From nobody Mon Feb 1 03:36:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D21B2CDA for ; Mon, 1 Feb 2016 03:36:32 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_eRIZw3UN6X for ; Mon, 1 Feb 2016 03:36:30 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1871ACE5C for ; Mon, 1 Feb 2016 03:36:30 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id 128so66431173wmz.1 for ; Mon, 01 Feb 2016 03:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=keDTJLtYydoTbzatXyr5FZqVy2PL7yp3cj4tQah8nzU=; b=nCx8Q9eb5x4Ri8uRzpMHiWrIdIi3HNGSxzxwwCRYfZopiEr9KDDU1tX5TLujTqobGD HICAJusnQshj8sxJCBPg8+XgipVatmGhV14GyfLHzB/LT2gr6fHUXv47R2po065JO+ta 4IeM4HPqw9ymVP3ygG3mal3QJD2vaQLFzLtMq0pQG/cWYMqEv//0/wpIU6TLhOGDsh6W 6A7/dOyfr/3fPjCuZ5uZtCrgi4RctJ0k9QrrDmQuaZxex58WITdBjpYRsCktmPOuEZLB 2FwT9+JKYlB1XZEgt2KpaTbjHONsaoB20PVTB4Cp+4cjrRmX3oE/afozUhFFzjaMBweG 2PKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=keDTJLtYydoTbzatXyr5FZqVy2PL7yp3cj4tQah8nzU=; b=eMGEor5vNvDWro+ebhoI6GD7DT8Hxy6WatlVPsNCqvXE7VnlewWKkPdlhVgp8RqeNQ TRuHs2h3D4FJkj5dBbrLfJuAOMIR0AcEwQ3GOiD0tYD9kS97k14kVLZTxyQC6HM0ICmf 0FTSzsiCE+FWVB6VEhvrKNVzIsKpHD9s9nla759/XtUIQeU6bWoLrNuTPOj9BDvoadJN VNRHxpThZehRTR66rPIC9a2bwiswl3J+Ud/JS7kpUIje73e1zy8cfM8SlZpH5ma1AVOq EEVpFV53X1KBkwJ330F2FXigsdX4Isfz1Q1zdt1sNtFJ+2deVRoCHVyw/sm4KPQNrTIi ul0w== X-Gm-Message-State: AG10YORYWYnXTYfzHXZ7Y04ISiuR1C04EV8eZGiaJvUx7XiuDlIw6bQLFQYk+bzagD06kw== X-Received: by 10.28.21.19 with SMTP id 19mr10642955wmv.43.1454326588683; Mon, 01 Feb 2016 03:36:28 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id lc1sm28577094wjc.5.2016.02.01.03.36.27 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 03:36:27 -0800 (PST) To: "oauth@ietf.org" References: From: Sergey Beryozkin Message-ID: <56AF433B.1040706@gmail.com> Date: Mon, 1 Feb 2016 11:36:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] How can client react to access token not-before errors X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:36:32 -0000 Hi Access tokens (particularly JWT-based) may have a not before property set - for example, a token introspection response may report an 'nbf' property. How can a client react to the error related to using the access token too early ? Typically a client would attempt to refresh a token if it has been rejected by RS, but in the case of NBF related errors it can become a cycle - refresh - get a new token - try it, too early, repeat... I think for RS reporting 503 with Retry-After, instead of 400/401, would be the right way to handle NBF errors. Thanks, Sergey From nobody Mon Feb 1 12:21:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6791B3603 for ; Mon, 1 Feb 2016 12:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 6w7j_Yx43X9W for ; Mon, 1 Feb 2016 12:21:32 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129531B3602 for ; Mon, 1 Feb 2016 12:21:32 -0800 (PST) Received: by mail-ob0-x22e.google.com with SMTP id is5so129967975obc.0 for ; Mon, 01 Feb 2016 12:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jfXfS8C3mhLoV7Sf8ygvcfAuWk4Tx5xfjPLuqg7Ghs0=; b=iflsRoqKrhKprQoWH+nNg4URWfYWbriVptUy3Q/pGWxdt2yoZWvSRMigGoKGovdUYO 19QaVN2iSznpSYnR+KJQXvhV+qPlPLLexW80g2b/4bdHOOTBzgMUuU7kxD0UCtQuiaE8 O4mqwfXqUfbFYukKGlGpXTqlNfDJtXGbZSPkSGFdWAaPLYq6cPSESETZC0KuYzKzXce5 TozEShVoBe38nWhOqQ9Pe+N06P1g8VcGnASk0CZe3xxHJAusfL+AOh7PMIf3nVZanqff 90dxZ4PH7Vp8vQ/AM1wwbjmZPc3BtycNB0h3LMAUiEyu+q1COOcu3lgrItT8yjEd524W p34g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jfXfS8C3mhLoV7Sf8ygvcfAuWk4Tx5xfjPLuqg7Ghs0=; b=SS732K6jO9+O9cSdB9kC+ToANTNnvcMdQlfLGQ42oB05UGxJxgWcjs2tT0YGeMIfxj R4H4U1YC3Dr9XmM4+Ym/4JqcBergwcEtTex4ebBa721O6DjNURcfjGm68V4QX7zgclcr omxDXNNrBzRmVyhpT2NUm/o+iYyfDGfJ3EhumtJ7RyO3JHagugsk1DQ4Yqe8LopBNTk5 kdNmL7kfbu+E8m+ofR2tM3Q9kmHxFnP62bApgDeZ5m+aghe2jJAOPuw1thCXgT80B624 cGFaoNLr4xMOzdrzdWuCnSGFe9/Muk0h+at/fAbekY9hCZDNPUM7yNIYCDS+thjvNwgZ wsDA== X-Gm-Message-State: AG10YOTixM0HraP4NXaLRwd7v77UyHiI7UsAPJBh2LIe1Q/64EDTyOB/+cBUtYMiXfEN2LHwcFuR1JtQHJjTwgLa X-Received: by 10.60.57.134 with SMTP id i6mr19293368oeq.11.1454358091408; Mon, 01 Feb 2016 12:21:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Mon, 1 Feb 2016 12:21:11 -0800 (PST) In-Reply-To: References: <56AB59CA.5070408@connect2id.com> <5CDF5150-89C7-4EC7-92C8-EE356C30993F@ve7jtb.com> From: William Denniss Date: Mon, 1 Feb 2016 12:21:11 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e013a2a266a80fc052abb2117 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:21:34 -0000 --089e013a2a266a80fc052abb2117 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 29, 2016 at 3:22 PM, Mike Jones wrote: > Do the PKCE authors want to make a concrete proposal for how to represent > this in discovery metadata? > We don't need to represent this property in the discovery metadata. All non-confidential clients should be using PKCE (and in the draft native apps best practice, we say it's a MUST if you want to follow the BCP). It's OK to send PKCE to a server that doesn't support PKCE (assuming standards compliance, they won't error on unknown params), and now we have a way that clients can discover PKCE support and send it only those those ASes who disclose this. If a server decides to fail all non-PKCE requests for non-confidential clients (which is fine), indicating this in discovery actually doesn't add a whole lot. Because if the client knows about PKCE it should have been sending it based on code_challenge_methods_supported anyway, and if it doesn't know about PKCE then it will always fail, discovery or not. The thing is, there is no reason for a public client to *not* send PKCE if the server indicates PKCE support, but then marks it as optional through this mechanism. If the client knows PKCE it should just always send PKCE = =E2=80=93 so knowing that the request would succeed even if it didn't doesn't add any value, and may cause harm. > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Friday, January 29, 2016 6:11 AM > *To:* Nat Sakimura > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Discovery metadata values added for > revocation, introspection, and PKCE > > > > The only problem with that is the client may only require it for some > types of clients (public) or response types. > > > > It may need to be finer grained than that, or define it as required for > all public clients using the token endpoint. > > > > John B. > > > > > > On Jan 29, 2016, at 10:15 AM, Nat Sakimura wrote: > > > > Good question. > > It's probably a good idea to be able to advertise this policy in the > discovery. > > Perhaps in the line of > > pkce_required or rfc7636_required? > The value should be Boolean. > > Nat from iPhone > > 2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 21:23 Vladimir Dzhuvinov : > > Thanks Mike, the updated spec looks good! > > I have a question related to PKCE: > > The PKCE spec seems to imply that an AS may require public clients to use > a code challenge: > > https://tools.ietf.org/html/rfc7636#section-4.4.1 > > If an AS has such a policy in place, how is this to be advertised? Or is > that supposed to the enforced when the client gets registered (there are = no > reg params for that at present)? > > On 28/01/16 19:27, Mike Jones wrote: > > The OAuth Discovery specification has been updated to add metadata values= for revocation , introspection , and PKCE . Changes were: > > > > * Added "revocation_endpoint_auth_methods_supported" and "revocatio= n_endpoint_auth_signing_alg_values_supported" for the revocation endpoint. > > > > * Added "introspection_endpoint_auth_methods_supported" and "intros= pection_endpoint_auth_signing_alg_values_supported" for the introspection e= ndpoint. > > > > * Added "code_challenge_methods_supported" for PKCE. > > > > The specification is available at: > > > > * http://tools.ietf.org/html/draft-jones-oauth-discovery-01 > > > > An HTML-formatted version is also available at: > > > > * http://self-issued.info/docs/draft-jones-oauth-discovery-01.html > > > > -- Mike > > > > P.S. This note was also published at http://self-issued.info/?p=3D1531 a= nd as @selfissued . > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013a2a266a80fc052abb2117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jan 29, 2016 at 3:22 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

Do the PKCE authors want to make a concrete pr= oposal for how to represent this in discovery metadata?


We don't need to represent this pro= perty in the discovery metadata.

All non-confident= ial clients should be using PKCE (and in the draft native apps best practic= e, we say it's a=C2=A0MUST=C2=A0if y= ou want to follow the BCP).=C2=A0 It's OK to send PKCE to a server that= doesn't support PKCE (assuming standards compliance, they won't er= ror on unknown params), and now we have a way that clients can discover PKC= E support and send it only those those ASes who disclose this.
If a server decides to fail all non-PKCE requests for non-conf= idential clients (which is fine), indicating this in discovery actually doe= sn't add a whole lot.=C2=A0 Because if the client knows about PKCE it s= hould have been sending it based on code_challenge_methods_supported anyway= , and if it doesn't know about PKCE then it will always fail, discovery= or not.

The thing is, there is no reason for a pu= blic client to *not* send PKCE if the server indicates PKCE support, but th= en marks it as optional through this mechanism.=C2=A0 If the client knows P= KCE it should just always send PKCE =E2=80=93 so knowing that the request w= ould succeed even if it didn't doesn't add any value, and may cause= harm.

=C2=A0

<= /u>

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, January 29, 2016 6:11 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for re= vocation, introspection, and PKCE

=C2=A0

The only problem with that is the client may only re= quire it for some types of clients (public) or response types.

=C2=A0

It may need to be finer grained than that, or define= it as required for all public clients using the token endpoint.<= /u>

=C2=A0

John B.

=C2=A0

=C2=A0

On Jan 29, 2016, at 10:15 AM, Nat Sakimura <sakimura@gmail.com&g= t; wrote:

=C2=A0

Good question.

It's probably a good idea to be able to advertise this policy in the di= scovery.

Perhaps in the line of

pkce_required or rfc7636_required?
The value should be Boolean.

Nat from iPhone

2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87= =91) 21:23 Vladimir Dzhuvinov <vladimir@connect2id.com>:

Thanks Mike, the update= d spec looks good!

I have a question related to PKCE:

The PKCE spec seems to imply that an AS may require public clients to use a= code challenge:

https://tools.ietf.org/html/rfc7636#section-4.4.1

If an AS has such a policy in place, how is this to be advertised? Or is th= at supposed to the enforced when the client gets registered (there are no r= eg params for that at present)?

On 28/01/16 19:27, Mike Jones wrote: 

The OAuth Discovery specification has been updated to add metadata val=
ues for revocation<http://tools.ietf.org/html/rfc7009>, introspection<http://tools=
.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636>.=C2=A0 Changes were:
=C2=A0
*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added "revocation_endpoint_=
auth_methods_supported" and "revocation_endpoint_auth_signing_alg=
_values_supported" for the revocation endpoint.
=C2=A0
*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added "introspection_endpoi=
nt_auth_methods_supported" and "introspection_endpoint_auth_signi=
ng_alg_values_supported" for the introspection endpoint.=

=C2=A0
*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Added "code_challenge_metho=
ds_supported" for PKCE.
=C2=A0
The specification is available at:
=C2=A0
*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.o=
rg/html/draft-jones-oauth-discovery-01
=C2=A0
An HTML-formatted version is also available at:
=C2=A0
*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-=
issued.info/docs/draft-jones-oauth-discovery-01.html

=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0


P.S.=C2=A0 This note was also published at http://self-issued.info/?p=3D1531 =
and as @selfissued<https://twitter.com/selfissued>.


=C2=A0


=C2=A0





_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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



-- 
Vladimir Dzhuvinov

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

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

=C2=A0


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


--089e013a2a266a80fc052abb2117-- From nobody Mon Feb 1 12:25:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722621B35CB for ; Mon, 1 Feb 2016 12:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 U4lquSQL8y7P for ; Mon, 1 Feb 2016 12:25:37 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AA81B3619 for ; Mon, 1 Feb 2016 12:25:36 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id xk3so30058099obc.2 for ; Mon, 01 Feb 2016 12:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=htfjBQ7Jotazm2s0IzrMHkqwTmd7y3lznLUNXO5FM68=; b=IVu/N+TFfzWl68Kj9KLggJ9dGkrlth4F+0W0OFbeEUljCpNfBa8xjz48EaEqXG892s uPQf9dwCNDGnDqXWRg2e9SOnepCNAbL9IIl48wajfR3BS4Bfv4iMdiAMLQeEmw9OW0a2 FXPmMV9Ry8A6wyvH/QIZEtflFhkAvTJ6oYvcOeekE6M6jNUzi4+zIBCp32w17Px5/gwV 6jxrhuVa5NkIrztXQiD+mWW46bgPDNaaodFnWvKP3WLi1szZC7xoU8evI0s4s4s4H5Xx CinhT8pumgAd/FjH+M6pwODe9kbf0fCvQ9dNyF5gH83ismM33Ne8aj10fwljb2Lnb2Ex 8uaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=htfjBQ7Jotazm2s0IzrMHkqwTmd7y3lznLUNXO5FM68=; b=e9MqEAxXQQ76qtn6wcKZ7XfuXdmYZBHf0FagmHecyV1Qx4d7byfGABKVjgk5V51czb Ma5TTzWsRS4fS56mCHtQ7cBVEkkrmlg+rxhMdNybC+sQSHdJUiba6F7BuZkZjyH0ybpe CKs6GWVfwl2lenwL8M8YsO7Q1JSgweaM0Fkde9/dz2Y6No5VcolcooyZAHXeYQ2wkm0k TjIy1UD14ZRPWMFj+liqBsBZvJaRot2MuzzCRRUZNY8Bh1b1FA5pUA0tPATK/F6EjsT3 7tFpNmvYC+PvKE1xsNKvZ/8qDFHx0TO5+XOxZaYPqZ7RS/L0mmucdtYPj+TKzjK3ut8h IwEQ== X-Gm-Message-State: AG10YOTcTTcnDVKwJxvwptV81WMdKNeegovpwWHwSzOnjqq5f1vOCyZK6hYoqEIYmvT3KFFCHjQtKWAoWfJsV6uW X-Received: by 10.182.114.167 with SMTP id jh7mr19678631obb.70.1454358336274; Mon, 01 Feb 2016 12:25:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Mon, 1 Feb 2016 12:25:16 -0800 (PST) In-Reply-To: References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com> From: William Denniss Date: Mon, 1 Feb 2016 12:25:16 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c2e2e602c27b052abb3046 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:25:42 -0000 --001a11c2e2e602c27b052abb3046 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We are now live with this change: https://accounts.google.com/.well-known/openid-configuration I'm glad we all reached a consensus on how this param should work, and what it should be called, and thank you Mike for revising the draft! My ask now is that we don't revisit this decision, unless for extremely good reasons, as we don't want to break clients who will start using this. On Mon, Jan 25, 2016 at 4:08 PM, William Denniss wrote: > Thanks Mike, looking forward to the update. I reviewed the other thread. > > On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones > wrote: > >> I'll add it to the discovery draft in the next day or so. Also, please >> see my questions in the message "[OAUTH-WG] Discovery document updates >> planned". I was waiting for that feedback before doing the update. >> >> Thanks, >> -- Mike >> ------------------------------ >> From: William Denniss >> Sent: =E2=80=8E1/=E2=80=8E25/=E2=80=8E2016 2:29 PM >> To: John Bradley >> Cc: Nat Sakimura ; oauth@ietf.org; Mike Jones >> >> Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery >> (draft-jones-oauth-discovery-00) >> >> OK great! It seems that we have consensus on this. So this is what we >> plan to add to our discovery doc, based on this discussion: >> >> "code_challenge_methods_supported": ["plain","S256"] >> >> What are the next steps? Can we we add it to >> https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see >> that the IANA registry created by that draft is "Specification >> Required", but PKCE is already an RFC without this param being registere= d. >> >> >> On Mon, Jan 25, 2016 at 2:11 PM, John Bradley wrote: >> >>> Yes sorry. code_challenge_method is the query parameter so >>> code_challenge_methods_supported >>> >>> >>> On Jan 25, 2016, at 6:12 PM, William Denniss >>> wrote: >>> >>> >>> >>> On Thu, Jan 21, 2016 at 6:17 AM, John Bradley wrote= : >>> >>>> The code_challenge and code_challenge_method parameter names predate >>>> calling the spec PKCE. >>>> >>>> Given that some of us deployed early versions of PKCE in products and >>>> opensource to mitigate the problem before the spec was completed we de= cided >>>> not to rename the parameter names from code_verifier_method to >>>> pkce_verifier_method. >>>> >>>> For consistency we should stick with code_verifier_methods_supported i= n >>>> discovery. >>>> >>> >>> To clarify, did you mean "code_challenge_methods_supported"? That is, >>> building on the param name "code_challenge_method" from Section 4.3 >>> ? >>> >>> >>>> >>>> John B. >>>> >>>> On Jan 21, 2016, at 3:12 AM, William Denniss >>>> wrote: >>>> >>>> "code_challenge_methods_supported" definitely works for me. >>>> >>>> Any objections to moving forward with that? I would like to update our >>>> discovery doc shortly. >>>> >>>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura >>>> wrote: >>>> >>>>> Ah, OK. That's actually reasonable. >>>>> >>>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake : >>>>> >>>>>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since t= he registered >>>>>> parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2= =80=9Cpkce_method". >>>>>> >>>>>> On Jan 19, 2016, at 11:58, William Denniss >>>>>> wrote: >>>>>> >>>>>> Seems like we agree this should be added. How should it look? >>>>>> >>>>>> Two ideas: >>>>>> >>>>>> "code_challenge_methods_supported": ["plain", "S256"] >>>>>> >>>>>> or >>>>>> >>>>>> "pkce_methods_supported": ["plain", "S256"] >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> Am 06.01.2016 um 18:25 schrieb William Denniss: >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley >>>>>>> wrote: >>>>>>> >>>>>>>> Good point. Now that PKCE is a RFC we should add it to discovery. >>>>>>>> >>>>>>>> John B. >>>>>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov < >>>>>>>> vladimir@connect2id.com> wrote: >>>>>>>> > >>>>>>>> > I just noticed PKCE support is missing from the discovery >>>>>>>> metadata. >>>>>>>> > >>>>>>>> > Is it a good idea to add it? >>>>>>>> > >>>>>>>> > Cheers, >>>>>>>> > >>>>>>>> > Vladimir >>>>>>>> > >>>>>>>> > -- >>>>>>>> > Vladimir Dzhuvinov >>>>>>>> > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > OAuth mailing list >>>>>>>> > OAuth@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listin= fo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>> >> > --001a11c2e2e602c27b052abb3046 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are now live with this change:

I'm glad we all reached a consensus on how this param shoul= d work, and what it should be called, and thank you Mike for revising the d= raft! My ask now is that we don't revisit this decision, unless for ext= remely good reasons, as we don't want to break clients who will start u= sing this.

On Mon, Jan 25, 2016 at 4:08 PM, William Denniss <= ;wdenniss@google.c= om> wrote:
Thanks Mike, looking forward to the update. I reviewed the other thread.

=
On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I'll add i= t to the discovery draft in the next day or so.=C2=A0 Also, please see my q= uestions in the message "[OAUTH-WG] Discovery document updates planned= ". I was waiting for that feedback before doing the update.

Thanks,
-- Mike
From: William Denniss
Sent: =E2=80= =8E1/=E2=80=8E25/=E2=80=8E2016 2:29 PM
To: John Bradley Cc: Nat Sakimura; oauth@ietf.org; Mike Jones
Subject: Re: [O= AUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-d= iscovery-00)

OK great! It seems that we have consensus on this. So this= is what we plan to add to our discovery doc, based on this discussion:

"code_challenge_methods_supported": ["plain","= ;S256"]

What are the next steps? Can we we add it to=C2=A0https://t= ools.ietf.org/html/draft-jones-oauth-discovery directly? I see that the= =C2=A0IANA registry created by that=C2=A0draft is "Specification Required", but PKCE is al= ready an RFC without this param being registered.


On Mon, Jan 25, 2016 at 2:11 PM, John Bradley <ve7jtb@ve7jtb.co= m> wrote:
Yes sorry. =C2=A0=C2=A0code_challe= nge_method is the query=C2=A0parameter= =C2=A0so=C2=A0code_challenge_methods_supported


On Jan 25, 2016, at 6:12 PM, William Denniss <wdenniss@google.com> wrote:


On Thu, Jan 21, 2016 at 6:17 AM, John Bradley <ve7jtb@ve7jtb.co= m> wrote:
The code_challenge and=C2=A0code_challe= nge_method parameter names predate calling the spec PKCE. =C2=A0

Given that some of us deployed early versions of PKCE in products and = opensource to mitigate the problem before the spec was completed we decided= not to rename the parameter names from code_verifier_method to pkce_verifi= er_method. =C2=A0

For consistency we should stick with code_verifier_methods_supported i= n discovery.

To clarify, did you mean "code_challenge_methods_supported"?= =C2=A0 That is, building on the param name "code_challenge_method"= ; from Section 4.3?
=C2=A0

John B.

On Jan 21, 2016, at 3:12 AM, William Denniss <wdenniss@google.com> wrote:
"code_challenge_meth= ods_supported" definitely works for me.

Any objections to moving forward with= that? I would like to update our discovery doc shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakimura@gmail.= com> wrote:
Ah, OK. That's actually reasonable.=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov mat= ake <matake@gmail.= com>:
I prefer =E2=80=9Ccode_challenge_method= s_supported=E2=80=9D, since the registered parameter name is =E2=80=9Ccode_= challenge_method=E2=80=9D, not =E2=80=9Cpkce_method".

On Jan 19, 2016, at 11:58, William Denniss <wdenniss@google.com> wrote:

Seems like we agree this should be added. How should it lo= ok?

Two ideas:

"code_challenge_methods_supported": ["plain", "S25= 6"]

or

"pkce_methods_supported": ["plain", "S256&quo= t;]



On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderst= edt <torsten@lo= dderstedt.net> wrote:
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.co= m> wrote:
Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com&= gt; wrote:
>
> I just noticed PKCE support is missing from the discovery metadata. >
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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



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


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

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

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






--001a11c2e2e602c27b052abb3046-- From nobody Mon Feb 1 13:12:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090231B36DC for ; Mon, 1 Feb 2016 13:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpeBeG2Apo_A for ; Mon, 1 Feb 2016 13:12:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E031B36D9 for ; Mon, 1 Feb 2016 13:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Eh5Yttrerzrs599McN0W9n6WzvgU2GQC9I9zA6CSPEY=; b=BikJM4ILbhzOq6wBOvfXGsaraYF55unc6qnt71AeQq4QSEoP9gA+GXdT+ovYC9z93z+Kw1gp48lx8OxmqhaF9YKKQAbUlABp5MLPhbFXSUfLeqWFhxITHYSllgyjiCGEBx4hmAPGLTd0dgbVzjunV2vgYkKZHd5ZVL62Hg7UcZ4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.396.15; Mon, 1 Feb 2016 21:12:43 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0396.020; Mon, 1 Feb 2016 21:12:43 +0000 From: Mike Jones To: William Denniss Thread-Topic: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) Thread-Index: AQHRSI65X4CzZd1mF0OC0DV6nH1wn57uj0gAgAAuDYCAAAmZAIATcoqAgAL7boCAAFXCgIAACbMAgACHgYCABr0aAIAAEIyAgAAFCoCAAAWVc4AAFigAgArB7ACAAA00cA== Date: Mon, 1 Feb 2016 21:12:43 +0000 Message-ID: References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::595] x-ms-office365-filtering-correlation-id: 432b5119-d128-4520-e625-08d32b4c6ce1 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:6swAj+ggC1zyptVF/X8yyMZopUC1eW2En6NLnSNwx6WNaczDCar2XLnfEUziqJcuqeL1iD2+ScnHIjOqxc/oQqVqcZMs6y33V0VcKHITS0l5wE49Bz3BLYF7Zb+0AJHWEdJH/3AiUxi5rp9w+xy0Uw==; 24:fi1dSbU+hnOAjRnU3ZOdnhU1/8jF5cb5btxtmznBSCpcEx5dwqNsKtAYQzW2SuyVY01qBWJwnV3e7eMK0Hq1YLXwVzmpktT9XsGUKyD+TVE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0839D067E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(24454002)(377454003)(76176999)(54356999)(230783001)(16236675004)(74316001)(19300405004)(50986999)(77096005)(2950100001)(2900100001)(76576001)(92566002)(33656002)(11100500001)(1220700001)(5001960100002)(110136002)(5008740100001)(10290500002)(15975445007)(3280700002)(86612001)(87936001)(1096002)(3660700001)(2906002)(586003)(19580395003)(19580405001)(102836003)(93886004)(3470700001)(790700001)(6116002)(19617315012)(4326007)(19609705001)(5880100001)(189998001)(99286002)(5002640100001)(122556002)(5004730100002)(106116001)(19625215002)(5003600100002)(40100003)(5005710100001)(10400500002)(86362001)(8990500004)(10090500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4427FE01334DEAADD6F42D6F5DE0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2016 21:12:43.2218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 21:12:50 -0000 --_000_BY2PR03MB4427FE01334DEAADD6F42D6F5DE0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZ3JhdHVsYXRpb25zIG9uIHlvdXIgZGVwbG95bWVudCENCg0KRnJvbTogV2lsbGlhbSBEZW5u aXNzIFttYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkg MSwgMjAxNiAxMjoyNSBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4NCkNjOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPjsgTmF0IFNha2ltdXJh IDxzYWtpbXVyYUBnbWFpbC5jb20+OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gQWR2ZXJ0aXNlIFBLQ0Ugc3VwcG9ydCBpbiBPQXV0aCAyLjAgRGlzY292ZXJ5IChkcmFm dC1qb25lcy1vYXV0aC1kaXNjb3ZlcnktMDApDQoNCldlIGFyZSBub3cgbGl2ZSB3aXRoIHRoaXMg Y2hhbmdlOg0KDQpodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20vLndlbGwta25vd24vb3Blbmlk LWNvbmZpZ3VyYXRpb24NCg0KSSdtIGdsYWQgd2UgYWxsIHJlYWNoZWQgYSBjb25zZW5zdXMgb24g aG93IHRoaXMgcGFyYW0gc2hvdWxkIHdvcmssIGFuZCB3aGF0IGl0IHNob3VsZCBiZSBjYWxsZWQs IGFuZCB0aGFuayB5b3UgTWlrZSBmb3IgcmV2aXNpbmcgdGhlIGRyYWZ0ISBNeSBhc2sgbm93IGlz IHRoYXQgd2UgZG9uJ3QgcmV2aXNpdCB0aGlzIGRlY2lzaW9uLCB1bmxlc3MgZm9yIGV4dHJlbWVs eSBnb29kIHJlYXNvbnMsIGFzIHdlIGRvbid0IHdhbnQgdG8gYnJlYWsgY2xpZW50cyB3aG8gd2ls bCBzdGFydCB1c2luZyB0aGlzLg0KDQpPbiBNb24sIEphbiAyNSwgMjAxNiBhdCA0OjA4IFBNLCBX aWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2ds ZS5jb20+PiB3cm90ZToNClRoYW5rcyBNaWtlLCBsb29raW5nIGZvcndhcmQgdG8gdGhlIHVwZGF0 ZS4gSSByZXZpZXdlZCB0aGUgb3RoZXIgdGhyZWFkLg0KDQpPbiBNb24sIEphbiAyNSwgMjAxNiBh dCAyOjQ5IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSdsbCBhZGQgaXQgdG8gdGhl IGRpc2NvdmVyeSBkcmFmdCBpbiB0aGUgbmV4dCBkYXkgb3Igc28uICBBbHNvLCBwbGVhc2Ugc2Vl IG15IHF1ZXN0aW9ucyBpbiB0aGUgbWVzc2FnZSAiW09BVVRILVdHXSBEaXNjb3ZlcnkgZG9jdW1l bnQgdXBkYXRlcyBwbGFubmVkIi4gSSB3YXMgd2FpdGluZyBmb3IgdGhhdCBmZWVkYmFjayBiZWZv cmUgZG9pbmcgdGhlIHVwZGF0ZS4NCg0KVGhhbmtzLA0KLS0gTWlrZQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IFdpbGxpYW0gRGVubmlzczxtYWlsdG86d2Rlbm5pc3NA Z29vZ2xlLmNvbT4NClNlbnQ6IOKAjjEv4oCOMjUv4oCOMjAxNiAyOjI5IFBNDQpUbzogSm9obiBC cmFkbGV5PG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4NCkNjOiBOYXQgU2FraW11cmE8bWFpbHRv OnNha2ltdXJhQGdtYWlsLmNvbT47IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz47IE1pa2UgSm9uZXM8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIEFkdmVydGlzZSBQS0NFIHN1cHBvcnQgaW4gT0F1dGggMi4wIERp c2NvdmVyeSAoZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwKQ0KT0sgZ3JlYXQhIEl0IHNl ZW1zIHRoYXQgd2UgaGF2ZSBjb25zZW5zdXMgb24gdGhpcy4gU28gdGhpcyBpcyB3aGF0IHdlIHBs YW4gdG8gYWRkIHRvIG91ciBkaXNjb3ZlcnkgZG9jLCBiYXNlZCBvbiB0aGlzIGRpc2N1c3Npb246 DQoNCiJjb2RlX2NoYWxsZW5nZV9tZXRob2RzX3N1cHBvcnRlZCI6IFsicGxhaW4iLCJTMjU2Il0N Cg0KV2hhdCBhcmUgdGhlIG5leHQgc3RlcHM/IENhbiB3ZSB3ZSBhZGQgaXQgdG8gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeSBkaXJlY3RseT8g SSBzZWUgdGhhdCB0aGUgSUFOQSByZWdpc3RyeSBjcmVhdGVkIGJ5IHRoYXQgZHJhZnQgaXMgIlNw ZWNpZmljYXRpb24gUmVxdWlyZWQiLCBidXQgUEtDRSBpcyBhbHJlYWR5IGFuIFJGQyB3aXRob3V0 IHRoaXMgcGFyYW0gYmVpbmcgcmVnaXN0ZXJlZC4NCg0KDQpPbiBNb24sIEphbiAyNSwgMjAxNiBh dCAyOjExIFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJA dmU3anRiLmNvbT4+IHdyb3RlOg0KWWVzIHNvcnJ5LiAgIGNvZGVfY2hhbGxlbmdlX21ldGhvZCBp cyB0aGUgcXVlcnkgcGFyYW1ldGVyIHNvIGNvZGVfY2hhbGxlbmdlX21ldGhvZHNfc3VwcG9ydGVk DQoNCg0KT24gSmFuIDI1LCAyMDE2LCBhdCA2OjEyIFBNLCBXaWxsaWFtIERlbm5pc3MgPHdkZW5u aXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KDQoN Ck9uIFRodSwgSmFuIDIxLCAyMDE2IGF0IDY6MTcgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZl N2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpUaGUgY29kZV9jaGFs bGVuZ2UgYW5kIGNvZGVfY2hhbGxlbmdlX21ldGhvZCBwYXJhbWV0ZXIgbmFtZXMgcHJlZGF0ZSBj YWxsaW5nIHRoZSBzcGVjIFBLQ0UuDQoNCkdpdmVuIHRoYXQgc29tZSBvZiB1cyBkZXBsb3llZCBl YXJseSB2ZXJzaW9ucyBvZiBQS0NFIGluIHByb2R1Y3RzIGFuZCBvcGVuc291cmNlIHRvIG1pdGln YXRlIHRoZSBwcm9ibGVtIGJlZm9yZSB0aGUgc3BlYyB3YXMgY29tcGxldGVkIHdlIGRlY2lkZWQg bm90IHRvIHJlbmFtZSB0aGUgcGFyYW1ldGVyIG5hbWVzIGZyb20gY29kZV92ZXJpZmllcl9tZXRo b2QgdG8gcGtjZV92ZXJpZmllcl9tZXRob2QuDQoNCkZvciBjb25zaXN0ZW5jeSB3ZSBzaG91bGQg c3RpY2sgd2l0aCBjb2RlX3ZlcmlmaWVyX21ldGhvZHNfc3VwcG9ydGVkIGluIGRpc2NvdmVyeS4N Cg0KVG8gY2xhcmlmeSwgZGlkIHlvdSBtZWFuICJjb2RlX2NoYWxsZW5nZV9tZXRob2RzX3N1cHBv cnRlZCI/ICBUaGF0IGlzLCBidWlsZGluZyBvbiB0aGUgcGFyYW0gbmFtZSAiY29kZV9jaGFsbGVu Z2VfbWV0aG9kIiBmcm9tIFNlY3Rpb24gNC4zPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NjM2I3NlY3Rpb24tNC4zPj8NCg0KDQpKb2huIEIuDQoNCk9uIEphbiAyMSwgMjAxNiwgYXQg MzoxMiBBTSwgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVu bmlzc0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCiJjb2RlX2NoYWxsZW5nZV9tZXRob2RzX3N1cHBv cnRlZCIgZGVmaW5pdGVseSB3b3JrcyBmb3IgbWUuDQoNCkFueSBvYmplY3Rpb25zIHRvIG1vdmlu ZyBmb3J3YXJkIHdpdGggdGhhdD8gSSB3b3VsZCBsaWtlIHRvIHVwZGF0ZSBvdXIgZGlzY292ZXJ5 IGRvYyBzaG9ydGx5Lg0KDQpPbiBUaHUsIEphbiAyMSwgMjAxNiBhdCAxOjM3IFBNLCBOYXQgU2Fr aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3Jv dGU6DQpBaCwgT0suIFRoYXQncyBhY3R1YWxseSByZWFzb25hYmxlLg0KDQoyMDE25bm0MeaciDIx 5pelKOacqCkgOTozMSBub3YgbWF0YWtlIDxtYXRha2VAZ21haWwuY29tPG1haWx0bzptYXRha2VA Z21haWwuY29tPj46DQpJIHByZWZlciDigJxjb2RlX2NoYWxsZW5nZV9tZXRob2RzX3N1cHBvcnRl ZOKAnSwgc2luY2UgdGhlIHJlZ2lzdGVyZWQgcGFyYW1ldGVyIG5hbWUgaXMg4oCcY29kZV9jaGFs bGVuZ2VfbWV0aG9k4oCdLCBub3Qg4oCccGtjZV9tZXRob2QiLg0KDQpPbiBKYW4gMTksIDIwMTYs IGF0IDExOjU4LCBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndk ZW5uaXNzQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KU2VlbXMgbGlrZSB3ZSBhZ3JlZSB0aGlzIHNo b3VsZCBiZSBhZGRlZC4gSG93IHNob3VsZCBpdCBsb29rPw0KDQpUd28gaWRlYXM6DQoNCiJjb2Rl X2NoYWxsZW5nZV9tZXRob2RzX3N1cHBvcnRlZCI6IFsicGxhaW4iLCAiUzI1NiJdDQoNCm9yDQoN CiJwa2NlX21ldGhvZHNfc3VwcG9ydGVkIjogWyJwbGFpbiIsICJTMjU2Il0NCg0KDQpPbiBXZWQs IEphbiA2LCAyMDE2IGF0IDk6NTkgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KKzEN Cg0KQW0gMDYuMDEuMjAxNiB1bSAxODoyNSBzY2hyaWViIFdpbGxpYW0gRGVubmlzczoNCisxDQoN Ck9uIFdlZCwgSmFuIDYsIDIwMTYgYXQgNjo0MCBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3 anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkdvb2QgcG9pbnQuICBO b3cgdGhhdCBQS0NFIGlzIGEgUkZDIHdlIHNob3VsZCBhZGQgaXQgdG8gZGlzY292ZXJ5Lg0KDQpK b2huIEIuDQo+IE9uIEphbiA2LCAyMDE2LCBhdCA5OjI5IEFNLCBWbGFkaW1pciBEemh1dmlub3Yg PHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+ IHdyb3RlOg0KPg0KPiBJIGp1c3Qgbm90aWNlZCBQS0NFIHN1cHBvcnQgaXMgbWlzc2luZyBmcm9t IHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuDQo+DQo+IElzIGl0IGEgZ29vZCBpZGVhIHRvIGFkZCBp dD8NCj4NCj4gQ2hlZXJzLA0KPg0KPiBWbGFkaW1pcg0KPg0KPiAtLQ0KPiBWbGFkaW1pciBEemh1 dmlub3YNCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5n IGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0K DQoNCg== --_000_BY2PR03MB4427FE01334DEAADD6F42D6F5DE0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNYWxndW4gR290aGljIjt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Q29u Z3JhdHVsYXRpb25zIG9uIHlvdXIgZGVwbG95bWVudCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAxLCAyMDE2IDEyOjI1IFBNPGJyPg0K PGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0Ozsg TmF0IFNha2ltdXJhICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBZHZlcnRpc2UgUEtDRSBzdXBwb3J0 IGluIE9BdXRoIDIuMCBEaXNjb3ZlcnkgKGRyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMCk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgbm93IGxpdmUgd2l0 aCB0aGlzIGNoYW5nZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9vcGVu aWQtY29uZmlndXJhdGlvbiI+aHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxsLWtub3du L29wZW5pZC1jb25maWd1cmF0aW9uPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gZ2xhZCB3ZSBhbGwgcmVhY2hlZCBhIGNvbnNlbnN1 cyBvbiBob3cgdGhpcyBwYXJhbSBzaG91bGQgd29yaywgYW5kIHdoYXQgaXQgc2hvdWxkIGJlIGNh bGxlZCwgYW5kIHRoYW5rIHlvdSBNaWtlIGZvciByZXZpc2luZyB0aGUgZHJhZnQhIE15IGFzayBu b3cgaXMgdGhhdCB3ZSBkb24ndCByZXZpc2l0IHRoaXMgZGVjaXNpb24sIHVubGVzcyBmb3IgZXh0 cmVtZWx5IGdvb2QgcmVhc29ucywgYXMgd2UgZG9uJ3QNCiB3YW50IHRvIGJyZWFrIGNsaWVudHMg d2hvIHdpbGwgc3RhcnQgdXNpbmcgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gMjUsIDIwMTYgYXQgNDowOCBQTSwg V2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IE1pa2UsIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgdXBkYXRlLiBJIHJldmlld2VkIHRoZSBvdGhl ciB0aHJlYWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgSmFuIDI1LCAyMDE2IGF0IDI6NDkgUE0sIE1pa2UgSm9uZXMg Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkknbGwgYWRkIGl0IHRvIHRoZSBkaXNjb3ZlcnkgZHJh ZnQgaW4gdGhlIG5leHQgZGF5IG9yIHNvLiZuYnNwOyBBbHNvLCBwbGVhc2Ugc2VlIG15IHF1ZXN0 aW9ucyBpbiB0aGUgbWVzc2FnZSAmcXVvdDtbT0FVVEgtV0ddIERpc2NvdmVyeSBkb2N1bWVudCB1 cGRhdGVzIHBsYW5uZWQmcXVvdDsuIEkgd2FzIHdhaXRpbmcgZm9yIHRoYXQNCiBmZWVkYmFjayBi ZWZvcmUgZG9pbmcgdGhlIHVwZGF0ZS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhy IHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOndk ZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5XaWxsaWFtIERlbm5pc3M8L2E+PC9z cGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPuKAjjEv4oCOMjUv4oCOMjAxNiAyOjI5IFBNPC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86 dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj5Kb2huIEJyYWRsZXk8L2E+PC9zcGFu Pjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+TmF0 IFNha2ltdXJhPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KTWlrZSBKb25lczwvYT48L3NwYW4+PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5SZTogW09BVVRILVdHXSBBZHZlcnRpc2UgUEtDRSBzdXBwb3J0IGluIE9BdXRoIDIuMCBE aXNjb3ZlcnkgKGRyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMCk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PSyBncmVhdCEgSXQgc2VlbXMgdGhhdCB3ZSBoYXZlIGNvbnNlbnN1cyBvbiB0aGlz LiBTbyB0aGlzIGlzIHdoYXQgd2UgcGxhbiB0byBhZGQgdG8gb3VyIGRpc2NvdmVyeSBkb2MsIGJh c2VkIG9uIHRoaXMgZGlzY3Vzc2lvbjoNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JnF1b3Q7Y29kZV9jaGFsbGVuZ2VfbWV0aG9kc19zdXBwb3J0ZWQmcXVv dDs6IFsmcXVvdDtwbGFpbiZxdW90OywmcXVvdDtTMjU2JnF1b3Q7XTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFyZSB0aGUgbmV4dCBz dGVwcz8gQ2FuIHdlIHdlIGFkZCBpdCB0byZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnkiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5PC9h PiBkaXJlY3RseT8gSSBzZWUgdGhhdCB0aGUmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+SUFOQQ0KIHJlZ2lzdHJ5IGNyZWF0ZWQgYnkgdGhhdDwvc3Bhbj4m bmJzcDtkcmFmdCBpcyAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+U3BlY2lmaWNhdGlvbiBSZXF1aXJlZCZxdW90OywgYnV0IFBLQ0UgaXMgYWxyZWFkeSBh biBSRkMgd2l0aG91dCB0aGlzIHBhcmFtIGJlaW5nIHJlZ2lzdGVyZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgSmFuIDI1LCAyMDE2IGF0IDI6MTEgUE0sIEpvaG4gQnJhZGxleSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRi QHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyBzb3JyeS4gJm5ic3A7Jm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmNvZGVfY2hhbGxlbmdlX21ldGhvZCBpcyB0 aGUgcXVlcnkmbmJzcDtwYXJhbWV0ZXImbmJzcDtzbyZuYnNwO2NvZGVfY2hhbGxlbmdlX21ldGhv ZHNfc3VwcG9ydGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDI1LCAyMDE2 LCBhdCA2OjEyIFBNLCBXaWxsaWFtIERlbm5pc3MgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZGVubmlz c0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc3NAZ29vZ2xlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMjEs IDIwMTYgYXQgNjoxNyBBTSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRi QHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgY29kZV9jaGFsbGVuZ2UgYW5kJm5ic3A7Y29kZV9jaGFsbGVuZ2VfbWV0aG9kIHBh cmFtZXRlciBuYW1lcyBwcmVkYXRlIGNhbGxpbmcgdGhlIHNwZWMgUEtDRS4gJm5ic3A7DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoYXQgc29t ZSBvZiB1cyBkZXBsb3llZCBlYXJseSB2ZXJzaW9ucyBvZiBQS0NFIGluIHByb2R1Y3RzIGFuZCBv cGVuc291cmNlIHRvIG1pdGlnYXRlIHRoZSBwcm9ibGVtIGJlZm9yZSB0aGUgc3BlYyB3YXMgY29t cGxldGVkIHdlIGRlY2lkZWQgbm90IHRvIHJlbmFtZSB0aGUgcGFyYW1ldGVyIG5hbWVzIGZyb20g Y29kZV92ZXJpZmllcl9tZXRob2QgdG8gcGtjZV92ZXJpZmllcl9tZXRob2QuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgY29u c2lzdGVuY3kgd2Ugc2hvdWxkIHN0aWNrIHdpdGggY29kZV92ZXJpZmllcl9tZXRob2RzX3N1cHBv cnRlZCBpbiBkaXNjb3ZlcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gY2xhcmlmeSwgZGlkIHlv dSBtZWFuICZxdW90O2NvZGVfY2hhbGxlbmdlX21ldGhvZHNfc3VwcG9ydGVkJnF1b3Q7PyZuYnNw OyBUaGF0IGlzLCBidWlsZGluZyBvbiB0aGUgcGFyYW0gbmFtZSAmcXVvdDtjb2RlX2NoYWxsZW5n ZV9tZXRob2QmcXVvdDsgZnJvbQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc2MzYjc2VjdGlvbi00LjMiIHRhcmdldD0iX2JsYW5rIj5TZWN0aW9uIDQuMzwvYT4/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAyMSwgMjAxNiwgYXQg MzoxMiBBTSwgV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90Ozxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPmNvZGVfY2hhbGxlbmdlX21ldGhvZHNfc3VwcG9y dGVkJnF1b3Q7IGRlZmluaXRlbHkgd29ya3MgZm9yIG1lLjwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+QW55IG9iamVjdGlvbnMgdG8gbW92aW5nIGZvcndhcmQgd2l0aCB0aGF0PyBJIHdvdWxk IGxpa2UgdG8gdXBkYXRlIG91ciBkaXNjb3ZlcnkgZG9jIHNob3J0bHkuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEph biAyMSwgMjAxNiBhdCAxOjM3IFBNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWgsIE9LLiBUaGF0J3MgYWN0dWFsbHkgcmVhc29uYWJsZS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTY8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7lubQ8 L3NwYW4+MTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7 LHNhbnMtc2VyaWYiPuaciDwvc3Bhbj4yMTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN YWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pyoPC9zcGFu PikNCiA5OjMxIG5vdiBtYXRha2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXRha2VAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWF0YWtlQGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBwcmVmZXIg4oCcY29kZV9jaGFsbGVuZ2VfbWV0aG9kc19zdXBwb3J0ZWTigJ0s IHNpbmNlIHRoZSByZWdpc3RlcmVkIHBhcmFtZXRlciBuYW1lIGlzIOKAnGNvZGVfY2hhbGxlbmdl X21ldGhvZOKAnSwgbm90IOKAnHBrY2VfbWV0aG9kJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAxOSwgMjAx NiwgYXQgMTE6NTgsIFdpbGxpYW0gRGVubmlzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNz QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWVt cyBsaWtlIHdlIGFncmVlIHRoaXMgc2hvdWxkIGJlIGFkZGVkLiBIb3cgc2hvdWxkIGl0IGxvb2s/ PGJyPg0KPGJyPg0KVHdvIGlkZWFzOjxicj4NCjxicj4NCiZxdW90O2NvZGVfY2hhbGxlbmdlX21l dGhvZHNfc3VwcG9ydGVkJnF1b3Q7OiBbJnF1b3Q7cGxhaW4mcXVvdDssICZxdW90O1MyNTYmcXVv dDtdIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3I8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+JnF1b3Q7cGtjZV9tZXRob2RzX3N1cHBvcnRlZCZxdW90OzogWyZxdW90 O3BsYWluJnF1b3Q7LCAmcXVvdDtTMjU2JnF1b3Q7XTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg SmFuIDYsIDIwMTYgYXQgOTo1OSBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFt IDA2LjAxLjIwMTYgdW0gMTg6MjUgc2NocmllYiBXaWxsaWFtIERlbm5pc3M6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gNiwgMjAx NiBhdCA2OjQwIEFNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3 anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBw b2ludC4mbmJzcDsgTm93IHRoYXQgUEtDRSBpcyBhIFJGQyB3ZSBzaG91bGQgYWRkIGl0IHRvIGRp c2NvdmVyeS48YnI+DQo8YnI+DQpKb2huIEIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgT24gSmFuIDYsIDIwMTYsIGF0IDk6MjkgQU0sIFZs YWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGp1c3Qgbm90aWNlZCBQS0NFIHN1cHBvcnQgaXMgbWlz c2luZyBmcm9tIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuPGJyPg0KJmd0Ozxicj4NCiZndDsgSXMg aXQgYSBnb29kIGlkZWEgdG8gYWRkIGl0Pzxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBWbGFkaW1pcjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0 OyBWbGFkaW1pciBEemh1dmlub3Y8YnI+DQomZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY2PR03MB4427FE01334DEAADD6F42D6F5DE0BY2PR03MB442namprd_-- From nobody Tue Feb 2 00:27:59 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338871A914A for ; Tue, 2 Feb 2016 00:25:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTPT9jRGgMPC for ; Tue, 2 Feb 2016 00:25:47 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC1C1A9125 for ; Tue, 2 Feb 2016 00:25:46 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id 128so106073910wmz.1 for ; Tue, 02 Feb 2016 00:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=Gg6qx/O+0Vl1R2j1BqzZRETCc8ZuKgF4Q4IfqrY4BpM=; b=EM7vfDTRZrKr1vRFLlg5kiJnP0FbRJlazRiQQM7kl5l58lp0g5P/1wb/M77ZO6FIpX memySS4LZUc9/vMQPZFFCS4jaKFLcrBDaeDEtqTl/cdlZeezRNhu/1tW0LTEChxdpJQ/ MIFHLdqe40/1Cv+JY62VnATNEZqIMTPDntRyS23KiAlg0WBJ8Mv1BN58aXN9BP55/SYx K55ihX19VwJYxMPQ5o8rOEWdssCnT54rdWeypolqpYU9ruZGuZHrZfAuSPMqmruh924b EVy80PTy1HDU/60vFuoVwVE9uDX8/fQmK3wY8xY3lrTWEZdq30Y27F7b95fQ2jQvp/2V BZSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=Gg6qx/O+0Vl1R2j1BqzZRETCc8ZuKgF4Q4IfqrY4BpM=; b=b8D6HsVsIIAp+a3NIQTdJKEEvdPTNOCIJLhSI1JIrGuK2fRarWhcII9mj+km6fSs1A HFjmc5P1B1jdLGP+aXaHc9+tnrAJsti/cUAdXENHldgDP063fZCE4dVXq5B6JhLXIya4 AiBwl4aqJSbIuOoKd1kLURPCZsOyNxhLmk/FE0aGwSP4tV5EnYNjkQqyNJaiR6jXgV11 I31i8pbue9rx4ifFOkdnhz0kMFs6/5DlFxTnlFvJsh2PpgfcllKyeWmnEIkBuEa0eqBW ma2nkbEyjz1nTbvpS42nGxtaQmuEcB/qIVfsq0k4mcosvoumKi8VjbfU4nL5WSZsS9wD 54Xw== X-Gm-Message-State: AG10YOS6NC1J2PpSI1V/2cthZOKApASoeMD2fkk+Vp5ery9UuKnmvB8O4mCVcA98RsNfxQ== X-Received: by 10.28.104.87 with SMTP id d84mr17300283wmc.56.1454401545022; Tue, 02 Feb 2016 00:25:45 -0800 (PST) Received: from dombp.local (p508CF4F7.dip0.t-ipconnect.de. [80.140.244.247]) by smtp.gmail.com with ESMTPSA id c7sm754252wmd.13.2016.02.02.00.25.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 00:25:43 -0800 (PST) Date: Tue, 2 Feb 2016 09:25:42 +0100 From: Dominick Baier To: William Denniss , Mike Jones Message-ID: In-Reply-To: References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com> X-Mailer: Airmail (351) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="56b06806_11a79f96_e59c" Archived-At: Cc: "=?utf-8?Q?oauth=40ietf.org?=" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:25:50 -0000 --56b06806_11a79f96_e59c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline IdentityServer 2.4 has PKCE support now as well https://github.com/IdentityServer/IdentityServer3/releases/tag/2.4.0 --=C2=A0 Dominick Baier On 1 =46ebruary 2016 at 22:12:54, Mike Jones (michael.jones=40microsoft.c= om) wrote: Congratulations on your deployment=21 =C2=A0 =46rom: William Denniss =5Bmailto:wdenniss=40google.com=5D Sent: Monday, =46ebruary 1, 2016 12:25 PM To: Mike Jones Cc: John Bradley ; Nat Sakimura ; oauth=40ietf.org Subject: Re: =5BOAUTH-WG=5D Advertise PKCE support in OAuth 2.0 Discovery= (draft-jones-oauth-discovery-00) =C2=A0 We are now live with this change: =C2=A0 https://accounts.google.com/.well-known/openid-configuration =C2=A0 I'm glad we all reached a consensus on how this param should work, and wh= at it should be called, and thank you Mike for revising the draft=21 My a= sk now is that we don't revisit this decision, unless for extremely good = reasons, as we don't want to break clients who will start using this. =C2=A0 On Mon, Jan 25, 2016 at 4:08 PM, William Denniss = wrote: Thanks Mike, looking forward to the update. I reviewed the other thread. =C2=A0 On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones wrote: I'll add it to the discovery draft in the next day or so.=C2=A0 Also, ple= ase see my questions in the message =22=5BOAUTH-WG=5D Discovery document = updates planned=22. I was waiting for that feedback before doing the upda= te. Thanks, -- Mike =46rom: William Denniss Sent: =E2=80=8E1/=E2=80=8E25/=E2=80=8E2016 2:29 PM To: John Bradley Cc: Nat Sakimura; oauth=40ietf.org; Mike Jones Subject: Re: =5BOAUTH-WG=5D Advertise PKCE support in OAuth 2.0 Discovery= (draft-jones-oauth-discovery-00) OK great=21 It seems that we have consensus on this. So this is what we p= lan to add to our discovery doc, based on this discussion: =C2=A0 =22code=5Fchallenge=5Fmethods=5Fsupported=22: =5B=22plain=22,=22S256=22=5D= =C2=A0 What are the next steps=3F Can we we add it to=C2=A0https://tools.ietf.or= g/html/draft-jones-oauth-discovery directly=3F I see that the=C2=A0IANA r= egistry created by that=C2=A0draft is =22Specification Required=22, but P= KCE is already an R=46C without this param being registered. =C2=A0 =C2=A0 On Mon, Jan 25, 2016 at 2:11 PM, John Bradley wrote= : Yes sorry. =C2=A0=C2=A0code=5Fchallenge=5Fmethod is the query=C2=A0parame= ter=C2=A0so=C2=A0code=5Fchallenge=5Fmethods=5Fsupported =C2=A0 =C2=A0 On Jan 25, 2016, at 6:12 PM, William Denniss wrot= e: =C2=A0 =C2=A0 =C2=A0 On Thu, Jan 21, 2016 at 6:17 AM, John Bradley wrote= : The code=5Fchallenge and=C2=A0code=5Fchallenge=5Fmethod parameter names p= redate calling the spec PKCE. =C2=A0 =C2=A0 Given that some of us deployed early versions of PKCE in products and ope= nsource to mitigate the problem before the spec was completed we decided = not to rename the parameter names from code=5Fverifier=5Fmethod to pkce=5F= verifier=5Fmethod. =C2=A0 =C2=A0 =46or consistency we should stick with code=5Fverifier=5Fmethods=5Fsuppor= ted in discovery. =C2=A0 To clarify, did you mean =22code=5Fchallenge=5Fmethods=5Fsupported=22=3F=C2= =A0 That is, building on the param name =22code=5Fchallenge=5Fmethod=22 f= rom Section 4.3=3F =C2=A0 =C2=A0 John B. =C2=A0 On Jan 21, 2016, at 3:12 AM, William Denniss wrot= e: =C2=A0 =22code=5Fchallenge=5Fmethods=5Fsupported=22 definitely works for me. =C2=A0 Any objections to moving forward with that=3F I would like to update our = discovery doc shortly. =C2=A0 On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura wrot= e: Ah, OK. That's actually reasonable.=C2=A0 =C2=A0 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake : I prefer =E2=80=9Ccode=5Fchallenge=5Fmethods=5Fsupported=E2=80=9D, since = the registered parameter name is =E2=80=9Ccode=5Fchallenge=5Fmethod=E2=80= =9D, not =E2=80=9Cpkce=5Fmethod=22. =C2=A0 On Jan 19, 2016, at 11:58, William Denniss wrote:= =C2=A0 Seems like we agree this should be added. How should it look=3F Two ideas: =22code=5Fchallenge=5Fmethods=5Fsupported=22: =5B=22plain=22, =22S256=22=5D= =C2=A0 or =C2=A0 =22pkce=5Fmethods=5Fsupported=22: =5B=22plain=22, =22S256=22=5D =C2=A0 On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt wrote: +1 =C2=A0 Am 06.01.2016 um 18:25 schrieb William Denniss: +1 =C2=A0 On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote:= Good point.=C2=A0 Now that PKCE is a R=46C we should add it to discovery.= John B. > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov wrote: > > I just noticed PKCE support is missing from the discovery metadata. > > Is it a good idea to add it=3F > > Cheers, > > Vladimir > > -- > Vladimir Dzhuvinov > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > OAuth mailing list > OAuth=40ietf.org > https://www.ietf.org/mailman/listinfo/oauth =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 OAuth mailing list =20 OAuth=40ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 --56b06806_11a79f96_e59c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

We have created the initial working group version of= OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative= changes.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-iet= f-oauth-discovery-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/= draft-ietf-oauth-discovery-00.html

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.

 

--_000_BY2PR03MB4427E9DAFDE674F71F6074AF5D60BY2PR03MB442namprd_-- From nobody Tue Feb 9 06:39:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D0B1A90A2 for ; Tue, 9 Feb 2016 06:39:32 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI0SIlpZ-yND for ; Tue, 9 Feb 2016 06:39:31 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98941A90A1 for ; Tue, 9 Feb 2016 06:39:30 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id 128so199222141wmz.1 for ; Tue, 09 Feb 2016 06:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=bB5dUXIZKvif5BhMxumBEZHMevOAcjvFMgo6lLXu5tw=; b=xS6GDyhw6hRvhgHj9y8PJFdXZL+PoqXBkomzTII5cQLKKIQsngP9sDU5iRJmr+eXb0 7puQ5oCOaQoNYSQ/6Z+hwj07IEs5hKORHykiIWwj6AnqglqND3aAG1nwXmqXmT87RaOU 6VGi+cTc//rrXslsBtIBHgZlOLsvqoaYiWw2c0zJBcUsf8GFMxJxiPr4xqrPg8P37rT9 30UF83cq8sIJ49Mdw8UYKI8ig35KverLmC7G4UMJ6wlN09064XNO0lFSTgZksWmq0NQk HMby2lLyUhqGY/OHAyheutozRYtcEknlLhIB4bozjOu2oMXdJgjkMdxwz8yAPzF6fB/V mDlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=bB5dUXIZKvif5BhMxumBEZHMevOAcjvFMgo6lLXu5tw=; b=KXyLF5CIs/RqCvULTj8TkLHcs7XhOqbEqP5D8fCHcOd1W42IKy6qJDgDlKLH1hQnGV macwoZWMyZ0hPu1TlgvKdyGg4d++odbUeLE081BU00ddNTNpn3bySaeCl9VllSrE/NGs sI+pEb63Ntscc0lK4zXv3xWlcsNC3QmREjiVrM0cdQ1uFEzBVANAvNjTB3mLMKHRZoNe XfYqFK6dnBik1MDEu4SpUjbICTrefWxnKnoAq6plxnbGPmthhQbG+RWilUO51E8OAga0 /3A56PiFk/3gEpEZjGoizYPxhSQ2ABIGDcGZloXcQLZ6Z12lOFou2HvigfyxZ6iy/94Q fy4w== X-Gm-Message-State: AG10YOSlBrsc78rxOrsrZ0RspJdRT7EFdE+Rct3VPqu8vtK/pWEeKLOARq8q1dlBN2w4bg== X-Received: by 10.28.73.136 with SMTP id w130mr5576099wma.36.1455028769511; Tue, 09 Feb 2016 06:39:29 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id i2sm34966171wjx.42.2016.02.09.06.39.28 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 06:39:28 -0800 (PST) References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> <9DC45CB4-07D8-4F17-8311-02AD60521379@ve7jtb.com> To: oauth@ietf.org From: Sergey Beryozkin Message-ID: <56B9FA20.60509@gmail.com> Date: Tue, 9 Feb 2016 14:39:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Missing response_type with implicit and code flows on the same path X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 14:39:32 -0000 Hi OAuth2 spec recommends how to deal with a missing response_type, set an error as a query or fragment parameter, depending on whether it is the authorization code or implicit flow and redirect. This implies that authorization code and implicit handlers listen on different paths, for example, code: /code implicit: /implicit so if a response type is missing the handler will know how to set the error on the redirect uri, as a query or a fragment..... However, I'd like to have a single handler, example (from the OIDC core): "https://server.example.com/authorize" which will support both the code and implicit flows. Here, 'response_type' is an obvious hint on what kind of flow is in process, however, if it is missing, how will a server know how to report a missing response_type error if it uses a shared "/authorize" path. I think in such cases reporting 400 is reasonable. Do you agree ? Thanks, Sergey From nobody Tue Feb 9 08:09:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108AC1AC3A5 for ; Tue, 9 Feb 2016 08:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqu24O-GTQzq for ; Tue, 9 Feb 2016 08:09:40 -0800 (PST) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FF81AC406 for ; Tue, 9 Feb 2016 08:09:40 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa09-06.prod.phx3.secureserver.net with id GG9e1s00E15ZTut01G9fRW; Tue, 09 Feb 2016 09:09:40 -0700 To: oauth@ietf.org References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> <9DC45CB4-07D8-4F17-8311-02AD60521379@ve7jtb.com> <56B9FA20.60509@gmail.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56BA0F42.5070702@connect2id.com> Date: Tue, 9 Feb 2016 18:09:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B9FA20.60509@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020806070907020609040801" Archived-At: Subject: Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:09:42 -0000 This is a cryptographically signed message in MIME format. --------------ms020806070907020609040801 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sergey, Yes, HTTP 400 is one way to handle a missing response_type with a "universal" authz endpoint. Or, you could encode the error in the query string as well as the fragment, and redirect back to the client. Vladimir On 09/02/16 16:39, Sergey Beryozkin wrote: > Hi > > OAuth2 spec recommends how to deal with a missing response_type, set > an error as a query or fragment parameter, depending on whether it is > the authorization code or implicit flow and redirect. > > This implies that authorization code and implicit handlers listen on > different paths, for example, > > code: /code > implicit: /implicit > > so if a response type is missing the handler will know how to set the > error on the redirect uri, as a query or a fragment..... > > However, I'd like to have a single handler, example (from the OIDC core= ): > > "https://server.example.com/authorize" > > which will support both the code and implicit flows. > > Here, 'response_type' is an obvious hint on what kind of flow is in > process, however, if it is missing, how will a server know how to > report a missing response_type error if it uses a shared "/authorize" > path. > > I think in such cases reporting 400 is reasonable. Do you agree ? > > Thanks, Sergey > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms020806070907020609040801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMDkxNjA5MzhaMC8GCSqGSIb3DQEJBDEiBCCGfmsZehW3vZY/tzb6JJd5neTL+2gg ZiFFV1g1lZp9jjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCgNS2vJ+3a LQ7zIdnVp2BbrOCoyCYJJ0VEjGieSIct09uXf4zIK4LLtVPdyQWYHE4a8OK1RNvwvyDwjzVN sr3Wh9sBhmIhZoSYhy2Mfn9wbiRC5DqVAxA0UmHAvnot1t2NFeT/PMYtsHazFuvUb4UOEqgU lihXgEcyMyUxZtPtEtPSjvAnuQHgraLBPZfM0mjpr3aLrEGMRSghQsrLcO7h/mSzkRYDmVEN +FpPancwxzDCSqzlacKyCkMsGVeDbTnCTGpH89nOtrX7Sc51NTNajUvdYHrY/xq0mQVKxnC8 TNEO1/e25dU4NmVtM++vyRmV6NhddW6uqeLDi6Nr9Qe2AAAAAAAA --------------ms020806070907020609040801-- From nobody Tue Feb 9 08:21:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3F1AC416 for ; Tue, 9 Feb 2016 08:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmZqbsfc3VfZ for ; Tue, 9 Feb 2016 08:21:04 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879711AC418 for ; Tue, 9 Feb 2016 08:21:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g62so181315980wme.0 for ; Tue, 09 Feb 2016 08:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=beBwIcwZBKx9OYGR4YruVNLfHVDXOdbwMnJ7LhhWZUU=; b=WxhMmhUx23/jtQBdskoXHa+0L8+HZeb3BLD4qzfc0tNJvS5QCBV5YA0pXsgjctnGJN aXH1W9zUdVsmF5EqbEJFmISbOQoxszlN7o+0IylPOxWJNov2diRVNKXmfujWM8zKSsuM fmMymVqQmF9auLADYfxM0UHDP0Lb6oMS1JSg9zD5SKP9vu+QECKPolEyWJ0wz2AdO6cE +C0X1LisG4hlIPo9FPl8bL0BumQSbLSvubqYgix0irZnS7PkkpjnPILp5mSgeBYqBTb6 r61XMmdHlko0eywCfJ6Qn2o9QBuvDqm0VPFFVTCw9LSriboJs+IOpV6NKs3+xFJfAqjj 3E9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=beBwIcwZBKx9OYGR4YruVNLfHVDXOdbwMnJ7LhhWZUU=; b=DsHpRIgCjwzPfvmNI9rgvAC/32251a+GT8Hl0fSo21iKbWFfnxIN9a39xRm41ueYJJ iP8x/nYJ/lzArCkCiHnA+57N08jXz/EzjVC2vzwENyZi1GB4FlaMfubNSMWCjA4yT7uh DnDU35p9oJICysjvF4YwI31AeRRFyrUbGkP7LjDO46cvunN98ulL5FGUNRL2LUS0TUaF xu+UwM19HdNvO1Ery6u3IuONI0UvSmw/R7oCyv5HyzLuMLaW334IJqT+sBATx55Ujoij n5lJXkVAICX4fLPG6swE8lvF5xWvh8DriR3M+M3N/fq4jy3i8TqgxlYRBix4Z+137LM3 SThw== X-Gm-Message-State: AG10YOSb2586f85049KtwyNfkjmH8OrO9NFJXxKPRFsgLeZanj1OlwpiBL7sooRt7yuBPg== X-Received: by 10.194.103.198 with SMTP id fy6mr40746479wjb.48.1455034863147; Tue, 09 Feb 2016 08:21:03 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id e198sm18431363wmd.0.2016.02.09.08.21.01 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 08:21:02 -0800 (PST) To: oauth@ietf.org References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> <9DC45CB4-07D8-4F17-8311-02AD60521379@ve7jtb.com> <56B9FA20.60509@gmail.com> <56BA0F42.5070702@connect2id.com> From: Sergey Beryozkin Message-ID: <56BA11ED.6080109@gmail.com> Date: Tue, 9 Feb 2016 16:21:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BA0F42.5070702@connect2id.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 16:21:06 -0000 Hi Vladimir Thanks for the response, On 09/02/16 16:09, Vladimir Dzhuvinov wrote: > Hi Sergey, > > Yes, HTTP 400 is one way to handle a missing response_type with a > "universal" authz endpoint. > Indeed, looks like it makes sense > Or, you could encode the error in the query string as well as the > fragment, and redirect back to the client. > I'm not sure if that can be done in a 'universal' endpoint case because it is not known if a client is running in the implicit context or code flow context. Though I guess it a client is restricted at the registration time to run only in the code or implicit flows then it will provide a hint... Cheers, Sergey > Vladimir > > > On 09/02/16 16:39, Sergey Beryozkin wrote: >> Hi >> >> OAuth2 spec recommends how to deal with a missing response_type, set >> an error as a query or fragment parameter, depending on whether it is >> the authorization code or implicit flow and redirect. >> >> This implies that authorization code and implicit handlers listen on >> different paths, for example, >> >> code: /code >> implicit: /implicit >> >> so if a response type is missing the handler will know how to set the >> error on the redirect uri, as a query or a fragment..... >> >> However, I'd like to have a single handler, example (from the OIDC core): >> >> "https://server.example.com/authorize" >> >> which will support both the code and implicit flows. >> >> Here, 'response_type' is an obvious hint on what kind of flow is in >> process, however, if it is missing, how will a server know how to >> report a missing response_type error if it uses a shared "/authorize" >> path. >> >> I think in such cases reporting 400 is reasonable. Do you agree ? >> >> Thanks, Sergey >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Tue Feb 9 09:19:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FF1ACD39 for ; Tue, 9 Feb 2016 09:19:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPFJJ0d1aBNe for ; Tue, 9 Feb 2016 09:19:45 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 47E221ACD44 for ; Tue, 9 Feb 2016 09:19:44 -0800 (PST) X-AuditID: 12074422-d6bff700000056c3-c3-56ba1faf0477 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F4.6B.22211.FAF1AB65; Tue, 9 Feb 2016 12:19:43 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u19HJgJQ000768; Tue, 9 Feb 2016 12:19:42 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u19HJeVa022127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2016 12:19:41 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_A26F2EA1-5738-423D-8038-237C35A5F0BC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 9 Feb 2016 12:19:40 -0500 Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT0V0vvyvMYPIpDou90z6xWJx8+4rN gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGWcPb+TtaAlo2LDmiusDYx/orsYOTkkBEwk Zrxfxd7FyMUhJNDGJPH4VSMzSEJIYAOjxLcNWRCJW0wSq84/Yuti5OBgFkiQONeQBVLDK6An 8erWZVYQW1jAW6LrQCMLiM0moCoxfU0LE4jNKRAtseFbMxuIzSKgItHVtowZYoy6RPtJF4gx VhI3uw+xQqyNkri6ciPYCSICOhKPL35jg7hTVmL370dMExj5ZyEcMQvJESA2s4C2xLKFr5kh bE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyM4 pF2UdjD+PKh0iFGAg1GJh/fA5x1hQqyJZcWVuYcYJTmYlER5D0vtChPiS8pPqcxILM6ILyrN SS0+xCjBwawkwiv3ZmeYEG9KYmVValE+TEqag0VJnPfRL6CUQHpiSWp2ampBahFMVoaDQ0mC d4Ic0FDBotT01Iq0zJwShDQTByfIcB6g4WtBaniLCxJzizPTIfKnGBWlxHlTQBICIImM0jy4 XlDKSXh72PQVozjQK8K8p0CqeIDpCq77FdBgJqDBK/5tAxlckoiQkmpgdDzEUxxcyn+63FDM S2vuc5F5Ktw60nmZEUsVvi9NEQ97kjyl/MX2sOxCThNXD5fXUxK/vLeP2eXxztLPU96iOVjO ZQbTtyXzpX22ZnG43Fhy2EbpTo2zXotFPkva+21pkdK3ta8X5YeIZVu99bbx6tmY+YzzF8Pd +p9bNy3axiz45M3O9beVWIozEg21mIuKEwEZD/LaFAMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:19:48 -0000 --Apple-Mail=_A26F2EA1-5738-423D-8038-237C35A5F0BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, thanks for putting this up. I would like to propose for two changes that have been brought up = before: 1) The wholesale removal of section 2, Webfinger lookup.=20 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. =E2=80=94 Justin > On Feb 9, 2016, at 9:09 AM, Mike Jones = wrote: >=20 > We have created the initial working group version of OAuth Discovery = based on draft-jones-oauth-discovery-01, with no normative changes. > =20 > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = > =20 > An HTML-formatted version is also available at: > =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = > =20 > -- Mike > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1534 = and as @selfissued = . > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A26F2EA1-5738-423D-8038-237C35A5F0BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike, thanks for putting this up.


I = would like to propose for two changes that have been brought up = before:

1) The = wholesale removal of section 2, Webfinger lookup. 

2) The changing of = "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 Justin


On Feb 9, 2016, at 9:09 AM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

We have created the = initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.

 

The specification is = available at:

=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00

 

An HTML-formatted = version is also available at:

=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html=

 

         =             &n= bsp;           &nbs= p;            =             -- = Mike

 

P.S.  This notice = was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.

 

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

= --Apple-Mail=_A26F2EA1-5738-423D-8038-237C35A5F0BC-- From nobody Tue Feb 9 14:04:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64E51B2A9C for ; Tue, 9 Feb 2016 14:03:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNgIbFjQlohT for ; Tue, 9 Feb 2016 14:03:57 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFE71B2A9A for ; Tue, 9 Feb 2016 14:03:56 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s68so385202qkh.3 for ; Tue, 09 Feb 2016 14:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7fc2nYgI4DC5htrODVd73tgfZWdUNy5U8E70EE5BzH8=; b=PIy9wOu1LVHSFazLG+YuJCViBKGj9h+l5tx2Ttp+B7TfnZa+F9sLJdsqrPtrsNPlv1 Yy/VjzgE3etwh0+pOOEnNCyeA01WQLeg60HwyeudBCVJjd0Dw+9axM16yc+TxfhF50lK PfNEFwSqqxzBv0vpOTHMfQy2J/kP5bDVsRjcvuODMdslq188mFEQOPMafSOGgsYX/3P5 B4/Q+Z/nCQnl0K7naJMt2c9//XfTeix3tcAot7SCU2mwiEJKVofT0+aroJcjlFaWcsR+ oXwQUTZhc1tN/1SV6Q2cKvI79cTyu25yosnDbWIkSpwIvqzVfUSgqoUwy2+FPrRAj4ui kzyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7fc2nYgI4DC5htrODVd73tgfZWdUNy5U8E70EE5BzH8=; b=Oenx8+5+uVUvrwWaFcLvgkyEi4b5gpyB2P+6NLeprUsdljnNh0GhlrXYTUAD8bgOa1 IowRm35NPWDl26kmRGmVB4DZTePRjwSpCXspaweRuFxGjedPioudOdZMp1Ad00paUQwV oIamdsS6Rxovq+ydiPnG9qOznAerPxNjs+kbp/AjyOE//dokSIIVL1m58kt3eFyz1z5Z koL0q8oqROoXXxbKF7HIIIfjwS+fuRVo9yeEDTSbxl5ccMJqHtteVS/naxNkRCEyue0q ugh2F7sCH7iQ+IyYlrMWhxwPaaF5/wSdGM5BkhJLAj1BvhYp57tCwdYzl68TzSVErcW3 usrQ== X-Gm-Message-State: AG10YOTWpUc4p9aORZ+lI4kmwmsJxjcNvK7k1AxevavXpRoYIbgRytoQwd9+16uDXYI5Dg== X-Received: by 10.55.53.207 with SMTP id c198mr43906756qka.24.1455055435975; Tue, 09 Feb 2016 14:03:55 -0800 (PST) Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id e184sm21986qkb.40.2016.02.09.14.03.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 14:03:55 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1CCAC1AA-4958-4EA9-8112-50E7413043AD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Tue, 9 Feb 2016 19:03:51 -0300 Message-Id: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> References: To: Justin Richer X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:04:00 -0000 --Apple-Mail=_1CCAC1AA-4958-4EA9-8112-50E7413043AD Content-Type: multipart/alternative; boundary="Apple-Mail=_667FE70D-5BC0-4599-A02A-7925F3518FD0" --Apple-Mail=_667FE70D-5BC0-4599-A02A-7925F3518FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If we keep webfinger I don=E2=80=99t think that having a generic OAuth = rel makes sense. It should be up to each API/Protocol to define it=E2=80= =99s own rel value like Connect has done. It is not reasonable to think that a persons ID provider is going to be = the same as the one for calendaring or photo sharing. So I could go two ways with webfinger, leave it out completely, or = leave it in but make it up to the application to define a rel value. I expect that some things using UMA in web-finger would point directly = to the resource and the resource would point the client at the correct = UMA server. The config file name in .well-known could stay as openid-configuration = for historical reasons or we could change it. I think we first need to decide if every protocol/API is going to have = its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? I prefer not to change the file name if we are going for one config = file, but if we do one alias/link is probably not the end of the world, = as I doubt people will ever remove openid-configuration one if they have = it now. John B. =20 > On Feb 9, 2016, at 2:19 PM, Justin Richer wrote: >=20 > Mike, thanks for putting this up. >=20 >=20 > I would like to propose for two changes that have been brought up = before: >=20 > 1) The wholesale removal of section 2, Webfinger lookup.=20 >=20 > 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. >=20 >=20 >=20 > =E2=80=94 Justin >=20 >=20 >> On Feb 9, 2016, at 9:09 AM, Mike Jones > wrote: >>=20 >> We have created the initial working group version of OAuth Discovery = based on draft-jones-oauth-discovery-01, with no normative changes. >> =20 >> The specification is available at: >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >> =20 >> An HTML-formatted version is also available at: >> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >> =20 >> -- Mike >> =20 >> P.S. This notice was also posted at http://self-issued.info/?p=3D1534 = and as @selfissued = . >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_667FE70D-5BC0-4599-A02A-7925F3518FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If we keep webfinger I don=E2=80=99t think that having a = generic OAuth rel makes sense.   It should be up to each = API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, Justin Richer = <jricher@mit.edu> = wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_667FE70D-5BC0-4599-A02A-7925F3518FD0-- --Apple-Mail=_1CCAC1AA-4958-4EA9-8112-50E7413043AD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMDkyMjAzNTFaMCMGCSqGSIb3DQEJBDEWBBQYEp6fQPPCY/K0HBQbRa0E gIoAFjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBu9Y77vYY3seIB9WZREPuWfZimX6Y5fq9RUUBwXc/xcQNmMk4eCgEE YdDIY9C1Ew6QCLgD0Rqr36foyqYUjiRqg/Ug7+ny8fcNrVNlW3uQb4xp/0VthDg/MbEpdA9QqCGD 1yTDm2ZIPGpcOF8kX3HClUTSnm/ePGaFpBcFd3DJLlp2KuL5PuqEbZ8fgGFnuLvdZ4/aDopklqBr hRjdKhjC3aTN3I8HgctlZxeHogc6BZO8riwM9OKQMqSZ/JF0BahJMX7nmKQFqgcI1gTk9atz3U6w fJD5JSa38Oy3HaUAzL2GFlF5tl487LF5p4xBrsSNLqHqT0w5I4qZeXT06Bo/AAAAAAAA --Apple-Mail=_1CCAC1AA-4958-4EA9-8112-50E7413043AD-- From nobody Tue Feb 9 14:19:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5541B2BE9 for ; Tue, 9 Feb 2016 14:19:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E0qMc8pprcN for ; Tue, 9 Feb 2016 14:19:02 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4DA1B2C10 for ; Tue, 9 Feb 2016 14:19:02 -0800 (PST) X-AuditID: 1209190c-4ffff7000000165e-cb-56ba65d4eefa Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 8A.99.05726.4D56AB65; Tue, 9 Feb 2016 17:19:01 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u19MJ0jL032033; Tue, 9 Feb 2016 17:19:00 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u19MIwkJ010437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2016 17:18:59 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A996B329-3DAC-4828-8787-19E0A1739260"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> Date: Tue, 9 Feb 2016 17:18:57 -0500 Message-Id: <0FF7CC5E-3975-4483-8428-3B9718ECFA00@mit.edu> References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0hTYRjmOzvbjmsnTtPyc6bRaUEpmwkOLczyT0n5IwYa+EeP7svNtinn bOYMyugCKtrFW815yaREK0zSvOB10kUojS4MNYMlGUtDJAoNo3OcN+jf+77P7f34XkKk+CpW EkaLFbEWxkRLZLhCGqdSf0DdyQcqJrGY3soFPObVnFcS0/JpWXJUlNDYuIglXO1cliZMTDzB T4lSZLF6ZDLmIjYiLk1meNHUieVUt4O8wltvJQXgZS0oAn4EpKKg84sLKwIyQkFdw2Cbqxf4 mlYAX9fNSHzNOAZrnW5MkPhTJ2HRwCVcqElKA73j78QCSUSVA/i5fYknEbyvEt7upwSOhNoL qx5eWdH6UXHQ6SxbicYpFeyaql/xEVEpsLhnUSpISeoQnGsz+XJ7AGx8PCsVOAE8v6/Ps7p2 COz548FuAMqxaQ3H5jUcK77p8OfkN+Crw+H9u99Fvno/7C9+gP8/3wcLf90U++pd8Nmcc3V+ EN67417lH4bjpfWr/nHQU9kgrgdbmkGI3pyvNjNGE4cy1FwGY7EgVh2pMRutGqS3tQHhC/2C 5J1gdpAeAhQBaDnpjupOVoiZXM5uHgJBBEZvJ+Vh/GhrerbebmA4QyprMyFuCKj4LE9ryxhQ 4pZsC6IDyNDZrmQFqWfs+YjNXqMFEzgdSHqWeIjKZKzoLEI5iF1DdxIEDclhPR+wjUWZKO+M 0WTdgDHCbwhAQs6bLwgcksthzJwx04ePgN3KQHJaACgBMNgs61rhPNPmXFovCOSf5U+G8leq kPPHu6728sYYb9z0t0MwtjIbkLIAtOeGBLvLewfnmSxroSPa0jD8cTokWRfduWw/Zkt0Exfp Eet72fXnqsyJ8gHNqC49qw47ob1QYvNW/Zj67e/Ummp2pB4JYE3+ruMz57oqlhOBMmZM9TS+ Famll52GEmVKxB5d6enq2N1ZSbb4N2Xh0801j0Y7tI7Sed1o0nka5wxMZJiI5Zh/bl+NS3kD AAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:19:05 -0000 --Apple-Mail=_A996B329-3DAC-4828-8787-19E0A1739260 Content-Type: multipart/alternative; boundary="Apple-Mail=_00802A6A-4791-4F97-AC18-AD854B0E781A" --Apple-Mail=_00802A6A-4791-4F97-AC18-AD854B0E781A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Webfinger without a rel=3D doesn=E2=80=99t make much sense for us to = define, does it? What output value is the client going to look for in = the response, then? I=E2=80=99m with John that we should let = applications define their own rel=3D values and therefore leave = webfinger out entirely. I don=E2=80=99t buy the historical compatibility argument here, and keep = in mind I=E2=80=99m an implementer who will need to support both = endpoints if we do split it. I already have a server that supports both = /.well-known/openid-configuration and /.well-known/uma-configuration so = I=E2=80=99m not at all worried about the perceived overhead. If a = protocol like OIDC wants to replicate the information in the OAuth = discovery document, that=E2=80=99s fine. If it wants to instead = reference the OAuth discovery document for the OAuth values, that=E2=80=99= s also fine. But that=E2=80=99s a decision up to the application = protocol that=E2=80=99s using OAuth. It=E2=80=99s much cleaner to define something new and keep it = structurally compatible (or at least not incompatible) with the OIDC = version. =E2=80=94 Justin > On Feb 9, 2016, at 5:03 PM, John Bradley wrote: >=20 > If we keep webfinger I don=E2=80=99t think that having a generic OAuth = rel makes sense. It should be up to each API/Protocol to define it=E2=80= =99s own rel value like Connect has done. >=20 > It is not reasonable to think that a persons ID provider is going to = be the same as the one for calendaring or photo sharing. >=20 > So I could go two ways with webfinger, leave it out completely, or = leave it in but make it up to the application to define a rel value. > I expect that some things using UMA in web-finger would point directly = to the resource and the resource would point the client at the correct = UMA server. >=20 > The config file name in .well-known could stay as openid-configuration = for historical reasons or we could change it. >=20 > I think we first need to decide if every protocol/API is going to have = its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? >=20 > I prefer not to change the file name if we are going for one config = file, but if we do one alias/link is probably not the end of the world, = as I doubt people will ever remove openid-configuration one if they have = it now. >=20 > John B. >=20 >=20 >> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>=20 >> Mike, thanks for putting this up. >>=20 >>=20 >> I would like to propose for two changes that have been brought up = before: >>=20 >> 1) The wholesale removal of section 2, Webfinger lookup. >>=20 >> 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. >>=20 >>=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Feb 9, 2016, at 9:09 AM, Mike Jones > wrote: >>>=20 >>> We have created the initial working group version of OAuth Discovery = based on draft-jones-oauth-discovery-01, with no normative changes. >>>=20 >>> The specification is available at: >>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>=20 >>> An HTML-formatted version is also available at: >>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>=20 >>> -- Mike >>>=20 >>> P.S. This notice was also posted at http://self-issued.info/?p=3D1534= and as @selfissued = . >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_00802A6A-4791-4F97-AC18-AD854B0E781A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Webfinger without a rel=3D doesn=E2=80=99t make much sense = for us to define, does it? What output value is the client going to look = for in the response, then? I=E2=80=99m with John that we should let = applications define their own rel=3D values and therefore leave = webfinger out entirely.


I don=E2=80=99t buy the = historical compatibility argument here, and keep in mind I=E2=80=99m an = implementer who will need to support both endpoints if we do split it. I = already have a server that supports both = /.well-known/openid-configuration and /.well-known/uma-configuration so = I=E2=80=99m not at all worried about the perceived overhead. If a = protocol like OIDC wants to replicate the information in the OAuth = discovery document, that=E2=80=99s fine. If it wants to instead = reference the OAuth discovery document for the OAuth values, that=E2=80=99= s also fine. But that=E2=80=99s a decision up to the application = protocol that=E2=80=99s using OAuth.

It=E2=80=99s much cleaner to define = something new and keep it structurally compatible (or at least not = incompatible) with the OIDC version.

 =E2=80=94 Justin


On = Feb 9, 2016, at 5:03 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

If we keep = webfinger I don=E2=80=99t think that having a generic OAuth rel makes = sense.   It should be up to each API/Protocol to define it=E2=80=99s = own rel value like Connect has done.

It is not reasonable to think that a = persons ID provider is going to be the same as the one for calendaring = or photo sharing.

So I could go two ways with webfinger,  leave it out = completely, or leave it in but make it up to the application to define a = rel value.
I expect that some things using UMA in = web-finger would point directly to the resource and the resource would = point the client at the correct UMA server.

The config file name in .well-known = could stay as openid-configuration for historical = reasons or we could change it.

I = think we first need to decide if every protocol/API is going to have its = own config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


= --Apple-Mail=_00802A6A-4791-4F97-AC18-AD854B0E781A-- --Apple-Mail=_A996B329-3DAC-4828-8787-19E0A1739260 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWumXRAAoJEDPAngkbd+w92FMH+gNCtt/HCVSMWW3iI9YDG/xj ue018/KIWeX0iwOCD7Hhd66Ex29jnK2Rr1Z/wo7P11/PDktvqvMG1O+fmbL5ZZO1 RveJVFOkjmtrbobK30+tqgedMSD8wGiKvKPVhfINmrWi7m3M8dGRJ4+x0mljzI25 TTVjk/FZpB4UoGh2ZdvXQ7RzsiwRej1lSzLknnZQRbq90E4KkCNkW9Zd0x7iHLIy 1+6rQxCQMqssTVZwc7S4iq8gEsLzEssgY9DaGmtYQmtSDUQ+TVcmXmgN8ITZ9E4s 6nhTp7ZJXofzuQNufnOVs4Zmfd8EYEIYlTSlCvdp0k1UTgv/e1S0xscN+Nvt6LQ= =+MI8 -----END PGP SIGNATURE----- --Apple-Mail=_A996B329-3DAC-4828-8787-19E0A1739260-- From nobody Tue Feb 9 14:39:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B06D1B2CE1 for ; Tue, 9 Feb 2016 14:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_92=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Gpwvh9Zxs0 for ; Tue, 9 Feb 2016 14:39:52 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD351ACCED for ; Tue, 9 Feb 2016 14:39:51 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u19Mdnmp012400 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Feb 2016 22:39:49 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u19Mdn8Z024535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2016 22:39:49 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u19MdlIN027312; Tue, 9 Feb 2016 22:39:47 GMT Received: from [10.229.147.29] (/24.244.23.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Feb 2016 14:39:47 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-C008F5DA-1860-4F15-82EE-A565BE8FEAD0 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> Date: Tue, 9 Feb 2016 14:39:45 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> To: John Bradley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:39:54 -0000 --Apple-Mail-C008F5DA-1860-4F15-82EE-A565BE8FEAD0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Another example is to look at scim discovery(in contrast with connect). When asked separately the answers may be different.=20 Asking what is the oauth server for scim is yet another relation. So may be= we need a scheme for oauth where query is rs:someval and optionally an acnt= value to.=20 For example Get ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.co= m Note i probably have the compound query syntax wrong.=20 Phil > On Feb 9, 2016, at 14:03, John Bradley wrote: >=20 > If we keep webfinger I don=E2=80=99t think that having a generic OAuth rel= makes sense. It should be up to each API/Protocol to define it=E2=80=99s o= wn rel value like Connect has done. >=20 > It is not reasonable to think that a persons ID provider is going to be th= e same as the one for calendaring or photo sharing. >=20 > So I could go two ways with webfinger, leave it out completely, or leave i= t in but make it up to the application to define a rel value. > I expect that some things using UMA in web-finger would point directly to t= he resource and the resource would point the client at the correct UMA serve= r. >=20 > The config file name in .well-known could stay as openid-configuration for= historical reasons or we could change it. >=20 > I think we first need to decide if every protocol/API is going to have its= own config file, we are going to get apps to retrieve multiple files, or e= verything is going to go into one config-file and applicatins just add to th= at? >=20 > I prefer not to change the file name if we are going for one config file, b= ut if we do one alias/link is probably not the end of the world, as I doubt p= eople will ever remove openid-configuration one if they have it now. >=20 > John B. >=20 > =20 >> On Feb 9, 2016, at 2:19 PM, Justin Richer wrote: >>=20 >> Mike, thanks for putting this up. >>=20 >>=20 >> I would like to propose for two changes that have been brought up before:= >>=20 >> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>=20 >> 2) The changing of "/.well-known/openid-configuration=E2=80=9D to "/.well= -known/oauth-authorization-server=E2=80=9D or something else not openid-rela= ted. >>=20 >>=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Feb 9, 2016, at 9:09 AM, Mike Jones wro= te: >>>=20 >>> We have created the initial working group version of OAuth Discovery bas= ed on draft-jones-oauth-discovery-01, with no normative changes. >>> =20 >>> The specification is available at: >>> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 >>> =20 >>> An HTML-formatted version is also available at: >>> =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-00.= html >>> =20 >>> -- Mike >>> =20 >>> P.S. This notice was also posted at http://self-issued.info/?p=3D1534 a= nd as @selfissued. >>> =20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-C008F5DA-1860-4F15-82EE-A565BE8FEAD0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Another example is to look at scim dis= covery(in contrast with connect).

When asked separately the answers may be d= ifferent. 

Asking what is the oauth server for scim is yet another rel= ation.  So may be we need a scheme for oauth where query is rs:someval a= nd optionally an acnt value to. 
For example
Get ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&ac= nt:phunt@example.com

Note i probably hav= e the compound query syntax wrong. 

Phil

On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think that havi= ng a generic OAuth rel makes sense.   It should be up to each API/Proto= col to define it=E2=80=99s own rel value like Connect has done.

It is not reasonable to think that a= persons ID provider is going to be the same as the one for calendaring or p= hoto sharing.

So I= could go two ways with webfinger,  leave it out completely, or leave i= t in but make it up to the application to define a rel value.
I expect that some things using UMA in web-finger would point directl= y to the resource and the resource would point the client at the correct UMA= server.

The confi= g file name in .well-known could stay as openid-config= uration for historical reasons or we could change it.

I think we first need to decide if every protocol/API is going to ha= ve its own config file, we are going to get apps to retrieve multi= ple files,  or everything is going to go into one config-file and a= pplicatins just add to that?
I prefer not to c= hange the file name if we are going for one config file, but if we do one al= ias/link is probably not the end of the world, as I doubt people will ever r= emove openid-configuration one if they have it now.

John B.
<= br class=3D"">
 
On Feb 9, 201= 6, at 2:19 PM, Justin Richer <jricher@mit.edu> wrote:

Mike,= thanks for putting this up.

<= br class=3D"">
I would like to propose for two changes that h= ave been brought up before:

1) T= he wholesale removal of section 2, Webfinger lookup. 
2) The changing of "/.well-known/openid-configur= ation=E2=80=9D to "/.well-known/oauth-authorization-server=E2=80=9D or somet= hing else not openid-related.

<= br class=3D"">

 =E2=80=94= Justin


On Feb 9, 2016,= at 9:09 AM, Mike Jones <Mi= chael.Jones@microsoft.com> wrote:

We have created the initial working group version o= f OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative= changes.
 
The specification is availab= le at:
 
An= HTML-formatted version is also available at:
=C2=B7    = ;   http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html=
 
    &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;   -- Mike
=  
P.S.  This= notice was also posted at http://self-issued.info/?p=3D1= 534 and as @selfissued.
 
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/oauth

= _________________________= ______________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/m= ailman/listinfo/oauth

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth
= --Apple-Mail-C008F5DA-1860-4F15-82EE-A565BE8FEAD0-- From nobody Tue Feb 9 14:53:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4506F1B2D60 for ; Tue, 9 Feb 2016 14:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 S4E5NlNFYMGC for ; Tue, 9 Feb 2016 14:52:58 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58FA1ACDD1 for ; Tue, 9 Feb 2016 14:52:57 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id b67so1701204qgb.1 for ; Tue, 09 Feb 2016 14:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LtEAIkM62dzAJW7V9MsPcyJranVpr65vWULXVC41Cr4=; b=HG1xjeSanOiXF/XSVRIq79aRBau9828+gsMnL0OiklXBYRHtoON6rgZlUmAAoLXLDN NmzYNWlQpp/2SV5Mu6BVB0a6zMDwT2bkGT/rEZxsZMHR1Kf8Mp5fCh/8lFVhMreysuBf hjj3ZGx7G50EB9Pi8BQwhcUpNaU1/ihtJXbYXMjd+uI+PwqsURJOi2NbfWDbfXZbN2wa 6blMxVzlox9V6TXkCcYEuf4zKGzp27hn3BaeJyIceMFhwXHdFYGycLEK/MmSaIAy3DqG hGgiXqQnLJsn9IqRElvTQy1T9fsgD7AELxVqcTjFzjNgfiKoXUQjunflJgMxRAaRYWeI jNMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LtEAIkM62dzAJW7V9MsPcyJranVpr65vWULXVC41Cr4=; b=JziRHK5hDN2Iy7XYBdKayBFWH//TYB9ccC8Vr4yvSI3I9vjVD9G4SBxEWPaye+kwze LMdofjXHQkRCeDRPCzdb2oM0HyCs944/r0AUMyinRd5xo672P6uv7eNpVX7f+PjlVHjC OZ03FdP1NHBzoTJs9oRkGqIB3g6VaX4I5FLuk/RtVn0Ooj1R0Y91WMjV8TzSuy8a/wym 0Pt5AT2AO+Q8csrNDOmL0VJT7V6T3bYNgh2EfZA3P1pwsHV+AhhFxd/tItaAraqEn/Xf ITN20RjXFCchypxWI6mRUqsUPvYJ61TUpM0bU3b2Ol6k4f0t1N/T0UZ9hX/6edBGCcdx MKGw== X-Gm-Message-State: AG10YOQ4ZDHMvKsJt/WwqvUKGWI5NnZW8hYdaI4uWH7SB+yIJ+x0q/AOLz/CqYqsCBObhg== X-Received: by 10.140.82.11 with SMTP id g11mr45710308qgd.77.1455058376965; Tue, 09 Feb 2016 14:52:56 -0800 (PST) Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id b201sm89102qhb.48.2016.02.09.14.52.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 14:52:56 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_38CA0FA8-74D6-424D-BFA6-98D2C135B63E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Tue, 9 Feb 2016 19:52:52 -0300 Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> To: "Phil Hunt (IDM)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:53:01 -0000 --Apple-Mail=_38CA0FA8-74D6-424D-BFA6-98D2C135B63E Content-Type: multipart/alternative; boundary="Apple-Mail=_493F2178-FFDF-4504-9323-42831887E3B7" --Apple-Mail=_493F2178-FFDF-4504-9323-42831887E3B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. There are probably multiple ways to do it. I don=E2=80=99t think trying to have a oauth rel and then sub types is = going to make sense to developers. It is also not a good fit for = Webfinger. I also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service. Remember that webfinger is a account alias and may not be the subject = that the SP/RP knows the user as. Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. John B > On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = wrote: >=20 > Another example is to look at scim discovery(in contrast with = connect). >=20 > When asked separately the answers may be different.=20 >=20 > Asking what is the oauth server for scim is yet another relation. So = may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >=20 > For example > Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >=20 > Note i probably have the compound query syntax wrong.=20 >=20 > Phil >=20 > On Feb 9, 2016, at 14:03, John Bradley > wrote: >=20 >> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>=20 >> It is not reasonable to think that a persons ID provider is going to = be the same as the one for calendaring or photo sharing. >>=20 >> So I could go two ways with webfinger, leave it out completely, or = leave it in but make it up to the application to define a rel value. >> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>=20 >> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>=20 >> I think we first need to decide if every protocol/API is going to = have its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? >>=20 >> I prefer not to change the file name if we are going for one config = file, but if we do one alias/link is probably not the end of the world, = as I doubt people will ever remove openid-configuration one if they have = it now. >>=20 >> John B. >>=20 >> =20 >>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>=20 >>> Mike, thanks for putting this up. >>>=20 >>>=20 >>> I would like to propose for two changes that have been brought up = before: >>>=20 >>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>=20 >>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. >>>=20 >>>=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>> On Feb 9, 2016, at 9:09 AM, Mike Jones > wrote: >>>>=20 >>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>> =20 >>>> The specification is available at: >>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>> =20 >>>> An HTML-formatted version is also available at: >>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>> =20 >>>> -- Mike >>>> =20 >>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>> =20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_493F2178-FFDF-4504-9323-42831887E3B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You would define a rel uri for SCIM.   The SCIM entry = can have sub properties if it supported more than one auth type, =  or you could have a SCIM discovery document that the URI points = to.

There are = probably multiple ways to do it.

I don=E2=80=99t think trying to have a = oauth rel and then sub types is going to make sense to developers. =  It is also not a good fit for Webfinger.

I also suspect that SCIM is more = naturally part of a authentication service It may be that the = authentication service points at the SCIM service.

Remember that webfinger = is a account alias and may not be the subject that the SP/RP knows the = user as.

Each = service will need to be thought through for webfinger as the account = identity may mean different things depending on the protocol, and not = every protocol needs per user discovery.

John B
On = Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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

= --Apple-Mail=_493F2178-FFDF-4504-9323-42831887E3B7-- --Apple-Mail=_38CA0FA8-74D6-424D-BFA6-98D2C135B63E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMDkyMjUyNTJaMCMGCSqGSIb3DQEJBDEWBBSH2Fi+eFQeJohyHSDSBGX0 ozFGEjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCixeYJ4pJ+AuqWVN4KkSPafB6F23ZBOBkkYwTc8E8ba+DioyM+wJlN SnV60F6G2Q6lysqiCUGceIexrXfuy49HRoKvOLrxqjYOA6dd9GchJ3fWobDck3XUTn3TP7n1U1D2 S07iFx6lDqlr7xjF55xUoYsyzBEFm6Sl89l3ArfL/jSCqFTTcw1eHeIYm/jwkNuWvE2UtHzU/cm8 cVpECPy7gw6cmk/wsyGf7qGSWaQmibMNWvM3L8KRzUByKpwAi4nVUNZFN/1hrt56YtgoLIYhm013 50BcZpGdgCA01CCMi8BIH/CEU4dK+kgkz9usHWkVKJ2zzuwW/mR/IQqF1W5jAAAAAAAA --Apple-Mail=_38CA0FA8-74D6-424D-BFA6-98D2C135B63E-- From nobody Tue Feb 9 15:03:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EC21B2DA0 for ; Tue, 9 Feb 2016 15:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_92=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeCGokBB1H_I for ; Tue, 9 Feb 2016 15:03:32 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34EA1B2D9E for ; Tue, 9 Feb 2016 15:03:31 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u19N3UND007306 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Feb 2016 23:03:31 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u19N3TWo030501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2016 23:03:29 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u19N3StD014920; Tue, 9 Feb 2016 23:03:29 GMT Received: from [25.83.59.80] (/24.114.39.49) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Feb 2016 15:03:28 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-99C222DB-4273-464C-BF0C-B56037FEF630 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Tue, 9 Feb 2016 15:03:23 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> To: John Bradley X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 23:03:34 -0000 --Apple-Mail-99C222DB-4273-464C-BF0C-B56037FEF630 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The rel for scim returns the endpoint for scim.=20 The rel for oauth returns endpoints for oauth.=20 The query lets the client say i want the endpoint for oauth used for scim.=20= I suppose you could reverse it but then we'll have oauth discovery happening= in different ways across many different specs. One set of considerations is= enough. :-) Phil > On Feb 9, 2016, at 14:52, John Bradley wrote: >=20 > You would define a rel uri for SCIM. The SCIM entry can have sub propert= ies if it supported more than one auth type, or you could have a SCIM disco= very document that the URI points to. >=20 > There are probably multiple ways to do it. >=20 > I don=E2=80=99t think trying to have a oauth rel and then sub types is goi= ng to make sense to developers. It is also not a good fit for Webfinger. >=20 > I also suspect that SCIM is more naturally part of a authentication servic= e It may be that the authentication service points at the SCIM service. >=20 > Remember that webfinger is a account alias and may not be the subject that= the SP/RP knows the user as. >=20 > Each service will need to be thought through for webfinger as the account i= dentity may mean different things depending on the protocol, and not every p= rotocol needs per user discovery. >=20 > John B >> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) wrote:= >>=20 >> Another example is to look at scim discovery(in contrast with connect). >>=20 >> When asked separately the answers may be different.=20 >>=20 >> Asking what is the oauth server for scim is yet another relation. So may= be we need a scheme for oauth where query is rs:someval and optionally an a= cnt value to.=20 >>=20 >> For example >> Get ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example= .com >>=20 >> Note i probably have the compound query syntax wrong.=20 >>=20 >> Phil >>=20 >>> On Feb 9, 2016, at 14:03, John Bradley wrote: >>>=20 >>> If we keep webfinger I don=E2=80=99t think that having a generic OAuth r= el makes sense. It should be up to each API/Protocol to define it=E2=80=99= s own rel value like Connect has done. >>>=20 >>> It is not reasonable to think that a persons ID provider is going to be t= he same as the one for calendaring or photo sharing. >>>=20 >>> So I could go two ways with webfinger, leave it out completely, or leav= e it in but make it up to the application to define a rel value. >>> I expect that some things using UMA in web-finger would point directly t= o the resource and the resource would point the client at the correct UMA se= rver. >>>=20 >>> The config file name in .well-known could stay as openid-configuration f= or historical reasons or we could change it. >>>=20 >>> I think we first need to decide if every protocol/API is going to have i= ts own config file, we are going to get apps to retrieve multiple files, or= everything is going to go into one config-file and applicatins just add to t= hat? >>>=20 >>> I prefer not to change the file name if we are going for one config file= , but if we do one alias/link is probably not the end of the world, as I dou= bt people will ever remove openid-configuration one if they have it now. >>>=20 >>> John B. >>>=20 >>> =20 >>>> On Feb 9, 2016, at 2:19 PM, Justin Richer wrote: >>>>=20 >>>> Mike, thanks for putting this up. >>>>=20 >>>>=20 >>>> I would like to propose for two changes that have been brought up befor= e: >>>>=20 >>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>=20 >>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D to "/.we= ll-known/oauth-authorization-server=E2=80=9D or something else not openid-re= lated. >>>>=20 >>>>=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones w= rote: >>>>>=20 >>>>> We have created the initial working group version of OAuth Discovery b= ased on draft-jones-oauth-discovery-01, with no normative changes. >>>>> =20 >>>>> The specification is available at: >>>>> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 >>>>> =20 >>>>> An HTML-formatted version is also available at: >>>>> =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-0= 0.html >>>>> =20 >>>>> -- Mike >>>>> =20 >>>>> P.S. This notice was also posted at http://self-issued.info/?p=3D1534= and as @selfissued. >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-99C222DB-4273-464C-BF0C-B56037FEF630 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The rel for scim returns the endpoint f= or scim. 

The rel for oauth returns endpoints for oauth. 

The qu= ery lets the client say i want the endpoint for oauth used for scim. 

= I suppose you could reverse it but then we'll have oauth discovery happening= in different ways across many different specs. One set of considerations is= enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <= ve7jtb@ve7jtb.com> wrote:
You would define a rel uri for SCIM.  = ; The SCIM entry can have sub properties if it supported more than one auth t= ype,  or you could have a SCIM discovery document that the URI points t= o.

There are probably mu= ltiple ways to do it.

I don=E2=80=99t think trying to have a oauth rel and then sub types is go= ing to make sense to developers.  It is also not a good fit for Webfing= er.

I also suspect= that SCIM is more naturally part of a authentication service It may be that= the authentication service points at the SCIM service.

Remember that webfinger is a account a= lias and may not be the subject that the SP/RP knows the user as.

Each service will need to be t= hought through for webfinger as the account identity may mean different thin= gs depending on the protocol, and not every protocol needs per user discover= y.

John B
On Fe= b 9, 2016, at 7:39 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

=
Another example is to look at scim discovery(in contrast wit= h connect).

When a= sked separately the answers may be different. 
Asking what is the oauth server for scim i= s yet another relation.  So may be we need a scheme for oauth where que= ry is rs:someval and optionally an acnt value to. 

For example
Get .= /well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com
Note i probably have the compound query sy= ntax wrong. 

Phil

On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think that having a generic OAu= th rel makes sense.   It should be up to each API/Protocol to define it= =E2=80=99s own rel value like Connect has done.

It is not reasonable to think that a persons ID prov= ider is going to be the same as the one for calendaring or photo sharing.

So I could go two wa= ys with webfinger,  leave it out completely, or leave it in but make it= up to the application to define a rel value.
I expect t= hat some things using UMA in web-finger would point directly to the resource= and the resource would point the client at the correct UMA server.

The config file name in .w= ell-known could stay as openid-configuration for histo= rical reasons or we could change it.

I think w= e first need to decide if every protocol/API is going to have its own config= file, we are going to get apps to retrieve multiple files, &= nbsp;or everything is going to go into one config-file and applicatins just a= dd to that?

I prefer not to change the file na= me if we are going for one config file, but if we do one alias/link is proba= bly not the end of the world, as I doubt people will ever remove openid-configuration one if they have it now.

John B.

 
On Feb 9, 2016, at 2= :19 PM, Justin Richer <jric= her@mit.edu> wrote:

Mike, thanks= for putting this up.


I would like to propose for two changes that have bee= n brought up before:

1) The wh= olesale removal of section 2, Webfinger lookup. 

2) The changing of "/.well-known/openid-configuratio= n=E2=80=9D to "/.well-known/oauth-authorization-server=E2=80=9D or something= else not openid-related.



 =E2=80=94 Just= in


On Feb 9, 2016, at 9= :09 AM, Mike Jones <Michael.J= ones@microsoft.com> wrote:

We have created the initial working group version of OAuth= Discovery based on draft-jones-oauth-discovery-01, with no normative change= s.
&nb= sp;
The specification is available at:=
 
An HTML-form= atted version is also available at:
=C2=B7     &n= bsp; = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html
&nb= sp;
     &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp; -- Mike
 
P.S.  This notice wa= s also posted at http://self-issued.info/?p=3D1534 and as @selfissu= ed.
 
____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>

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

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

= --Apple-Mail-99C222DB-4273-464C-BF0C-B56037FEF630-- From nobody Tue Feb 9 15:16:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BAD1B2DE0 for ; Tue, 9 Feb 2016 15:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 R5moOsu06l8Y for ; Tue, 9 Feb 2016 15:16:26 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 6E72B1B2DDD for ; Tue, 9 Feb 2016 15:16:25 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id b35so2145926qge.0 for ; Tue, 09 Feb 2016 15:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GMzP7aldJxWqgkg2BVkhFEnkYY5crYnC4l1CmXvvVbk=; b=hkAsR98LD5TcplfhCwRDyd2UJc3mYjABRpIE2A836Ma1PHhm+ARtchQwNX9V3b5e3x PyvEbXbxjaOW0w+edGtngz7/NuWbyi5hNI8nfNVpfQyVxIw3T4oRe9SC1njQ2m40yKmM a1lxgGtIBzRM3ysKLAf0UHJVTSEfRboTWr6X4GjHJywrE3BA+aIKZ4h4t2QR8XEazezS z+EFvQ7V2d6hbW+5plfHYKffD5R6vhUUpQAM4TOzgOvbuRzQj+xgy/UXHgVm3QTjcoe9 uji17XQposg58ot4gQ/WMYNCGlkNB+9373QeXDcyZOzwFXJc1ZF2pljaHBhPtnGLSfg4 C0Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=GMzP7aldJxWqgkg2BVkhFEnkYY5crYnC4l1CmXvvVbk=; b=D1p44SYIWKI0B7J72DTGchwvJ//PkLjZBCyF69TOyPrRbmpxifs5oT2zP4fGpKhuZa K5ecnIInSWve8SE/LUWK6pUsYCoCJUXVci7ZNq/omBxxjBiMwJTGjblfqTVReyFtJa2B 7nnX2wU8V5lSPWf03CGna8fL++Xh0E3YRZe0psO9mIIJRu/P+3TiXUDcTUQtgBu+hwV5 TcdH4Rmdhx8oJ3/1w8BB22l5iacZ6xIkJLxE9IIRNt/4oVfylwCt65HEywTEF8bLP9es P8WJeWOsaxrr12cXEkLIdZx1CxZ7DQJOTPB2AhKMe4AxlgumZ7HWlqXQy2d8H8T7YDeM UJSA== X-Gm-Message-State: AG10YORdB9PUxnu9yODRwLZ1KwON6GuBZTJ7VsfBwbomp14Vt8OGQm/X4y3v4Eoej73FRg== X-Received: by 10.140.35.115 with SMTP id m106mr44360309qgm.13.1455059784941; Tue, 09 Feb 2016 15:16:24 -0800 (PST) Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id 197sm133531qhr.36.2016.02.09.15.16.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 15:16:24 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7AC81935-0A3A-4463-B9AC-2E92A1576B07"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Tue, 9 Feb 2016 20:16:20 -0300 Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> To: "Phil Hunt (IDM)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 23:16:29 -0000 --Apple-Mail=_7AC81935-0A3A-4463-B9AC-2E92A1576B07 Content-Type: multipart/alternative; boundary="Apple-Mail=_2D62D5DA-A0B7-410A-8F4A-5C2659E6C34C" --Apple-Mail=_2D62D5DA-A0B7-410A-8F4A-5C2659E6C34C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please don=E2=80=99t break the webfinger RFC. If you search for SCIM you can have additional properties returned as = part of the entry, but you only search for one thing. =20 Webfinger is designed to be very simple to implement. In general you = just get back the whole document with all the rel.=20 The query filter is a optional optimization.=20 The JSON in the doc is by rel. > On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) = wrote: >=20 > The rel for scim returns the endpoint for scim.=20 >=20 > The rel for oauth returns endpoints for oauth.=20 >=20 > The query lets the client say i want the endpoint for oauth used for = scim.=20 >=20 > I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >=20 > Phil >=20 > On Feb 9, 2016, at 14:52, John Bradley > wrote: >=20 >> You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. >>=20 >> There are probably multiple ways to do it. >>=20 >> I don=E2=80=99t think trying to have a oauth rel and then sub types = is going to make sense to developers. It is also not a good fit for = Webfinger. >>=20 >> I also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service. >>=20 >> Remember that webfinger is a account alias and may not be the subject = that the SP/RP knows the user as. >>=20 >> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>=20 >> John B >>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: >>>=20 >>> Another example is to look at scim discovery(in contrast with = connect). >>>=20 >>> When asked separately the answers may be different.=20 >>>=20 >>> Asking what is the oauth server for scim is yet another relation. = So may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >>>=20 >>> For example >>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>=20 >>> Note i probably have the compound query syntax wrong.=20 >>>=20 >>> Phil >>>=20 >>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>=20 >>>> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>>>=20 >>>> It is not reasonable to think that a persons ID provider is going = to be the same as the one for calendaring or photo sharing. >>>>=20 >>>> So I could go two ways with webfinger, leave it out completely, or = leave it in but make it up to the application to define a rel value. >>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>=20 >>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>=20 >>>> I think we first need to decide if every protocol/API is going to = have its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? >>>>=20 >>>> I prefer not to change the file name if we are going for one config = file, but if we do one alias/link is probably not the end of the world, = as I doubt people will ever remove openid-configuration one if they have = it now. >>>>=20 >>>> John B. >>>>=20 >>>> =20 >>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>=20 >>>>> Mike, thanks for putting this up. >>>>>=20 >>>>>=20 >>>>> I would like to propose for two changes that have been brought up = before: >>>>>=20 >>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>=20 >>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>=20 >>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>=20 >>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>> =20 >>>>>> The specification is available at: >>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>> =20 >>>>>> An HTML-formatted version is also available at: >>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>> =20 >>>>>> -- Mike >>>>>> =20 >>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>> =20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 --Apple-Mail=_2D62D5DA-A0B7-410A-8F4A-5C2659E6C34C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please don=E2=80=99t break the webfinger RFC.

If you search for SCIM = you can have additional properties returned as part of the entry, but = you only search for one thing.
 
Webfinger is designed to be very simple to implement. =  In general you just get back the whole document with all the = rel. 
The query filter is a optional = optimization. 

The JSON in the doc is by rel.

On = Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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


= --Apple-Mail=_2D62D5DA-A0B7-410A-8F4A-5C2659E6C34C-- --Apple-Mail=_7AC81935-0A3A-4463-B9AC-2E92A1576B07 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMDkyMzE2MjFaMCMGCSqGSIb3DQEJBDEWBBSfU4U6BTwP4M7zmuSDy7U8 asj0sDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBvBOb9EqChnIwOpGPWNoIrwr7kmf1s6nU2AxBSDg2XMxTPFrEmDh6+ YMQIjVyAPm7lcNGtyW8c9eUFUFOJ7YIEP9tVy0aCcDFMIS64Q9lfbXIYySJ01E3OuDT89lijfqZI Lh6lAmxCOzmLJXwon57zC8QPRmaQA/cBy0u//orVlaAUNzvYnOp1a8YdKzWDju4NGYuIHRHg2zoa cxbyi2SG3DnXAbnldI7WztGWVogPhC+Uu8LaUY0qE2EX4MAJUKAcOc3R90WL6JZ88c6KcjNcXPu7 oqJrRqb49lTfFJ5gpJsgG5IgmnGxjD8EoTTNB9tFRkJO62iBwl5VnSdw7ZFVAAAAAAAA --Apple-Mail=_7AC81935-0A3A-4463-B9AC-2E92A1576B07-- From nobody Tue Feb 9 15:24:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD141B2E04 for ; Tue, 9 Feb 2016 15:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 rtLG_vQtnTpX for ; Tue, 9 Feb 2016 15:24:07 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30501B2E05 for ; Tue, 9 Feb 2016 15:24:06 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u19NO4Ze006962 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 9 Feb 2016 23:24:04 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u19NO4Jj023590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 9 Feb 2016 23:24:04 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u19NO3ga008940; Tue, 9 Feb 2016 23:24:03 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Feb 2016 15:24:02 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_19580389-338C-4BB8-BE09-8ABF65FB1524" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Tue, 9 Feb 2016 15:24:01 -0800 Message-Id: <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 23:24:09 -0000 --Apple-Mail=_19580389-338C-4BB8-BE09-8ABF65FB1524 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Huh? Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? Further, having rel=3Doauth lets us define one RFC for all that covers = all the security concerns for oauth discovery. If we do it your way = then every resource that registers its own discovery also has to have an = oauth section that copies the oauth discovery stuff because there is no = longer an oauth discovery relationship. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 9, 2016, at 3:16 PM, John Bradley wrote: >=20 > Please don=E2=80=99t break the webfinger RFC. >=20 > If you search for SCIM you can have additional properties returned as = part of the entry, but you only search for one thing. > =20 > Webfinger is designed to be very simple to implement. In general you = just get back the whole document with all the rel.=20 > The query filter is a optional optimization.=20 >=20 > The JSON in the doc is by rel. >=20 >> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>=20 >> The rel for scim returns the endpoint for scim.=20 >>=20 >> The rel for oauth returns endpoints for oauth.=20 >>=20 >> The query lets the client say i want the endpoint for oauth used for = scim.=20 >>=20 >> I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >>=20 >> Phil >>=20 >> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>=20 >>> You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. >>>=20 >>> There are probably multiple ways to do it. >>>=20 >>> I don=E2=80=99t think trying to have a oauth rel and then sub types = is going to make sense to developers. It is also not a good fit for = Webfinger. >>>=20 >>> I also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service. >>>=20 >>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>=20 >>> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>>=20 >>> John B >>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: >>>>=20 >>>> Another example is to look at scim discovery(in contrast with = connect). >>>>=20 >>>> When asked separately the answers may be different.=20 >>>>=20 >>>> Asking what is the oauth server for scim is yet another relation. = So may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >>>>=20 >>>> For example >>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>=20 >>>> Note i probably have the compound query syntax wrong.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>=20 >>>>> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>>>>=20 >>>>> It is not reasonable to think that a persons ID provider is going = to be the same as the one for calendaring or photo sharing. >>>>>=20 >>>>> So I could go two ways with webfinger, leave it out completely, = or leave it in but make it up to the application to define a rel value. >>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>=20 >>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>=20 >>>>> I think we first need to decide if every protocol/API is going to = have its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>=20 >>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> =20 >>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>=20 >>>>>> Mike, thanks for putting this up. >>>>>>=20 >>>>>>=20 >>>>>> I would like to propose for two changes that have been brought up = before: >>>>>>=20 >>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>=20 >>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>=20 >>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>=20 >>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>> =20 >>>>>>> The specification is available at: >>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>> =20 >>>>>>> An HTML-formatted version is also available at: >>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>> =20 >>>>>>> -- = Mike >>>>>>> =20 >>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >=20 --Apple-Mail=_19580389-338C-4BB8-BE09-8ABF65FB1524 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Huh?

Our = proposals are the opposite of one-another.  In your proposal you = have people querying scim to get oauth.  I=E2=80=99m saying you = query rel=3Dscim to get information about SCIM.  Querying rel=3DSCIM = and receiving OAuth seems bass- ackwards does it not?

Further, having = rel=3Doauth lets us define one RFC for all that covers all the security = concerns for oauth discovery.  If we do it your way then every = resource that registers its own discovery also has to have an oauth = section that copies the oauth discovery stuff because there is no longer = an oauth discovery relationship.




On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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



= --Apple-Mail=_19580389-338C-4BB8-BE09-8ABF65FB1524-- From nobody Tue Feb 9 15:49:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFA61B30A4 for ; Tue, 9 Feb 2016 15:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 FzteCd9T_2jT for ; Tue, 9 Feb 2016 15:49:46 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 E9A681B30A6 for ; Tue, 9 Feb 2016 15:49:45 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id b35so2640207qge.0 for ; Tue, 09 Feb 2016 15:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FpvaUHNQTKokPac4USHnMgfbPG++sYcu9SRDK3SOY+E=; b=TJek58FPG3yFuZDqPTHvM5CvK7ArstVAgN6vOjw/3bv2vNBcvFuehmBuKr21zOo29v Vzsd6e4XGfdWo9GbQfxTpOwzS8Eo7gyIOzmzDHCKFfl4UbXkNFPAD45Cyd/S0RAKX33m 7o5r+2cASGVelCGrRp8HUNN8ZVhSgabrLdMvCVpXQdudj9rB9eb63uC8kZguynaIQHDQ RWNzZ1Z9llzqcA0l5jVQFnGRbKzdDsxJbESkqZMVCnwCvtATJGZcmeOmof6P5XGjBG52 iwx2AT/Zt+qg4CXt1PYpx7NuV0JBqP9spcqUqbn5WOxPqmQvynM1nWFAT3KsLbWRlQxe zVwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FpvaUHNQTKokPac4USHnMgfbPG++sYcu9SRDK3SOY+E=; b=aOlhSiAcsescDCKlbvBt3ihQhx4I/WoDONLp9AxC1Zybdcv04A/nhOvmpAg7ENGCrX elE/zChBrUTPRnE76QFv1n7x4woehX5atTTD+LSYpjVEWLMi3+ZiQE4ZkJY/8yoBDElF R9Vo9ybYVjtlnW2GLqfUcOlfb9PemLw7Nz4QLS5XF/UTRmeG+Ea1TSMzidncYINER5lt DJRBlwgl6wjlDqc9e8FrBIUqzR7cVF33mzK2Q8bCCmVhrfu+EsRnXZnfbFQK1a1DH22e WZgxhExsy8YKg2pcpB15kNghKE8rEVhX1pSvlZPjzbruvpI/R4WXAeKY1UlvEfH6xOSD CpwQ== X-Gm-Message-State: AG10YOT8YnfxpsPjRJW6lN0phAC6kEW4Ltxvulql7e46G2n/XF99U72azsLURwMcjGOY5A== X-Received: by 10.140.220.78 with SMTP id q75mr47160783qhb.77.1455061784765; Tue, 09 Feb 2016 15:49:44 -0800 (PST) Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id t187sm177872qht.39.2016.02.09.15.49.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 15:49:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> Date: Tue, 9 Feb 2016 20:49:39 -0300 Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 23:49:49 -0000 --Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5 Content-Type: multipart/alternative; boundary="Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246" --Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Have a look at https://tools.ietf.org/html/rfc7033 = The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. I think that is going to be more complicated for clients to parse. I think that the difference is how you look at the actors involved. I = think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 So yes we are looking at it from different ends. I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. John B. > On Feb 9, 2016, at 8:24 PM, Phil Hunt wrote: >=20 > Huh? >=20 > Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >=20 > Further, having rel=3Doauth lets us define one RFC for all that covers = all the security concerns for oauth discovery. If we do it your way = then every resource that registers its own discovery also has to have an = oauth section that copies the oauth discovery stuff because there is no = longer an oauth discovery relationship. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>=20 >> Please don=E2=80=99t break the webfinger RFC. >>=20 >> If you search for SCIM you can have additional properties returned as = part of the entry, but you only search for one thing. >> =20 >> Webfinger is designed to be very simple to implement. In general you = just get back the whole document with all the rel.=20 >> The query filter is a optional optimization.=20 >>=20 >> The JSON in the doc is by rel. >>=20 >>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>>=20 >>> The rel for scim returns the endpoint for scim.=20 >>>=20 >>> The rel for oauth returns endpoints for oauth.=20 >>>=20 >>> The query lets the client say i want the endpoint for oauth used for = scim.=20 >>>=20 >>> I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >>>=20 >>> Phil >>>=20 >>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>=20 >>>> You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. >>>>=20 >>>> There are probably multiple ways to do it. >>>>=20 >>>> I don=E2=80=99t think trying to have a oauth rel and then sub types = is going to make sense to developers. It is also not a good fit for = Webfinger. >>>>=20 >>>> I also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service. >>>>=20 >>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>=20 >>>> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>>>=20 >>>> John B >>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: >>>>>=20 >>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>=20 >>>>> When asked separately the answers may be different.=20 >>>>>=20 >>>>> Asking what is the oauth server for scim is yet another relation. = So may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >>>>>=20 >>>>> For example >>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>=20 >>>>> Note i probably have the compound query syntax wrong.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>=20 >>>>>> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>>>>>=20 >>>>>> It is not reasonable to think that a persons ID provider is going = to be the same as the one for calendaring or photo sharing. >>>>>>=20 >>>>>> So I could go two ways with webfinger, leave it out completely, = or leave it in but make it up to the application to define a rel value. >>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>=20 >>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>=20 >>>>>> I think we first need to decide if every protocol/API is going to = have its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>=20 >>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> =20 >>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>=20 >>>>>>> Mike, thanks for putting this up. >>>>>>>=20 >>>>>>>=20 >>>>>>> I would like to propose for two changes that have been brought = up before: >>>>>>>=20 >>>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>>=20 >>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D = to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>=20 >>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>> =20 >>>>>>>> The specification is available at: >>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>> =20 >>>>>>>> An HTML-formatted version is also available at: >>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>> =20 >>>>>>>> -- = Mike >>>>>>>> =20 >>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>> =20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>=20 >=20 --Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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




= --Apple-Mail=_97CB28A2-6543-43E6-B803-9C6090C2E246-- --Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMDkyMzQ5NDBaMCMGCSqGSIb3DQEJBDEWBBRDoFTi6wzW009MiDOMHnN/ /XOihzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBGpJNsGFNetL6Mx/42EGkngIumwp80QBL54RuPkWeWUbyLsM4fDLAn pubHCmKZxqFUkSWU3zv1lt/k4Q50DH9Qr/+2CEw0tCazaLvwZUm+1QNiHcgCfUnBmU/zkHrRoSPN ++39j+/EM17oIAdLRWNTAjD4JdpDAQqQJyBFjI1PSBK+k5uH+CUrVFm2hSf/1nv2yi6tCW/9JZzj FX/Fw7H64q8CGY31EN3gNGCPoEZE6zMo4MPb98YGAF4mkyFCkOjPRWGFKH8c9UgguR1bZL72jlyy VYbR2uT88FzBzsdCyfUcIBAKhhQBWfg2DbJ+sZZ4ANiXKi3+e4bGpRkRvl1aAAAAAAAA --Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5-- From nobody Tue Feb 9 16:20:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C118B1B2A6C for ; Tue, 9 Feb 2016 16:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 iWvF_R5Cqfcu for ; Tue, 9 Feb 2016 16:20:24 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFC31B2A68 for ; Tue, 9 Feb 2016 16:20:24 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1A0KN9W019398 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Feb 2016 00:20:23 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1A0KMic008061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 00:20:22 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1A0KMlw003727; Wed, 10 Feb 2016 00:20:22 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Feb 2016 16:20:21 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Tue, 9 Feb 2016 16:20:17 -0800 Message-Id: <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 00:20:29 -0000 --Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 John, I am following 7033. The rel parameter is not the query it is the sub = set of the resource you want information about. There is nothing complex here. In most cases this would be responded to = by a simple transformation pattern. Correcting my previous example (but showing it in easy to read = form)=E2=80=A6the proper query that returns information for both SCIM = and OAuth endpoints would be: GET /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth= This would return something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json { "subject" : =E2=80=9Chttp://scim.example.com", =20 "links" : [ { "rel" : =E2=80=9Coauth", "href" : "https://oauth.example.com/" } ] } This tells me that the OAuth server used for SCIM at scim.example.com is = at oauth.example.com Note that 7033 has an extension mechanism to define other schemes. E.g. = =E2=80=9Cacct=E2=80=9D is just one scheme. Others can be defined. For = example, =E2=80=9Crs:=E2=80=9D could be registered allowing URIs to be = used for the resource instead of an actual https endpoint (which is also = allowed). GET /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth This would return something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json { "subject" : =E2=80=9Crs:scim", =20 "links" : [ { "rel" : =E2=80=9Coauth", "href" : "https://oauth.example.com/" } ] } This says something different. This says that for scim services the = oauth service is oauth.example.com. The first example actually has more granularity. The second example = does not require the client to know the scim endpoint in advance. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 9, 2016, at 3:49 PM, John Bradley wrote: >=20 > Have a look at > https://tools.ietf.org/html/rfc7033 = >=20 > The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. >=20 > I think that is going to be more complicated for clients to parse. >=20 > I think that the difference is how you look at the actors involved. I = think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 >=20 > So yes we are looking at it from different ends. >=20 > I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. >=20 > John B. >=20 >> On Feb 9, 2016, at 8:24 PM, Phil Hunt > wrote: >>=20 >> Huh? >>=20 >> Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >>=20 >> Further, having rel=3Doauth lets us define one RFC for all that = covers all the security concerns for oauth discovery. If we do it your = way then every resource that registers its own discovery also has to = have an oauth section that copies the oauth discovery stuff because = there is no longer an oauth discovery relationship. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>>=20 >>> Please don=E2=80=99t break the webfinger RFC. >>>=20 >>> If you search for SCIM you can have additional properties returned = as part of the entry, but you only search for one thing. >>> =20 >>> Webfinger is designed to be very simple to implement. In general = you just get back the whole document with all the rel.=20 >>> The query filter is a optional optimization.=20 >>>=20 >>> The JSON in the doc is by rel. >>>=20 >>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>>>=20 >>>> The rel for scim returns the endpoint for scim.=20 >>>>=20 >>>> The rel for oauth returns endpoints for oauth.=20 >>>>=20 >>>> The query lets the client say i want the endpoint for oauth used = for scim.=20 >>>>=20 >>>> I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>>=20 >>>>> You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to. >>>>>=20 >>>>> There are probably multiple ways to do it. >>>>>=20 >>>>> I don=E2=80=99t think trying to have a oauth rel and then sub = types is going to make sense to developers. It is also not a good fit = for Webfinger. >>>>>=20 >>>>> I also suspect that SCIM is more naturally part of a = authentication service It may be that the authentication service points = at the SCIM service. >>>>>=20 >>>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>>=20 >>>>> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>>>>=20 >>>>> John B >>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: >>>>>>=20 >>>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>>=20 >>>>>> When asked separately the answers may be different.=20 >>>>>>=20 >>>>>> Asking what is the oauth server for scim is yet another relation. = So may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 >>>>>>=20 >>>>>> For example >>>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>>=20 >>>>>> Note i probably have the compound query syntax wrong.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>>=20 >>>>>>> If we keep webfinger I don=E2=80=99t think that having a generic = OAuth rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done. >>>>>>>=20 >>>>>>> It is not reasonable to think that a persons ID provider is = going to be the same as the one for calendaring or photo sharing. >>>>>>>=20 >>>>>>> So I could go two ways with webfinger, leave it out completely, = or leave it in but make it up to the application to define a rel value. >>>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>>=20 >>>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>>=20 >>>>>>> I think we first need to decide if every protocol/API is going = to have its own config file, we are going to get apps to retrieve = multiple files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>>=20 >>>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> =20 >>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>>=20 >>>>>>>> Mike, thanks for putting this up. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I would like to propose for two changes that have been brought = up before: >>>>>>>>=20 >>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>>>=20 >>>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D = to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>>=20 >>>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>>> =20 >>>>>>>>> The specification is available at: >>>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>>> =20 >>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>>> =20 >>>>>>>>> -- = Mike >>>>>>>>> =20 >>>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 John,

I = am following 7033.  The rel parameter is not the query it is the = sub set of the resource you want information about.

There is nothing complex = here. In most cases this would be responded to by a simple = transformation pattern.

Correcting my previous example (but showing it in easy to = read form)=E2=80=A6the proper query that returns information for both = SCIM and OAuth endpoints would be:

GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth

This = would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Chttp://scim.example.com",
     =20
       "links" :
       [
         {
           "rel" : =
=E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for = SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension = mechanism to define other schemes. E.g. =E2=80=9Cacct=E2=80=9D is just = one scheme. Others can be defined. For example, =E2=80=9Crs:=E2=80=9D = could be registered allowing URIs to be used for the resource instead of = an actual https endpoint (which is also allowed).

GET = /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth

This would return = something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Crs:scim",
     =20
       "links" :
       [
         {
           "rel" : =E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This = says something different.  This says that for scim services the = oauth service is oauth.example.com.

The first example actually has more = granularity.  The second example does not require the client to = know the scim endpoint in advance.





On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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





= --Apple-Mail=_B02B826D-FADC-4A76-B857-E5BB379A8002-- From nobody Tue Feb 9 16:34:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B752A1B2A6C for ; Tue, 9 Feb 2016 16:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 7PXoz6WUjDyZ for ; Tue, 9 Feb 2016 16:34:07 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABB81B2A68 for ; Tue, 9 Feb 2016 16:34:07 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id y89so3221724qge.2 for ; Tue, 09 Feb 2016 16:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XFbU8eGGf2dvGDK4gWRctPJmL/o0BWEQ2rTVch57kIA=; b=IEc/OOhFazlyp+2YYP9feKbawRF75JBGKZWk2i4QimIKLxkFH16VC2mtJRYr9jwBPd 2IMAxXwkxcnyVxYeeR7biHz7y5sbFiDi6r390SRKSkvkHBbNo2IwfSV/TuXFU4nXXxrr IR/yJdtvENM8ypIMoU/swIsXWG672v4yKlZSrGvy2iz8RMxzPNAbxiVdZ8htrlr8RQEV PadLrbMgP/SsLQ9L8q1paVwz77iYNxBnk0uWa3mEWJfYspAQpqucOV/70dpE7t4qWmT5 tzrMMTna0NHGHrdMVxm/Cw1EcHBFc2FrnkRjoPmSvvpG2oPAdbhW0zHxZIODBWaD/ONc 2vIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XFbU8eGGf2dvGDK4gWRctPJmL/o0BWEQ2rTVch57kIA=; b=VFg0+McU6FtEJ1IBAZfpELFOyNGnIAEQ4ns/U9XNtq+vL6/oTmDxQZuZuzd11UIY47 6m56LES+n4jS75XQjJHBSRvHDEjf6I2xK4xRWw4lGgtcLSrgHQAh0eS2MNAewqvQgi1w uP7s9iqxbZyOrDek2M5PKYchL/s65sbdxQwnLRzugcMlcayfw6+f4od6wnHmUGDTa8fw kCSYSbdMRer1KY0UdC3ahmJfID67260MxVdjg0f+OjIePvTtTN1knwIIafqnb3imz8bA q2b3JyjevSKHq3MbDROgNNoFXgsktBheGxr1GTeG2O8y+8mJi9Qq10KY4qvNnp1lQY2L VdPg== X-Gm-Message-State: AG10YOSlK3miwbTeO+QQXjwfwOIN0iYWw7dK92aBoW0ayY5YOPkWvhB7ncfwG2ccqU+BFQ== X-Received: by 10.140.81.80 with SMTP id e74mr45029225qgd.27.1455064446472; Tue, 09 Feb 2016 16:34:06 -0800 (PST) Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id m2sm246164qhm.33.2016.02.09.16.34.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 16:34:05 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_848D4A19-3C66-4DB1-BEF9-1C779DE8359A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> Date: Tue, 9 Feb 2016 21:34:02 -0300 Message-Id: <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 00:34:11 -0000 --Apple-Mail=_848D4A19-3C66-4DB1-BEF9-1C779DE8359A Content-Type: multipart/alternative; boundary="Apple-Mail=_27FD7FE3-1DCC-4E0F-864B-AC003079292E" --Apple-Mail=_27FD7FE3-1DCC-4E0F-864B-AC003079292E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK I was talking about discovering user services via webfinger, (The way = connect uses it and most other things) and you are talking about using = it to discover things about a server. Your first example had phunt@example.com as the account you were = querying, and that seemed like a user discovery to me. If you are looking up the OAuth config for a server why would you not = just go strait to the .wellknown=20 By the way in your example you would need to run a webfinger server on = scim.example.com to be able to answer the query.=20 looking for .wellknown on examle.com seems more direct. You seem to be looking more for where is the service for the domain = rather than the user. John B. > On Feb 9, 2016, at 9:20 PM, Phil Hunt wrote: >=20 > John, >=20 > I am following 7033. The rel parameter is not the query it is the sub = set of the resource you want information about. >=20 > There is nothing complex here. In most cases this would be responded = to by a simple transformation pattern. >=20 > Correcting my previous example (but showing it in easy to read = form)=E2=80=A6the proper query that returns information for both SCIM = and OAuth endpoints would be: >=20 > GET /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doau= th >=20 > This would return something like: > HTTP/1.1 200 OK > Access-Control-Allow-Origin: * > Content-Type: application/jrd+json >=20 > { > "subject" : =E2=80=9Chttp://scim.example.com = ", > =20 > "links" : > [ > { > "rel" : =E2=80=9Coauth", > "href" : "https://oauth.example.com/ = " > } > ] > } >=20 > This tells me that the OAuth server used for SCIM at scim.example.com = is at oauth.example.com = >=20 > Note that 7033 has an extension mechanism to define other schemes. = E.g. =E2=80=9Cacct=E2=80=9D is just one scheme. Others can be defined. = For example, =E2=80=9Crs:=E2=80=9D could be registered allowing URIs to = be used for the resource instead of an actual https endpoint (which is = also allowed). >=20 > GET /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth >=20 > This would return something like: > HTTP/1.1 200 OK > Access-Control-Allow-Origin: * > Content-Type: application/jrd+json >=20 > { > "subject" : =E2=80=9Crs:scim", > =20 > "links" : > [ > { > "rel" : =E2=80=9Coauth", > "href" : "https://oauth.example.com/ = " > } > ] > } >=20 > This says something different. This says that for scim services the = oauth service is oauth.example.com . >=20 > The first example actually has more granularity. The second example = does not require the client to know the scim endpoint in advance. >=20 >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 9, 2016, at 3:49 PM, John Bradley > wrote: >>=20 >> Have a look at >> https://tools.ietf.org/html/rfc7033 = >>=20 >> The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. >>=20 >> I think that is going to be more complicated for clients to parse. >>=20 >> I think that the difference is how you look at the actors involved. = I think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 >>=20 >> So yes we are looking at it from different ends. >>=20 >> I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. >>=20 >> John B. >>=20 >>> On Feb 9, 2016, at 8:24 PM, Phil Hunt > wrote: >>>=20 >>> Huh? >>>=20 >>> Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >>>=20 >>> Further, having rel=3Doauth lets us define one RFC for all that = covers all the security concerns for oauth discovery. If we do it your = way then every resource that registers its own discovery also has to = have an oauth section that copies the oauth discovery stuff because = there is no longer an oauth discovery relationship. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>>>=20 >>>> Please don=E2=80=99t break the webfinger RFC. >>>>=20 >>>> If you search for SCIM you can have additional properties returned = as part of the entry, but you only search for one thing. >>>> =20 >>>> Webfinger is designed to be very simple to implement. In general = you just get back the whole document with all the rel.=20 >>>> The query filter is a optional optimization.=20 >>>>=20 >>>> The JSON in the doc is by rel. >>>>=20 >>>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>>>>=20 >>>>> The rel for scim returns the endpoint for scim.=20 >>>>>=20 >>>>> The rel for oauth returns endpoints for oauth.=20 >>>>>=20 >>>>> The query lets the client say i want the endpoint for oauth used = for scim.=20 >>>>>=20 >>>>> I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>>>=20 >>>>>> You would define a rel uri for SCIM. The SCIM entry can have = sub properties if it supported more than one auth type, or you could = have a SCIM discovery document that the URI points to. >>>>>>=20 >>>>>> There are probably multiple ways to do it. >>>>>>=20 >>>>>> I don=E2=80=99t think trying to have a oauth rel and then sub = types is going to make sense to developers. It is also not a good fit = for Webfinger. >>>>>>=20 >>>>>> I also suspect that SCIM is more naturally part of a = authentication service It may be that the authentication service points = at the SCIM service. >>>>>>=20 >>>>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>>>=20 >>>>>> Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. >>>>>>=20 >>>>>> John B >>>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = > wrote: >>>>>>>=20 >>>>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>>>=20 >>>>>>> When asked separately the answers may be different.=20 >>>>>>>=20 >>>>>>> Asking what is the oauth server for scim is yet another = relation. So may be we need a scheme for oauth where query is = rs:someval and optionally an acnt value to.=20 >>>>>>>=20 >>>>>>> For example >>>>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>>>=20 >>>>>>> Note i probably have the compound query syntax wrong.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>>>=20 >>>>>>>> If we keep webfinger I don=E2=80=99t think that having a = generic OAuth rel makes sense. It should be up to each API/Protocol to = define it=E2=80=99s own rel value like Connect has done. >>>>>>>>=20 >>>>>>>> It is not reasonable to think that a persons ID provider is = going to be the same as the one for calendaring or photo sharing. >>>>>>>>=20 >>>>>>>> So I could go two ways with webfinger, leave it out = completely, or leave it in but make it up to the application to define a = rel value. >>>>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>>>=20 >>>>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>>>=20 >>>>>>>> I think we first need to decide if every protocol/API is going = to have its own config file, we are going to get apps to retrieve = multiple files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>>>=20 >>>>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>>>=20 >>>>>>>>> Mike, thanks for putting this up. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I would like to propose for two changes that have been brought = up before: >>>>>>>>>=20 >>>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>>>>=20 >>>>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D = to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =E2=80=94 Justin >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>>>=20 >>>>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>>>> =20 >>>>>>>>>> The specification is available at: >>>>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>>>> =20 >>>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>>>> =20 >>>>>>>>>> -- = Mike >>>>>>>>>> =20 >>>>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>>>> =20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_27FD7FE3-1DCC-4E0F-864B-AC003079292E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK I was talking about discovering user services via = webfinger, (The way connect uses it and most other things) and you are = talking about using it to discover things about a server.

Your first example had = phunt@example.com as = the account you were querying, and that seemed like a user discovery to = me.

If you are = looking up the OAuth config for a server why would you not just go = strait to the .wellknown 

By the way in your example you would = need to run a webfinger server on scim.example.com to be able to answer the = query. 

looking for .wellknown on examle.com seems more direct.

You seem to be looking more for where = is the service for the domain rather than the user.


John B.

On Feb 9, 2016, at 9:20 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

John,

I am following 7033. =  The rel parameter is not the query it is the sub set of the = resource you want information about.

There is nothing complex here. In most = cases this would be responded to by a simple transformation = pattern.

Correcting my previous example (but showing it in easy to = read form)=E2=80=A6the proper query that returns information for both = SCIM and OAuth endpoints would be:

GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth

This = would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Chttp://scim.example.com",
     =20
       "links" :
       [
         {
           "rel" : =
=E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for = SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension = mechanism to define other schemes. E.g. =E2=80=9Cacct=E2=80=9D is just = one scheme. Others can be defined. For example, =E2=80=9Crs:=E2=80=9D = could be registered allowing URIs to be used for the resource instead of = an actual https endpoint (which is also allowed).

GET = /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth

This would return = something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Crs:scim",
     =20
       "links" :
       [
         {
           "rel" : =E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This = says something different.  This says that for scim services the = oauth service is oauth.example.com.

The first example actually has more = granularity.  The second example does not require the client to = know the scim endpoint in advance.






On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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






= --Apple-Mail=_27FD7FE3-1DCC-4E0F-864B-AC003079292E-- --Apple-Mail=_848D4A19-3C66-4DB1-BEF9-1C779DE8359A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTAwMDM0MDJaMCMGCSqGSIb3DQEJBDEWBBTOvFl+yd/RwmWwbswoX5ge 5iM/ezCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCrLyiH50ni3EQxrssmj9NR563vD7hziUChbrpMQntqYMoYnnNKGyPC DdHXhhVgUQVqUPifX7JzYABNQ9vPnWm64EubyD8R7bZMxwrLusmQofLCdoymlzN2kFId/aXhlpMQ mnaHAJjDKzO4Cyf5qWqAv+NXQuVCNYziOZy8ToWn5lNzMGPnw+pVIgs5qvOK+oZZ7qaabJvvosWr r/8+CNF4lWFWEIoDRVca0GVzUYrZWsKBeDtOmMqOo5nqu1sPsv75au0NhspM29vLnOAX9NWElqMI 2vJqwlGUEux8GdCXVGhRX3pSjUGVy/YmDPU8l7bYdJbuAhP/kxet5hFFyJMaAAAAAAAA --Apple-Mail=_848D4A19-3C66-4DB1-BEF9-1C779DE8359A-- From nobody Tue Feb 9 18:02:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFC91B351E for ; Tue, 9 Feb 2016 18:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 EaXnDqZ_ayKX for ; Tue, 9 Feb 2016 18:02:13 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2151B3513 for ; Tue, 9 Feb 2016 18:01:04 -0800 (PST) X-AuditID: 1209190e-bcbff7000000091c-ff-56ba99d8ee1a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CC.D0.02332.8D99AB65; Tue, 9 Feb 2016 21:00:56 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u1A20uxN010045; Tue, 9 Feb 2016 21:00:56 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1A20sYv026942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2016 21:00:55 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8D9DCED5-6ABD-4DDC-BDA7-2493E4423B83"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> Date: Tue, 9 Feb 2016 21:00:53 -0500 Message-Id: <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGKsWRmVeSWpSXmKPExsUixG6nrntz5q4wg/WFFiffvmKzWDC/kd1i 9d2/bA7MHkuW/GTy+Pj0FovH7dsbWQKYo7hsUlJzMstSi/TtErgy/vW+Yy5Y1sRccebNdJYG xv1nmboYOTkkBEwktjVeZu1i5OIQEmhjkjiwZhM7hLOBUeLQs3OMEM4tJomOqd9ZQFqEBbwl ug40gtm8AnoSr25BtDMLTGGUWPboNFAHB9BcKYkZ+wVAatgEVCWmr2kBW8cpYCexZN5ONhCb RUBF4uDLFnYQm1nAU+LT9OlQM60kOqd8ZoFYfJpFYsa2V2AJEaCGffseMULcLSux+/cjpgmM ArOQ3DEL2R2zwAYnSRxe1cYOYWtLLFv4mhnC1pTY372cBVNcQ6Lz20RWCFteYvvbOVBxS4nF M29A1dtK3OpbwARh20k8mraIdQEj9ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTS TYygKOSU5NvB+PWg0iFGAQ5GJR7eGya7woRYE8uKK3MPMUpyMCmJ8v7oAQrxJeWnVGYkFmfE F5XmpBYfYlQB2vVow+oLjFIsefl5qUoivMHNQHW8KYmVValF+TBl0hwsSuK8j37tDBMSSE8s Sc1OTS1ILYLJynBwKEnwRswAahQsSk1PrUjLzClBSDNxcB5ilODgARp+eDrI8OKCxNzizHSI /ClGRSlxXkWQZgGQREZpHlwvKHkmvD1s+opRHOgtYd4lIFU8wMQL1/0KaDAT0OAV/7aBDC5J REhJNTAqfQln5cq+wRRTUtJ48WHC6/gNXxT4D3xaWdklxpi9/cPZsoA3N4KFFifr1PY+aDvA uCtVfsVJRRGGB/aBXyYl3jRh38P0cnL/veSyfyEMeh+PTOk4vSOFK+eTxysOpitVUvMbPt17 OkGBJy31yucljmIXXDQm/T1dzsF+s/HxPPfkjbdPPVmtxFKckWioxVxUnAgA/kNUU3kDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 02:02:17 -0000 --Apple-Mail=_8D9DCED5-6ABD-4DDC-BDA7-2493E4423B83 Content-Type: multipart/alternative; boundary="Apple-Mail=_26742459-E7A6-4E04-B938-F21F59BFEACD" --Apple-Mail=_26742459-E7A6-4E04-B938-F21F59BFEACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to John=E2=80=99s point. Webfinger is, as designed, about doing = per-user service discovery. Let=E2=80=99s keep the OAuth service = discovery away from that. What does it mean to find the OAuth server for = a user, anyway? Without the context of a resource protocol, I don=E2=80=99= t think it does. If you already have the domain and you don=E2=80=99t = need to do a transform from a user-identifier, just go straight to = .well-known and have an OAuth service discovery document. I think the current discovery draft has tried much too hard to copy = what=E2=80=99s in OIDC, where it does make sense to use webfinger and = per-user discovery systems in the context of a specific identity = protocol. It=E2=80=99s a great starting place, but I think we decidedly = need to get away from it now. =E2=80=94 Justin > On Feb 9, 2016, at 7:34 PM, John Bradley wrote: >=20 > OK I was talking about discovering user services via webfinger, (The = way connect uses it and most other things) and you are talking about = using it to discover things about a server. >=20 > Your first example had phunt@example.com as = the account you were querying, and that seemed like a user discovery to = me. >=20 > If you are looking up the OAuth config for a server why would you not = just go strait to the .wellknown >=20 > By the way in your example you would need to run a webfinger server on = scim.example.com to be able to answer the = query. >=20 > looking for .wellknown on examle.com seems more = direct. >=20 > You seem to be looking more for where is the service for the domain = rather than the user. >=20 >=20 > John B. >=20 >> On Feb 9, 2016, at 9:20 PM, Phil Hunt > wrote: >>=20 >> John, >>=20 >> I am following 7033. The rel parameter is not the query it is the = sub set of the resource you want information about. >>=20 >> There is nothing complex here. In most cases this would be responded = to by a simple transformation pattern. >>=20 >> Correcting my previous example (but showing it in easy to read = form)=E2=80=A6the proper query that returns information for both SCIM = and OAuth endpoints would be: >>=20 >> GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth = >>=20 >> This would return something like: >> HTTP/1.1 200 OK >> Access-Control-Allow-Origin: * >> Content-Type: application/jrd+json >>=20 >> { >> "subject" : =E2=80=9Chttp://scim.example.com = ", >>=20 >> "links" : >> [ >> { >> "rel" : =E2=80=9Coauth", >> "href" : "https://oauth.example.com/ = " >> } >> ] >> } >>=20 >> This tells me that the OAuth server used for SCIM at scim.example.com = is at oauth.example.com = >>=20 >> Note that 7033 has an extension mechanism to define other schemes. = E.g. =E2=80=9Cacct=E2=80=9D is just one scheme. Others can be defined. = For example, =E2=80=9Crs:=E2=80=9D could be registered allowing URIs to = be used for the resource instead of an actual https endpoint (which is = also allowed). >>=20 >> GET /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth >>=20 >> This would return something like: >> HTTP/1.1 200 OK >> Access-Control-Allow-Origin: * >> Content-Type: application/jrd+json >>=20 >> { >> "subject" : =E2=80=9Crs:scim", >>=20 >> "links" : >> [ >> { >> "rel" : =E2=80=9Coauth", >> "href" : "https://oauth.example.com/ = " >> } >> ] >> } >>=20 >> This says something different. This says that for scim services the = oauth service is oauth.example.com . >>=20 >> The first example actually has more granularity. The second example = does not require the client to know the scim endpoint in advance. >>=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 9, 2016, at 3:49 PM, John Bradley > wrote: >>>=20 >>> Have a look at >>> https://tools.ietf.org/html/rfc7033 = >>>=20 >>> The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. >>>=20 >>> I think that is going to be more complicated for clients to parse. >>>=20 >>> I think that the difference is how you look at the actors involved. = I think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. >>>=20 >>> So yes we are looking at it from different ends. >>>=20 >>> I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. >>>=20 >>> John B. >>>=20 >>>> On Feb 9, 2016, at 8:24 PM, Phil Hunt > wrote: >>>>=20 >>>> Huh? >>>>=20 >>>> Our proposals are the opposite of one-another. In your proposal = you have people querying scim to get oauth. I=E2=80=99m saying you = query rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >>>>=20 >>>> Further, having rel=3Doauth lets us define one RFC for all that = covers all the security concerns for oauth discovery. If we do it your = way then every resource that registers its own discovery also has to = have an oauth section that copies the oauth discovery stuff because = there is no longer an oauth discovery relationship. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com = phil.hunt@oracle.com = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>>>>=20 >>>>> Please don=E2=80=99t break the webfinger RFC. >>>>>=20 >>>>> If you search for SCIM you can have additional properties returned = as part of the entry, but you only search for one thing. >>>>>=20 >>>>> Webfinger is designed to be very simple to implement. In general = you just get back the whole document with all the rel. >>>>> The query filter is a optional optimization. >>>>>=20 >>>>> The JSON in the doc is by rel. >>>>>=20 >>>>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: >>>>>>=20 >>>>>> The rel for scim returns the endpoint for scim. >>>>>>=20 >>>>>> The rel for oauth returns endpoints for oauth. >>>>>>=20 >>>>>> The query lets the client say i want the endpoint for oauth used = for scim. >>>>>>=20 >>>>>> I suppose you could reverse it but then we'll have oauth = discovery happening in different ways across many different specs. One = set of considerations is enough. :-) >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>>>>=20 >>>>>>> You would define a rel uri for SCIM. The SCIM entry can have = sub properties if it supported more than one auth type, or you could = have a SCIM discovery document that the URI points to. >>>>>>>=20 >>>>>>> There are probably multiple ways to do it. >>>>>>>=20 >>>>>>> I don=E2=80=99t think trying to have a oauth rel and then sub = types is going to make sense to developers. It is also not a good fit = for Webfinger. >>>>>>>=20 >>>>>>> I also suspect that SCIM is more naturally part of a = authentication service It may be that the authentication service points = at the SCIM service. >>>>>>>=20 >>>>>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>>>>=20 >>>>>>> Each service will need to be thought through for webfinger as = the account identity may mean different things depending on the = protocol, and not every protocol needs per user discovery. >>>>>>>=20 >>>>>>> John B >>>>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = > wrote: >>>>>>>>=20 >>>>>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>>>>=20 >>>>>>>> When asked separately the answers may be different. >>>>>>>>=20 >>>>>>>> Asking what is the oauth server for scim is yet another = relation. So may be we need a scheme for oauth where query is = rs:someval and optionally an acnt value to. >>>>>>>>=20 >>>>>>>> For example >>>>>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>>>>=20 >>>>>>>> Note i probably have the compound query syntax wrong. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>>>>=20 >>>>>>>>> If we keep webfinger I don=E2=80=99t think that having a = generic OAuth rel makes sense. It should be up to each API/Protocol to = define it=E2=80=99s own rel value like Connect has done. >>>>>>>>>=20 >>>>>>>>> It is not reasonable to think that a persons ID provider is = going to be the same as the one for calendaring or photo sharing. >>>>>>>>>=20 >>>>>>>>> So I could go two ways with webfinger, leave it out = completely, or leave it in but make it up to the application to define a = rel value. >>>>>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>>>>=20 >>>>>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>>>>=20 >>>>>>>>> I think we first need to decide if every protocol/API is going = to have its own config file, we are going to get apps to retrieve = multiple files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>>>>=20 >>>>>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>>>>=20 >>>>>>>>>> Mike, thanks for putting this up. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I would like to propose for two changes that have been = brought up before: >>>>>>>>>>=20 >>>>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup. >>>>>>>>>>=20 >>>>>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D = to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>>>>>=20 >>>>>>>>>>> The specification is available at: >>>>>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>>>>>=20 >>>>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>>>>>=20 >>>>>>>>>>> -- = Mike >>>>>>>>>>>=20 >>>>>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_26742459-E7A6-4E04-B938-F21F59BFEACD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to John=E2=80=99s point. Webfinger is, as designed, about = doing per-user service discovery. Let=E2=80=99s keep the OAuth service = discovery away from that. What does it mean to find the OAuth server for = a user, anyway? Without the context of a resource protocol, I don=E2=80=99= t think it does. If you already have the domain and you don=E2=80=99t = need to do a transform from a user-identifier, just go straight to = .well-known and have an OAuth service discovery document.

I think the current = discovery draft has tried much too hard to copy what=E2=80=99s in OIDC, = where it does make sense to use webfinger and per-user discovery systems = in the context of a specific identity protocol. It=E2=80=99s a great = starting place, but I think we decidedly need to get away from it = now.

 =E2=80=94 Justin

On = Feb 9, 2016, at 7:34 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

OK I was = talking about discovering user services via webfinger, (The way connect = uses it and most other things) and you are talking about using it to = discover things about a server.

Your first example had phunt@example.com as the account you were querying, and = that seemed like a user discovery to me.

If you are looking up the OAuth config = for a server why would you not just go strait to the = .wellknown 

By the way in your example you would need to run a webfinger = server on scim.example.com to be able to answer the = query. 

looking for .wellknown on examle.com seems more direct.

You seem to be looking more for where = is the service for the domain rather than the user.


John B.

On Feb = 9, 2016, at 9:20 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

John,

I am following 7033. =  The rel parameter is not the query it is the sub set of the = resource you want information about.

There is nothing complex here. In most = cases this would be responded to by a simple transformation = pattern.

Correcting my previous example (but showing it in easy to = read form)=E2=80=A6the proper query that returns information for both = SCIM and OAuth endpoints would be:

GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth

This = would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Chttp://scim.example.com",
     =20
       "links" :
       [
         {
           "rel" : =
=E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for = SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension = mechanism to define other schemes. E.g. =E2=80=9Cacct=E2=80=9D is just = one scheme. Others can be defined. For example, =E2=80=9Crs:=E2=80=9D = could be registered allowing URIs to be used for the resource instead of = an actual https endpoint (which is also allowed).

GET = /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth

This would return = something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Crs:scim",
     =20
       "links" :
       [
         {
           "rel" : =E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This = says something different.  This says that for scim services the = oauth service is oauth.example.com.

The first example actually has more = granularity.  The second example does not require the client to = know the scim endpoint in advance.






On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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







= --Apple-Mail=_26742459-E7A6-4E04-B938-F21F59BFEACD-- --Apple-Mail=_8D9DCED5-6ABD-4DDC-BDA7-2493E4423B83 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWupnWAAoJEDPAngkbd+w9lCMH/1HCh9I020DRea+lcn7Zy/U9 bnnQSnKAxJol9L7MIUW2kSVZqPnq8uxKnSmRD6NNrIEQg+LTxBDulVOcAvdd4NFA FVdC5++h/ligB9/vLINEFeuF6+lshvdVbNKemdK2lXjOQ88mFJMoW+E3NIdvMnxh V/fYlaSCZr4AqwhSq80qAoThm8uGLyqxj0gcPY2hu9fFIy6iK/rIu3wkyidbAge6 V2GbiY/Y8ta+XD9BBy+YbFqHNIwI9g/wqPU1P9TaQnfZtGG+MXKpd4w6LSlns4Qy CAZBYp+YCfadpw94bBXJ7CDVNum0Bjq8R1WZiHvqQvUDLkk216hY5stDNnrRuXg= =lbFj -----END PGP SIGNATURE----- --Apple-Mail=_8D9DCED5-6ABD-4DDC-BDA7-2493E4423B83-- From nobody Tue Feb 9 23:59:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF14B1A000A for ; Tue, 9 Feb 2016 23:59:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsKYdZvHmXoH for ; Tue, 9 Feb 2016 23:59:06 -0800 (PST) Received: from p3plsmtpa08-10.prod.phx3.secureserver.net (p3plsmtpa08-10.prod.phx3.secureserver.net [173.201.193.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E87D1A0013 for ; Tue, 9 Feb 2016 23:59:06 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-10.prod.phx3.secureserver.net with id GXz41s00315ZTut01Xz5eo; Wed, 10 Feb 2016 00:59:06 -0700 To: oauth@ietf.org References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> <9DC45CB4-07D8-4F17-8311-02AD60521379@ve7jtb.com> <56B9FA20.60509@gmail.com> <56BA0F42.5070702@connect2id.com> <56BA11ED.6080109@gmail.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <56BAEDC7.4040806@connect2id.com> Date: Wed, 10 Feb 2016 09:59:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BA11ED.6080109@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000405040604090803010204" Archived-At: Subject: Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 07:59:08 -0000 This is a cryptographically signed message in MIME format. --------------ms000405040604090803010204 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/02/16 18:21, Sergey Beryozkin wrote: > Hi Vladimir > > Thanks for the response, > On 09/02/16 16:09, Vladimir Dzhuvinov wrote: >> Hi Sergey, >> >> Yes, HTTP 400 is one way to handle a missing response_type with a >> "universal" authz endpoint. >> > Indeed, looks like it makes sense >> Or, you could encode the error in the query string as well as the >> fragment, and redirect back to the client. >> > I'm not sure if that can be done in a 'universal' endpoint case > because it is not known if a client is running in the implicit context > or code flow context. Though I guess it a client is restricted at the > registration time to run only in the code or implicit flows then it > will provide a hint... If you set both the query and the fragment you'll take care of both flows= :) > > Cheers, Sergey > >> Vladimir >> >> >> On 09/02/16 16:39, Sergey Beryozkin wrote: >>> Hi >>> >>> OAuth2 spec recommends how to deal with a missing response_type, set >>> an error as a query or fragment parameter, depending on whether it is= >>> the authorization code or implicit flow and redirect. >>> >>> This implies that authorization code and implicit handlers listen on >>> different paths, for example, >>> >>> code: /code >>> implicit: /implicit >>> >>> so if a response type is missing the handler will know how to set the= >>> error on the redirect uri, as a query or a fragment..... >>> >>> However, I'd like to have a single handler, example (from the OIDC >>> core): >>> >>> "https://server.example.com/authorize" >>> >>> which will support both the code and implicit flows. >>> >>> Here, 'response_type' is an obvious hint on what kind of flow is in >>> process, however, if it is missing, how will a server know how to >>> report a missing response_type error if it uses a shared "/authorize"= >>> path. >>> >>> I think in such cases reporting 400 is reasonable. Do you agree ? >>> >>> Thanks, Sergey >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms000405040604090803010204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMTAwNzU5MDNaMC8GCSqGSIb3DQEJBDEiBCAkPGg9xeJRXi8hkSb1LW8uzhbXZm94 I07UO6QRfVCdezBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQAFAmSQXtDm TxOVLuvSenGn55jD32KSP4rt2AR+txZBZeJAHCW7kr/Efu5KYTnbkOa1NY6TikoQZqdFpTMa hM1jFwAzr1fKk4fB7fefsq6xyAe+FIkaTv+pkVgHh87+f5+KdxFknFX3HMrXZy2lULOuEIOZ U9lRbdqIXGihwEd1fB4dn0bKQdisSBpwpjxNFpxS5SK1XBtsSwjLIb7ou6xd607a2j3yqFjX GsItdZqE56OHhA5e7ZneTJ1ZBtnWAxxEvmtirqxgBLdySltEo7wECPKWOKjnlzhJ/g+IjCjv 1CQVyG/KwfYp3U9eeGwrBnwX+AbqwxGq8FZVP1aP5iBfAAAAAAAA --------------ms000405040604090803010204-- From nobody Wed Feb 10 00:10:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AF01A0058 for ; Wed, 10 Feb 2016 00:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 5kRK6iaCNsTH for ; Wed, 10 Feb 2016 00:10:14 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B83E1A0052 for ; Wed, 10 Feb 2016 00:10:13 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1A8ACac022153 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Feb 2016 08:10:12 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1A8ABsT017362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 08:10:12 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1A8AA6f029013; Wed, 10 Feb 2016 08:10:11 GMT Received: from [10.0.1.22] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 10 Feb 2016 00:10:10 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A6047B3-A7CE-4A2F-A865-D0038FB4AD8E" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> Date: Wed, 10 Feb 2016 00:10:08 -0800 Message-Id: References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 08:10:19 -0000 --Apple-Mail=_7A6047B3-A7CE-4A2F-A865-D0038FB4AD8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin, The abstract to 7033 says. This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. I am pushing on this because I think we really need to bind the resource = service into discovery somehow. The RS is just as important as the other = oauth endpoints. If a client can be convinced or configured to use a fake resource server = (that proxies the real one), then we have the same problem as a client = being convinced to use a fake token endpoint =E2=80=94 only much worse. I don=E2=80=99t get the big taboo against webfinger here. We don=E2=80=99t= have to use webfinger - but are you arguing for something completely = different? A new protocol? Since OIDC already started the ball rolling = with webfinger, it seems worth while trying to use it. What am I missing here? Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 9, 2016, at 6:00 PM, Justin Richer wrote: >=20 > +1 to John=E2=80=99s point. Webfinger is, as designed, about doing = per-user service discovery. Let=E2=80=99s keep the OAuth service = discovery away from that. What does it mean to find the OAuth server for = a user, anyway? Without the context of a resource protocol, I don=E2=80=99= t think it does. If you already have the domain and you don=E2=80=99t = need to do a transform from a user-identifier, just go straight to = .well-known and have an OAuth service discovery document. >=20 > I think the current discovery draft has tried much too hard to copy = what=E2=80=99s in OIDC, where it does make sense to use webfinger and = per-user discovery systems in the context of a specific identity = protocol. It=E2=80=99s a great starting place, but I think we decidedly = need to get away from it now. >=20 > =E2=80=94 Justin >=20 >> On Feb 9, 2016, at 7:34 PM, John Bradley > wrote: >>=20 >> OK I was talking about discovering user services via webfinger, (The = way connect uses it and most other things) and you are talking about = using it to discover things about a server. >>=20 >> Your first example had phunt@example.com = as the account you were querying, and that seemed like a user discovery = to me. >>=20 >> If you are looking up the OAuth config for a server why would you not = just go strait to the .wellknown=20 >>=20 >> By the way in your example you would need to run a webfinger server = on scim.example.com to be able to answer the = query.=20 >>=20 >> looking for .wellknown on examle.com seems more = direct. >>=20 >> You seem to be looking more for where is the service for the domain = rather than the user. >>=20 >>=20 >> John B. >>=20 >>> On Feb 9, 2016, at 9:20 PM, Phil Hunt > wrote: >>>=20 >>> John, >>>=20 >>> I am following 7033. The rel parameter is not the query it is the = sub set of the resource you want information about. >>>=20 >>> There is nothing complex here. In most cases this would be responded = to by a simple transformation pattern. >>>=20 >>> Correcting my previous example (but showing it in easy to read = form)=E2=80=A6the proper query that returns information for both SCIM = and OAuth endpoints would be: >>>=20 >>> GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth = >>>=20 >>> This would return something like: >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Origin: * >>> Content-Type: application/jrd+json >>>=20 >>> { >>> "subject" : =E2=80=9Chttp://scim.example.com = ", >>> =20 >>> "links" : >>> [ >>> { >>> "rel" : =E2=80=9Coauth", >>> "href" : "https://oauth.example.com/ = " >>> } >>> ] >>> } >>>=20 >>> This tells me that the OAuth server used for SCIM at = scim.example.com is at oauth.example.com = >>>=20 >>> Note that 7033 has an extension mechanism to define other schemes. = E.g. =E2=80=9Cacct=E2=80=9D is just one scheme. Others can be defined. = For example, =E2=80=9Crs:=E2=80=9D could be registered allowing URIs to = be used for the resource instead of an actual https endpoint (which is = also allowed). >>>=20 >>> GET /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth >>>=20 >>> This would return something like: >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Origin: * >>> Content-Type: application/jrd+json >>>=20 >>> { >>> "subject" : =E2=80=9Crs:scim", >>> =20 >>> "links" : >>> [ >>> { >>> "rel" : =E2=80=9Coauth", >>> "href" : "https://oauth.example.com/ = " >>> } >>> ] >>> } >>>=20 >>> This says something different. This says that for scim services the = oauth service is oauth.example.com . >>>=20 >>> The first example actually has more granularity. The second example = does not require the client to know the scim endpoint in advance. >>>=20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 9, 2016, at 3:49 PM, John Bradley > wrote: >>>>=20 >>>> Have a look at >>>> https://tools.ietf.org/html/rfc7033 = >>>>=20 >>>> The way to do what you want would mean having multiple array = objects with the same rel and somehow differentiating them via = properties. >>>>=20 >>>> I think that is going to be more complicated for clients to parse. >>>>=20 >>>> I think that the difference is how you look at the actors involved. = I think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 >>>>=20 >>>> So yes we are looking at it from different ends. >>>>=20 >>>> I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. >>>>=20 >>>> John B. >>>>=20 >>>>> On Feb 9, 2016, at 8:24 PM, Phil Hunt > wrote: >>>>>=20 >>>>> Huh? >>>>>=20 >>>>> Our proposals are the opposite of one-another. In your proposal = you have people querying scim to get oauth. I=E2=80=99m saying you = query rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? >>>>>=20 >>>>> Further, having rel=3Doauth lets us define one RFC for all that = covers all the security concerns for oauth discovery. If we do it your = way then every resource that registers its own discovery also has to = have an oauth section that copies the oauth discovery stuff because = there is no longer an oauth discovery relationship. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: >>>>>>=20 >>>>>> Please don=E2=80=99t break the webfinger RFC. >>>>>>=20 >>>>>> If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one thing. >>>>>> =20 >>>>>> Webfinger is designed to be very simple to implement. In general = you just get back the whole document with all the rel.=20 >>>>>> The query filter is a optional optimization.=20 >>>>>>=20 >>>>>> The JSON in the doc is by rel. >>>>>>=20 >>>>>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) = > wrote: >>>>>>>=20 >>>>>>> The rel for scim returns the endpoint for scim.=20 >>>>>>>=20 >>>>>>> The rel for oauth returns endpoints for oauth.=20 >>>>>>>=20 >>>>>>> The query lets the client say i want the endpoint for oauth used = for scim.=20 >>>>>>>=20 >>>>>>> I suppose you could reverse it but then we'll have oauth = discovery happening in different ways across many different specs. One = set of considerations is enough. :-) >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Feb 9, 2016, at 14:52, John Bradley > wrote: >>>>>>>=20 >>>>>>>> You would define a rel uri for SCIM. The SCIM entry can have = sub properties if it supported more than one auth type, or you could = have a SCIM discovery document that the URI points to. >>>>>>>>=20 >>>>>>>> There are probably multiple ways to do it. >>>>>>>>=20 >>>>>>>> I don=E2=80=99t think trying to have a oauth rel and then sub = types is going to make sense to developers. It is also not a good fit = for Webfinger. >>>>>>>>=20 >>>>>>>> I also suspect that SCIM is more naturally part of a = authentication service It may be that the authentication service points = at the SCIM service. >>>>>>>>=20 >>>>>>>> Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as. >>>>>>>>=20 >>>>>>>> Each service will need to be thought through for webfinger as = the account identity may mean different things depending on the = protocol, and not every protocol needs per user discovery. >>>>>>>>=20 >>>>>>>> John B >>>>>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = > wrote: >>>>>>>>>=20 >>>>>>>>> Another example is to look at scim discovery(in contrast with = connect). >>>>>>>>>=20 >>>>>>>>> When asked separately the answers may be different.=20 >>>>>>>>>=20 >>>>>>>>> Asking what is the oauth server for scim is yet another = relation. So may be we need a scheme for oauth where query is = rs:someval and optionally an acnt value to.=20 >>>>>>>>>=20 >>>>>>>>> For example >>>>>>>>> Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com = >>>>>>>>>=20 >>>>>>>>> Note i probably have the compound query syntax wrong.=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> On Feb 9, 2016, at 14:03, John Bradley > wrote: >>>>>>>>>=20 >>>>>>>>>> If we keep webfinger I don=E2=80=99t think that having a = generic OAuth rel makes sense. It should be up to each API/Protocol to = define it=E2=80=99s own rel value like Connect has done. >>>>>>>>>>=20 >>>>>>>>>> It is not reasonable to think that a persons ID provider is = going to be the same as the one for calendaring or photo sharing. >>>>>>>>>>=20 >>>>>>>>>> So I could go two ways with webfinger, leave it out = completely, or leave it in but make it up to the application to define a = rel value. >>>>>>>>>> I expect that some things using UMA in web-finger would point = directly to the resource and the resource would point the client at the = correct UMA server. >>>>>>>>>>=20 >>>>>>>>>> The config file name in .well-known could stay as = openid-configuration for historical reasons or we could change it. >>>>>>>>>>=20 >>>>>>>>>> I think we first need to decide if every protocol/API is = going to have its own config file, we are going to get apps to retrieve = multiple files, or everything is going to go into one config-file and = applicatins just add to that? >>>>>>>>>>=20 >>>>>>>>>> I prefer not to change the file name if we are going for one = config file, but if we do one alias/link is probably not the end of the = world, as I doubt people will ever remove openid-configuration one if = they have it now. >>>>>>>>>>=20 >>>>>>>>>> John B. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Mike, thanks for putting this up. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I would like to propose for two changes that have been = brought up before: >>>>>>>>>>>=20 >>>>>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup.=20 >>>>>>>>>>>=20 >>>>>>>>>>> 2) The changing of "/.well-known/openid-configuration=E2=80=9D= to "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> =E2=80=94 Justin >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones = > = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> We have created the initial working group version of OAuth = Discovery based on draft-jones-oauth-discovery-01, with no normative = changes. >>>>>>>>>>>> =20 >>>>>>>>>>>> The specification is available at: >>>>>>>>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 = >>>>>>>>>>>> =20 >>>>>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html = >>>>>>>>>>>> =20 >>>>>>>>>>>> = -- Mike >>>>>>>>>>>> =20 >>>>>>>>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1534 = and as @selfissued . >>>>>>>>>>>> =20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_7A6047B3-A7CE-4A2F-A865-D0038FB4AD8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Justin,

The= abstract to 7033 says.

   This specification defines the =
WebFinger protocol, which can be used
   to discover information about people or other entities =
on the
   Internet using standard HTTP methods.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.

I am = pushing on this because I think we really need to bind the resource = service into discovery somehow. The RS is just as important as the other = oauth endpoints.

If a client can be convinced or configured to use a fake = resource server (that proxies the real one), then we have the same = problem as a client being convinced to use a fake token endpoint =E2=80=94= only much worse.

I don=E2=80=99t get the big taboo against webfinger here. We = don=E2=80=99t have to use webfinger - but are you arguing for something = completely different? A new protocol? Since OIDC already started the = ball rolling with webfinger, it seems worth while trying to use = it.

What am I = missing here?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On Feb 9, 2016, at 6:00 PM, Justin Richer <jricher@mit.edu> = wrote:

+1 to John=E2=80= =99s point. Webfinger is, as designed, about doing per-user service = discovery. Let=E2=80=99s keep the OAuth service discovery away from = that. What does it mean to find the OAuth server for a user, anyway? = Without the context of a resource protocol, I don=E2=80=99t think it = does. If you already have the domain and you don=E2=80=99t need to do a = transform from a user-identifier, just go straight to .well-known and = have an OAuth service discovery document.

I think the current discovery draft has = tried much too hard to copy what=E2=80=99s in OIDC, where it does make = sense to use webfinger and per-user discovery systems in the context of = a specific identity protocol. It=E2=80=99s a great starting place, but I = think we decidedly need to get away from it now.

 =E2=80=94 = Justin

On Feb 9, 2016, at 7:34 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:

OK I was = talking about discovering user services via webfinger, (The way connect = uses it and most other things) and you are talking about using it to = discover things about a server.

Your first example had phunt@example.com as the account you were querying, and = that seemed like a user discovery to me.

If you are looking up the OAuth config = for a server why would you not just go strait to the = .wellknown 

By the way in your example you would need to run a webfinger = server on scim.example.com to be able to answer the = query. 

looking for .wellknown on examle.com seems more direct.

You seem to be looking more for where = is the service for the domain rather than the user.


John B.

On Feb = 9, 2016, at 9:20 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

John,

I am following 7033. =  The rel parameter is not the query it is the sub set of the = resource you want information about.

There is nothing complex here. In most = cases this would be responded to by a simple transformation = pattern.

Correcting my previous example (but showing it in easy to = read form)=E2=80=A6the proper query that returns information for both = SCIM and OAuth endpoints would be:

GET = /.well-known/webfinger?resource=3Dhttps://scim.example.com&rel=3Doauth

This = would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Chttp://scim.example.com",
     =20
       "links" :
       [
         {
           "rel" : =
=E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for = SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension = mechanism to define other schemes. E.g. =E2=80=9Cacct=E2=80=9D is just = one scheme. Others can be defined. For example, =E2=80=9Crs:=E2=80=9D = could be registered allowing URIs to be used for the resource instead of = an actual https endpoint (which is also allowed).

GET = /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth

This would return = something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : =E2=80=9Crs:scim",
     =20
       "links" :
       [
         {
           "rel" : =E2=80=9Coauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This = says something different.  This says that for scim services the = oauth service is oauth.example.com.

The first example actually has more = granularity.  The second example does not require the client to = know the scim endpoint in advance.






On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean = having multiple array objects with the same rel and somehow = differentiating them via properties.

I think that is going to be more = complicated for clients to parse.

I think that the difference is how you = look at the actors involved.  I think clients look for a service = and then go from there,  you are advocating that they would look = for a authorization method and then find services that support that = method.   

So yes we are looking at it from different ends.

I don=E2=80=99t know = that defining OAuth genericly at the webfinger level of user discovery = makes sense.   Perhaps for a enterprise custom API environment it = might.

John = B.

On Feb 9, 2016, at 8:24 PM, = Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the = opposite of one-another.  In your proposal you have people querying = scim to get oauth.  I=E2=80=99m saying you query rel=3Dscim to get = information about SCIM.  Querying rel=3DSCIM and receiving OAuth = seems bass- ackwards does it not?

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.





On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Please don=E2=80= =99t break the webfinger RFC.

If you search for SCIM you can have additional properties = returned as part of the entry, but you only search for one = thing.
 
Webfinger is = designed to be very simple to implement.  In general you just get = back the whole document with all the rel. 
The = query filter is a optional optimization. 

The JSON in the doc is by = rel.

On Feb 9, 2016, at 8:03 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim = returns the endpoint for scim. 

The rel for oauth returns endpoints for = oauth. 

The= query lets the client say i want the endpoint for oauth used for = scim. 

I = suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel = uri for SCIM.   The SCIM entry can have sub properties if it = supported more than one auth type,  or you could have a SCIM = discovery document that the URI points to.

There are probably multiple ways to do = it.

I don=E2=80=99= t think trying to have a oauth rel and then sub types is going to make = sense to developers.  It is also not a good fit for = Webfinger.

I = also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service.

Remember that webfinger is a account alias and may not be the = subject that the SP/RP knows the user as.

Each service will need to be thought = through for webfinger as the account identity may mean different things = depending on the protocol, and not every protocol needs per user = discovery.

John = B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

Another example = is to look at scim discovery(in contrast with connect).

When asked separately = the answers may be different. 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

For = example
Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

Note i probably have the = compound query syntax wrong. 

Phil

On Feb 9, 2016, at = 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don=E2=80=99t think = that having a generic OAuth rel makes sense.   It should be up to = each API/Protocol to define it=E2=80=99s own rel value like Connect has = done.

It is not = reasonable to think that a persons ID provider is going to be the same = as the one for calendaring or photo sharing.

So I could go two ways with webfinger, =  leave it out completely, or leave it in but make it up to the = application to define a rel value.
I expect that = some things using UMA in web-finger would point directly to the resource = and the resource would point the client at the correct UMA = server.

The = config file name in .well-known could stay as openid-configuration for historical reasons or we could = change it.

I think we = first need to decide if every protocol/API is going to have its own = config file, we are going to get apps = to retrieve multiple files,  or everything is going = to go into one config-file and applicatins just add to = that?

I prefer not to = change the file name if we are going for one config file, but if we do = one alias/link is probably not the end of the world, as I doubt people = will ever remove openid-configuration one if they have it = now.

John = B.

 
On Feb 9, 2016, at 2:19 PM, = Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes = that have been brought up before:

1) The wholesale removal of section 2, = Webfinger lookup. 

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related.



 =E2=80=94 = Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have = created the initial working group version of OAuth Discovery based on = draft-jones-oauth-discovery-01, with no normative changes.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.htm= l
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This notice was also posted at http://self-issued.info/?p=3D1534 and as @selfissued.
 
_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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








= --Apple-Mail=_7A6047B3-A7CE-4A2F-A865-D0038FB4AD8E-- From nobody Wed Feb 10 02:10:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03191A1A43 for ; Wed, 10 Feb 2016 02:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGisHD_rdmGX for ; Wed, 10 Feb 2016 02:10:05 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00A81A1A45 for ; Wed, 10 Feb 2016 02:10:04 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g62so19553331wme.0 for ; Wed, 10 Feb 2016 02:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=5VRyXFQ1Tx+nvp5Xwv9Ncvso0BpwbT1QF81pPxDqHOc=; b=HUld0pLGnR/TL3uF/nNV+fJEEYzHKcxHSZ0X9JiuxZKQuONUg7hYT5oXNR4zCOEJsK PYfPzk8mHi0mUzAD3fC4Ze8pOcu7NZjDlLye/ys4vSccnM1kcpGH44Wlh8QinmvxS1wJ wpFchMCSvEXdK3rhzhev79yqdvVzSWNqEEnzq7m5ncUpUGhtjEUgfKyONM+vHQPpLaEy 6/9+uX6THULG4YvVbTVs8h1sskPNsHnox/2J0YCwXxlvvDVHmIkMUC/99V0hv3OzBWvR 3+iDYpLyVFbe6+N+yfUWGn6XGIXE6OZ5IZ0rEWeRB29qUxqp/kniwjZZcc3Q9Vc9Y/de o9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=5VRyXFQ1Tx+nvp5Xwv9Ncvso0BpwbT1QF81pPxDqHOc=; b=dIFJWwJysOahmNq+YVCBbmSIB399gLH7eMLis49XwQpbExYIrtcN8oIcPZSKpUaUI2 BZcLZtoj0nemv6cZ27MFagTmznfOkEWvyrKYcTarwW3G8+TUZ6R5SZA2wxYvz4N4JCWz 9VS3SLCFN7TaJcP4lg/QhWnZTMWocLQoNCS4ZrVXdXKb7H3fQPLhmTY8ScRBYql3dMRU 27vM/uGTdo8wuzOJY9YOo0mIZn36R337d8vreAP4nyNSyvHs0rO8rbr7I/Oj0FgU7Muq phZC1mxwoZAM2VcAxF57x+qtuM8Jlz6LKF9uWmrmh4N9+FWfKmvm4vKxNpxwbDO2+ILd eUQw== X-Gm-Message-State: AG10YOT2mMDqHvGkAj2qUDKox/AK4oII4LUJZANY5f9uErLM4oSNTdlze2fXuZt/z3HJ1A== X-Received: by 10.28.130.205 with SMTP id e196mr10413345wmd.34.1455099003590; Wed, 10 Feb 2016 02:10:03 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id x66sm2659665wmb.20.2016.02.10.02.10.02 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 02:10:02 -0800 (PST) To: oauth@ietf.org References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> <9DC45CB4-07D8-4F17-8311-02AD60521379@ve7jtb.com> <56B9FA20.60509@gmail.com> <56BA0F42.5070702@connect2id.com> <56BA11ED.6080109@gmail.com> <56BAEDC7.4040806@connect2id.com> From: Sergey Beryozkin Message-ID: <56BB0C6C.1060507@gmail.com> Date: Wed, 10 Feb 2016 10:09:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BAEDC7.4040806@connect2id.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 10:10:07 -0000 Hi I got it, thanks for clarifying the idea :-) Thanks, Sergey On 10/02/16 07:59, Vladimir Dzhuvinov wrote: > > > On 09/02/16 18:21, Sergey Beryozkin wrote: >> Hi Vladimir >> >> Thanks for the response, >> On 09/02/16 16:09, Vladimir Dzhuvinov wrote: >>> Hi Sergey, >>> >>> Yes, HTTP 400 is one way to handle a missing response_type with a >>> "universal" authz endpoint. >>> >> Indeed, looks like it makes sense >>> Or, you could encode the error in the query string as well as the >>> fragment, and redirect back to the client. >>> >> I'm not sure if that can be done in a 'universal' endpoint case >> because it is not known if a client is running in the implicit context >> or code flow context. Though I guess it a client is restricted at the >> registration time to run only in the code or implicit flows then it >> will provide a hint... > > If you set both the query and the fragment you'll take care of both flows :) >> >> Cheers, Sergey >> >>> Vladimir >>> >>> >>> On 09/02/16 16:39, Sergey Beryozkin wrote: >>>> Hi >>>> >>>> OAuth2 spec recommends how to deal with a missing response_type, set >>>> an error as a query or fragment parameter, depending on whether it is >>>> the authorization code or implicit flow and redirect. >>>> >>>> This implies that authorization code and implicit handlers listen on >>>> different paths, for example, >>>> >>>> code: /code >>>> implicit: /implicit >>>> >>>> so if a response type is missing the handler will know how to set the >>>> error on the redirect uri, as a query or a fragment..... >>>> >>>> However, I'd like to have a single handler, example (from the OIDC >>>> core): >>>> >>>> "https://server.example.com/authorize" >>>> >>>> which will support both the code and implicit flows. >>>> >>>> Here, 'response_type' is an obvious hint on what kind of flow is in >>>> process, however, if it is missing, how will a server know how to >>>> report a missing response_type error if it uses a shared "/authorize" >>>> path. >>>> >>>> I think in such cases reporting 400 is reasonable. Do you agree ? >>>> >>>> Thanks, Sergey >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Wed Feb 10 05:30:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03741B2AA9 for ; Wed, 10 Feb 2016 05:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vcYeVyWXbP6 for ; Wed, 10 Feb 2016 05:30:40 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9C71B2A9E for ; Wed, 10 Feb 2016 05:30:39 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id x1so6576809qkc.1 for ; Wed, 10 Feb 2016 05:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1fVvjqGkFfcK8MtSJDnnAZe4s5DNo/ZGN59RwPQknWY=; b=CE56dS8VjSsJjc8kOwejtjf72CeoYmyDfQ8qDX5TgscgKCd3TjQx7IvKQGHWRIpjoO 0SsnCYobbjn2D+2EtuZhnBAdEH8gFapkQ++FKF5H8Yy4dLjJl2Ga+lW/odVV/ciqkehj BKLzLwV0UOuEFJ223Zeaype/bBuhNtQCfRNIn4K/W+adTGHWzfroHmoCg2yH8MFAgH0V BNTx3DURBYOSoW2VwbKrt4i2ZjyPMZvzQxyK1G6c2k9WOvswxEu5XxGxveUfokb/sSXL zkGvY/qDxz/p+jIeTU5s9/nZ27+griIeEO3hQsB8nFyuTNyQe47rUeTon5BX9y4pj6Th mMkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1fVvjqGkFfcK8MtSJDnnAZe4s5DNo/ZGN59RwPQknWY=; b=AfjPGtw3WU7kSUhWawDklX/ld3dmpyKnsCT6D2p5uAqXwIiN+M2ejNEuQB7HjdhdpP 35Ta9AKnOuNK8KjEYBwNNPFrJRadH3wobX48gh0lwotQykArFnmZY1dYGmAM876Z1dec knhzearBcKwe5yKUoqTQ+cX9oqyE3GqwhlVH+z3rpJjWzP/gQT2nVAskaUI+Dt1wHuiZ M3F6bviC8bysevzf9oIEdYfRXc7pbUA4b5croyIaA+5jq8p88+vXRb0KUA6Ha/EK9cyR ws5EEWrJF/g1nvuOium7lEuFr68AGLUzKi+8k6ZRYHT8nDzrz5r3paDzYLCe0Nn6EXgR /CJg== X-Gm-Message-State: AG10YOTLbfa+sZE4F5PtXw6WjSXQmMllsG3HeJ9P1/tKNI5gZDZ0f8LIEgYdpmvAta+xwQ== X-Received: by 10.55.76.213 with SMTP id z204mr47982283qka.58.1455111038799; Wed, 10 Feb 2016 05:30:38 -0800 (PST) Received: from [192.168.1.68] ([191.115.118.180]) by smtp.gmail.com with ESMTPSA id g130sm1270904qkb.28.2016.02.10.05.30.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Feb 2016 05:30:37 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2E4C1641-1F6D-41B2-9566-F5D15AF03DE1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <56BB0C6C.1060507@gmail.com> Date: Wed, 10 Feb 2016 10:30:27 -0300 Message-Id: References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> <9DC45CB4-07D8-4F17-8311-02AD60521379@ve7jtb.com> <56B9FA20.60509@gmail.com> <56BA0F42.5070702@connect2id.com> <56BA11ED.6080109@gmail.com> <56BAEDC7.4040806@connect2id.com> <56BB0C6C.1060507@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.3112) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:30:43 -0000 --Apple-Mail=_2E4C1641-1F6D-41B2-9566-F5D15AF03DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This trick works for the response types that use the GET POST and = fragment encoded response modes.=20 In the future if we do a Java Script response mode as is being proposed = that might not always be the case. Just a heads up. Regards John B. > On Feb 10, 2016, at 7:09 AM, Sergey Beryozkin = wrote: >=20 > Hi >=20 > I got it, thanks for clarifying the idea :-) >=20 > Thanks, Sergey > On 10/02/16 07:59, Vladimir Dzhuvinov wrote: >>=20 >>=20 >> On 09/02/16 18:21, Sergey Beryozkin wrote: >>> Hi Vladimir >>>=20 >>> Thanks for the response, >>> On 09/02/16 16:09, Vladimir Dzhuvinov wrote: >>>> Hi Sergey, >>>>=20 >>>> Yes, HTTP 400 is one way to handle a missing response_type with a >>>> "universal" authz endpoint. >>>>=20 >>> Indeed, looks like it makes sense >>>> Or, you could encode the error in the query string as well as the >>>> fragment, and redirect back to the client. >>>>=20 >>> I'm not sure if that can be done in a 'universal' endpoint case >>> because it is not known if a client is running in the implicit = context >>> or code flow context. Though I guess it a client is restricted at = the >>> registration time to run only in the code or implicit flows then it >>> will provide a hint... >>=20 >> If you set both the query and the fragment you'll take care of both = flows :) >>>=20 >>> Cheers, Sergey >>>=20 >>>> Vladimir >>>>=20 >>>>=20 >>>> On 09/02/16 16:39, Sergey Beryozkin wrote: >>>>> Hi >>>>>=20 >>>>> OAuth2 spec recommends how to deal with a missing response_type, = set >>>>> an error as a query or fragment parameter, depending on whether it = is >>>>> the authorization code or implicit flow and redirect. >>>>>=20 >>>>> This implies that authorization code and implicit handlers listen = on >>>>> different paths, for example, >>>>>=20 >>>>> code: /code >>>>> implicit: /implicit >>>>>=20 >>>>> so if a response type is missing the handler will know how to set = the >>>>> error on the redirect uri, as a query or a fragment..... >>>>>=20 >>>>> However, I'd like to have a single handler, example (from the OIDC >>>>> core): >>>>>=20 >>>>> "https://server.example.com/authorize" >>>>>=20 >>>>> which will support both the code and implicit flows. >>>>>=20 >>>>> Here, 'response_type' is an obvious hint on what kind of flow is = in >>>>> process, however, if it is missing, how will a server know how to >>>>> report a missing response_type error if it uses a shared = "/authorize" >>>>> path. >>>>>=20 >>>>> I think in such cases reporting 400 is reasonable. Do you agree ? >>>>>=20 >>>>> Thanks, Sergey >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2E4C1641-1F6D-41B2-9566-F5D15AF03DE1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTAxMzMwMjdaMCMGCSqGSIb3DQEJBDEWBBRwocCKaNyG/TAaqpHa7sZA BoHBsDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAOhJLdolYGjJsyVvi09+C1Qa5BvZbDUREyQ5HRdYU4yVL9SVxB8Imx hUhqcTYWu+nXvsnAHDfan1Tre8i2NKovDLbKzkDKDoXi36BwQg2VfK/fLX6JynIKRGxX8bwC6JGD 9COLSlyBB+Leq8MAmis375qRIsAYOxFAMjMadDQtDimDPLbu+QF9Ex6TsanyUE2ZKAhGcMLFoJOZ SyPsnJlZb1jqIScIqlek06yr+xkIvEBmpFgxECRoCKxh8ELEzpuV7Yr5RjEv03RH14z0v7zEoLrG ZNeA+bYseDorF/Tcw1sXYZ2aP9u+ylgyk86XIaREHmY8Zw/W6lW4HFAbSS78AAAAAAAA --Apple-Mail=_2E4C1641-1F6D-41B2-9566-F5D15AF03DE1-- From nobody Wed Feb 10 05:43:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BAC1A886F for ; Wed, 10 Feb 2016 05:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 pLqXa8UuJ8-w for ; Wed, 10 Feb 2016 05:43:25 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F141D1A8A9B for ; Wed, 10 Feb 2016 05:43:24 -0800 (PST) X-AuditID: 12074425-b63ff70000002fb0-80-56bb3dd3b07c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 53.25.12208.3DD3BB65; Wed, 10 Feb 2016 08:40:35 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1ADeYUT021524; Wed, 10 Feb 2016 08:40:34 -0500 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1ADeWi4000891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2016 08:40:33 -0500 To: Phil Hunt References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> From: Justin Richer Message-ID: <56BB3DCA.9070209@mit.edu> Date: Wed, 10 Feb 2016 08:40:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080109090309050101080206" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6noltqtzvMYOJkEYuTb1+xWSyY38hu sfruXzYHZo8lS34yeXx8eovF4/btjSwBzFFcNimpOZllqUX6dglcGdvPfGUvWDiVq+L50S3s DYxr/zB1MXJySAiYSJzd9IO9i5GLQ0igjUni3o+vUM5GRokfi25BObeZJKb0vmEGaREW8Jbo OtDIAmKLCKhIfLt6nRGi6AirxK1DPawgCWYBT4k9zy4wgthsAqoS09e0gO3jFVCT2PxmCzuI zQIUfz/jIliNqECMxMXOI1A1ghInZz4BW8ApYCfRfLWTDWJmmMSH338ZJzDyz0JSNgtJCsI2 k5i3+SEzhC0v0bx1NpDNAWSrSSxrVUIWXsDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83 s0QvNaV0EyM45F1UdzBOOKR0iFGAg1GJh/eGya4wIdbEsuLK3EOMkhxMSqK8+oq7w4T4kvJT KjMSizPii0pzUosPMUpwMCuJ8M60BsrxpiRWVqUW5cOkpDlYlMR5H/3aGSYkkJ5YkpqdmlqQ WgSTleHgUJLg7bQFahQsSk1PrUjLzClBSDNxcIIM5wEaXgVSw1tckJhbnJkOkT/FqCglzpsG khAASWSU5sH1glJSwtvDpq8YxYFeEeZlBqniAaYzuO5XQIOZgAbv+L4LZHBJIkJKqoGx5PWD xPSJM3S/rD7IrLg+3v+qxewLUza9zjH5PtFUcfG5gyozb11sn6eheOrJe7H0ac/zvZYUdf3f /3S/nq+r3FwrruLrrw9fLJpjd3n/6+APm4IK+EwLhQ1K5vp/uLsg6VjGn50a713eHrvzyD1p T4HZuQI3GZ5MxgeFToF1Ty0Ptuybo/r6khJLcUaioRZzUXEiAKP85Y0kAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:43:32 -0000 This is a multi-part message in MIME format. --------------080109090309050101080206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes, it says that because we can't ever talk about people as being the only things in the world. The purpose of webfinger is to take something that's easily human-memorizable, like an email-formatted identifier, and transform it into an HTTPS URL that can be fetched with GET. It's true that you could have an organization or bot or other entity that you want to refer to with a username@domain.ext type of format, sure. But I argue that if you're talking about a resource server, you're likely to already have a URL that you can put in to the .well-known discovery step. You don't need the human-readable transform to do what you're talking about below in any of the use cases, you just need the service discovery document part. Additionally, we all three actually agree about the importance of discovery from a resource server, except that John and I couched that in "knowing the specific API" and having that API define its first-stage discovery process. OIDC used webfinger because it makes sense to have a human-readable identifier for an identity protocol. It probably makes sense to have SCIM define its own webfinger REL as well since you've got entity identifiers all over the place. But it doesn't really make sense for OAuth, and especially not the multi-part resource you're talking about below. And to add just a bit from personal experience, we actually just relaxed and simplified our webfinger implementation so that it returns the same document regardless of what REL you asked for anyway, which is pretty common with the handful of webfinger servers that I've seen in the wild. -- Justin On 2/10/2016 3:10 AM, Phil Hunt wrote: > Justin, > > The abstract to 7033 says. > > This specification defines the WebFinger protocol, which can be used > to discover information about people_or other entities on the Internet_ using standard HTTP methods. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. > > I am pushing on this because I think we really need to bind the > resource service into discovery somehow. The RS is just as important > as the other oauth endpoints. > > If a client can be convinced or configured to use a fake resource > server (that proxies the real one), then we have the same problem as a > client being convinced to use a fake token endpoint — only much worse. > > I don’t get the big taboo against webfinger here. We don’t have to use > webfinger - but are you arguing for something completely different? A > new protocol? Since OIDC already started the ball rolling with > webfinger, it seems worth while trying to use it. > > What am I missing here? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > >> On Feb 9, 2016, at 6:00 PM, Justin Richer > > wrote: >> >> +1 to John’s point. Webfinger is, as designed, about doing per-user >> service discovery. Let’s keep the OAuth service discovery away from >> that. What does it mean to find the OAuth server for a user, anyway? >> Without the context of a resource protocol, I don’t think it does. If >> you already have the domain and you don’t need to do a transform from >> a user-identifier, just go straight to .well-known and have an OAuth >> service discovery document. >> >> I think the current discovery draft has tried much too hard to copy >> what’s in OIDC, where it does make sense to use webfinger and >> per-user discovery systems in the context of a specific identity >> protocol. It’s a great starting place, but I think we decidedly need >> to get away from it now. >> >> — Justin >> >>> On Feb 9, 2016, at 7:34 PM, John Bradley >> > wrote: >>> >>> OK I was talking about discovering user services via webfinger, (The >>> way connect uses it and most other things) and you are talking about >>> using it to discover things about a server. >>> >>> Your first example had phunt@example.com >>> as the account you were querying, and that seemed like a user >>> discovery to me. >>> >>> If you are looking up the OAuth config for a server why would you >>> not just go strait to the .wellknown >>> >>> By the way in your example you would need to run a webfinger server >>> on scim.example.com to be able to answer >>> the query. >>> >>> looking for .wellknown on examle.com seems more >>> direct. >>> >>> You seem to be looking more for where is the service for the domain >>> rather than the user. >>> >>> >>> John B. >>> >>>> On Feb 9, 2016, at 9:20 PM, Phil Hunt >>> > wrote: >>>> >>>> John, >>>> >>>> I am following 7033. The rel parameter is not the query it is the >>>> sub set of the resource you want information about. >>>> >>>> There is nothing complex here. In most cases this would be >>>> responded to by a simple transformation pattern. >>>> >>>> Correcting my previous example (but showing it in easy to read >>>> form)…the proper query that returns information for both SCIM and >>>> OAuth endpoints would be: >>>> >>>> GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth >>>> >>>> This would return something like: >>>> HTTP/1.1 200 OK >>>> Access-Control-Allow-Origin: * >>>> Content-Type: application/jrd+json >>>> >>>> { >>>> "subject" : “http://scim.example.com ", >>>> >>>> "links" : >>>> [ >>>> { >>>> "rel" : “oauth", >>>> "href" : "https://oauth.example.com/" >>>> } >>>> ] >>>> } >>>> >>>> This tells me that the OAuth server used for SCIM at >>>> scim.example.com is at oauth.example.com >>>> >>>> >>>> Note that 7033 has an extension mechanism to define other schemes. >>>> E.g. “acct†is just one scheme. Others can be defined. For example, >>>> “rs:†could be registered allowing URIs to be used for the resource >>>> instead of an actual https endpoint (which is also allowed). >>>> >>>> GET /.well-known/webfinger?resource=rs:scim&rel=oauth >>>> >>>> This would return something like: >>>> HTTP/1.1 200 OK >>>> Access-Control-Allow-Origin: * >>>> Content-Type: application/jrd+json >>>> >>>> { >>>> "subject" : “rs:scim", >>>> >>>> "links" : >>>> [ >>>> { >>>> "rel" : “oauth", >>>> "href" : "https://oauth.example.com/" >>>> } >>>> ] >>>> } >>>> >>>> This says something different. This says that for scim services >>>> the oauth service is oauth.example.com . >>>> >>>> The first example actually has more granularity. The second >>>> example does not require the client to know the scim endpoint in >>>> advance. >>>> >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> >>>> >>>>> On Feb 9, 2016, at 3:49 PM, John Bradley >>>> > wrote: >>>>> >>>>> Have a look at >>>>> https://tools.ietf.org/html/rfc7033 >>>>> >>>>> The way to do what you want would mean having multiple array >>>>> objects with the same rel and somehow differentiating them via >>>>> properties. >>>>> >>>>> I think that is going to be more complicated for clients to parse. >>>>> >>>>> I think that the difference is how you look at the actors >>>>> involved. I think clients look for a service and then go from >>>>> there, you are advocating that they would look for a >>>>> authorization method and then find services that support that method. >>>>> >>>>> So yes we are looking at it from different ends. >>>>> >>>>> I don’t know that defining OAuth genericly at the webfinger level >>>>> of user discovery makes sense. Perhaps for a enterprise custom >>>>> API environment it might. >>>>> >>>>> John B. >>>>> >>>>>> On Feb 9, 2016, at 8:24 PM, Phil Hunt >>>>> > wrote: >>>>>> >>>>>> Huh? >>>>>> >>>>>> Our proposals are the opposite of one-another. In your proposal >>>>>> you have people querying scim to get oauth. I’m saying you query >>>>>> rel=scim to get information about SCIM. Querying rel=SCIM and >>>>>> receiving OAuth seems bass- ackwards does it not? >>>>>> >>>>>> Further, having rel=oauth lets us define one RFC for all that >>>>>> covers all the security concerns for oauth discovery. If we do >>>>>> it your way then every resource that registers its own discovery >>>>>> also has to have an oauth section that copies the oauth discovery >>>>>> stuff because there is no longer an oauth discovery relationship. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 9, 2016, at 3:16 PM, John Bradley >>>>>> > wrote: >>>>>>> >>>>>>> Please don’t break the webfinger RFC. >>>>>>> >>>>>>> If you search for SCIM you can have additional properties >>>>>>> returned as part of the entry, but you only search for one thing. >>>>>>> Webfinger is designed to be very simple to implement. In >>>>>>> general you just get back the whole document with all the rel. >>>>>>> The query filter is a optional optimization. >>>>>>> >>>>>>> The JSON in the doc is by rel. >>>>>>> >>>>>>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) >>>>>>>> > wrote: >>>>>>>> >>>>>>>> The rel for scim returns the endpoint for scim. >>>>>>>> >>>>>>>> The rel for oauth returns endpoints for oauth. >>>>>>>> >>>>>>>> The query lets the client say i want the endpoint for oauth >>>>>>>> used for scim. >>>>>>>> >>>>>>>> I suppose you could reverse it but then we'll have oauth >>>>>>>> discovery happening in different ways across many different >>>>>>>> specs. One set of considerations is enough. :-) >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On Feb 9, 2016, at 14:52, John Bradley >>>>>>> > wrote: >>>>>>>> >>>>>>>>> You would define a rel uri for SCIM. The SCIM entry can have >>>>>>>>> sub properties if it supported more than one auth type, or >>>>>>>>> you could have a SCIM discovery document that the URI points to. >>>>>>>>> >>>>>>>>> There are probably multiple ways to do it. >>>>>>>>> >>>>>>>>> I don’t think trying to have a oauth rel and then sub types is >>>>>>>>> going to make sense to developers. It is also not a good fit >>>>>>>>> for Webfinger. >>>>>>>>> >>>>>>>>> I also suspect that SCIM is more naturally part of a >>>>>>>>> authentication service It may be that the authentication >>>>>>>>> service points at the SCIM service. >>>>>>>>> >>>>>>>>> Remember that webfinger is a account alias and may not be the >>>>>>>>> subject that the SP/RP knows the user as. >>>>>>>>> >>>>>>>>> Each service will need to be thought through for webfinger as >>>>>>>>> the account identity may mean different things depending on >>>>>>>>> the protocol, and not every protocol needs per user discovery. >>>>>>>>> >>>>>>>>> John B >>>>>>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Another example is to look at scim discovery(in contrast with >>>>>>>>>> connect). >>>>>>>>>> >>>>>>>>>> When asked separately the answers may be different. >>>>>>>>>> >>>>>>>>>> Asking what is the oauth server for scim is yet another >>>>>>>>>> relation. So may be we need a scheme for oauth where query >>>>>>>>>> is rs:someval and optionally an acnt value to. >>>>>>>>>> >>>>>>>>>> For example >>>>>>>>>> Get >>>>>>>>>> ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:phunt@example.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note i probably have the compound query syntax wrong. >>>>>>>>>> >>>>>>>>>> Phil >>>>>>>>>> >>>>>>>>>> On Feb 9, 2016, at 14:03, John Bradley >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> If we keep webfinger I don’t think that having a generic >>>>>>>>>>> OAuth rel makes sense. It should be up to each >>>>>>>>>>> API/Protocol to define it’s own rel value like Connect has >>>>>>>>>>> done. >>>>>>>>>>> >>>>>>>>>>> It is not reasonable to think that a persons ID provider is >>>>>>>>>>> going to be the same as the one for calendaring or photo >>>>>>>>>>> sharing. >>>>>>>>>>> >>>>>>>>>>> So I could go two ways with webfinger, leave it out >>>>>>>>>>> completely, or leave it in but make it up to the application >>>>>>>>>>> to define a rel value. >>>>>>>>>>> I expect that some things using UMA in web-finger would >>>>>>>>>>> point directly to the resource and the resource would point >>>>>>>>>>> the client at the correct UMA server. >>>>>>>>>>> >>>>>>>>>>> The config file name in .well-known could stay as >>>>>>>>>>> openid-configuration for historical reasons or we could >>>>>>>>>>> change it. >>>>>>>>>>> >>>>>>>>>>> I think we first need to decide if every protocol/API is >>>>>>>>>>> going to have its own config file, we are going to get apps >>>>>>>>>>> to retrieve multiple files, or everything is going to go >>>>>>>>>>> into one config-file and applicatins just add to that? >>>>>>>>>>> >>>>>>>>>>> I prefer not to change the file name if we are going for one >>>>>>>>>>> config file, but if we do one alias/link is probably not the >>>>>>>>>>> end of the world, as I doubt people will ever remove >>>>>>>>>>> openid-configuration one if they have it now. >>>>>>>>>>> >>>>>>>>>>> John B. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Mike, thanks for putting this up. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I would like to propose for two changes that have been >>>>>>>>>>>> brought up before: >>>>>>>>>>>> >>>>>>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup. >>>>>>>>>>>> >>>>>>>>>>>> 2) The changing of "/.well-known/openid-configuration†to >>>>>>>>>>>> "/.well-known/oauth-authorization-server†or something else >>>>>>>>>>>> not openid-related. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> — Justin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> We have created the initial working group version of OAuth >>>>>>>>>>>>> Discovery based on draft-jones-oauth-discovery-01, with no >>>>>>>>>>>>> normative changes. >>>>>>>>>>>>> The specification is available at: >>>>>>>>>>>>> ·http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 >>>>>>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>>>>>> ·http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html >>>>>>>>>>>>> -- Mike >>>>>>>>>>>>> P.S. This notice was also posted >>>>>>>>>>>>> athttp://self-issued.info/?p=1534and as@selfissued >>>>>>>>>>>>> . >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --------------080109090309050101080206 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yes, it says that because we can't ever talk about people as being the only things in the world. The purpose of webfinger is to take something that's easily human-memorizable, like an email-formatted identifier, and transform it into an HTTPS URL that can be fetched with GET. It's true that you could have an organization or bot or other entity that you want to refer to with a username@domain.ext type of format, sure. But I argue that if you're talking about a resource server, you're likely to already have a URL that you can put in to the .well-known discovery step. You don't need the human-readable transform to do what you're talking about below in any of the use cases, you just need the service discovery document part.

Additionally, we all three actually agree about the importance of discovery from a resource server, except that John and I couched that in "knowing the specific API" and having that API define its first-stage discovery process. OIDC used webfinger because it makes sense to have a human-readable identifier for an identity protocol. It probably makes sense to have SCIM define its own webfinger REL as well since you've got entity identifiers all over the place. But it doesn't really make sense for OAuth, and especially not the multi-part resource you're talking about below.

And to add just a bit from personal experience, we actually just relaxed and simplified our webfinger implementation so that it returns the same document regardless of what REL you asked for anyway, which is pretty common with the handful of webfinger servers that I've seen in the wild.

 -- Justin

On 2/10/2016 3:10 AM, Phil Hunt wrote:
Justin,

The abstract to 7033 says. 

   This specification defines the WebFinger protocol, which can be used
   to discover information about people or other entities on the
   Internet using standard HTTP methods.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.

I am pushing on this because I think we really need to bind the resource service into discovery somehow. The RS is just as important as the other oauth endpoints.

If a client can be convinced or configured to use a fake resource server (that proxies the real one), then we have the same problem as a client being convinced to use a fake token endpoint — only much worse.

I don’t get the big taboo against webfinger here. We don’t have to use webfinger - but are you arguing for something completely different? A new protocol? Since OIDC already started the ball rolling with webfinger, it seems worth while trying to use it.

What am I missing here?

Phil

On Feb 9, 2016, at 6:00 PM, Justin Richer <jricher@mit.edu> wrote:

+1 to John’s point. Webfinger is, as designed, about doing per-user service discovery. Let’s keep the OAuth service discovery away from that. What does it mean to find the OAuth server for a user, anyway? Without the context of a resource protocol, I don’t think it does. If you already have the domain and you don’t need to do a transform from a user-identifier, just go straight to .well-known and have an OAuth service discovery document.

I think the current discovery draft has tried much too hard to copy what’s in OIDC, where it does make sense to use webfinger and per-user discovery systems in the context of a specific identity protocol. It’s a great starting place, but I think we decidedly need to get away from it now.

 — Justin

On Feb 9, 2016, at 7:34 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

OK I was talking about discovering user services via webfinger, (The way connect uses it and most other things) and you are talking about using it to discover things about a server.

Your first example had phunt@example.com as the account you were querying, and that seemed like a user discovery to me.

If you are looking up the OAuth config for a server why would you not just go strait to the .wellknown 

By the way in your example you would need to run a webfinger server on scim.example.com to be able to answer the query. 

looking for .wellknown on examle.com seems more direct.

You seem to be looking more for where is the service for the domain rather than the user.


John B.

On Feb 9, 2016, at 9:20 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

John,

I am following 7033.  The rel parameter is not the query it is the sub set of the resource you want information about.

There is nothing complex here. In most cases this would be responded to by a simple transformation pattern.

Correcting my previous example (but showing it in easy to read form)…the proper query that returns information for both SCIM and OAuth endpoints would be:

GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth

This would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : “http://scim.example.com",
      
       "links" :
       [
         {
           "rel" : “oauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension mechanism to define other schemes. E.g. “acct†is just one scheme. Others can be defined. For example, “rs:†could be registered allowing URIs to be used for the resource instead of an actual https endpoint (which is also allowed).

GET /.well-known/webfinger?resource=rs:scim&rel=oauth

This would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : “rs:scim",
      
       "links" :
       [
         {
           "rel" : “oauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This says something different.  This says that for scim services the oauth service is oauth.example.com.

The first example actually has more granularity.  The second example does not require the client to know the scim endpoint in advance.



On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean having multiple array objects with the same rel and somehow differentiating them via properties.

I think that is going to be more complicated for clients to parse.

I think that the difference is how you look at the actors involved.  I think clients look for a service and then go from there,  you are advocating that they would look for a authorization method and then find services that support that method.   

So yes we are looking at it from different ends.

I don’t know that defining OAuth genericly at the webfinger level of user discovery makes sense.   Perhaps for a enterprise custom API environment it might.

John B.

On Feb 9, 2016, at 8:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the opposite of one-another.  In your proposal you have people querying scim to get oauth.  I’m saying you query rel=scim to get information about SCIM.  Querying rel=SCIM and receiving OAuth seems bass- ackwards does it not?

Further, having rel=oauth lets us define one RFC for all that covers all the security concerns for oauth discovery.  If we do it your way then every resource that registers its own discovery also has to have an oauth section that copies the oauth discovery stuff because there is no longer an oauth discovery relationship.


On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Please don’t break the webfinger RFC.

If you search for SCIM you can have additional properties returned as part of the entry, but you only search for one thing.
 
Webfinger is designed to be very simple to implement.  In general you just get back the whole document with all the rel. 
The query filter is a optional optimization. 

The JSON in the doc is by rel.

On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim returns the endpoint for scim. 

The rel for oauth returns endpoints for oauth. 

The query lets the client say i want the endpoint for oauth used for scim. 

I suppose you could reverse it but then we'll have oauth discovery happening in different ways across many different specs. One set of considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> wrote:

You would define a rel uri for SCIM.   The SCIM entry can have sub properties if it supported more than one auth type,  or you could have a SCIM discovery document that the URI points to.

There are probably multiple ways to do it.

I don’t think trying to have a oauth rel and then sub types is going to make sense to developers.  It is also not a good fit for Webfinger.

I also suspect that SCIM is more naturally part of a authentication service It may be that the authentication service points at the SCIM service.

Remember that webfinger is a account alias and may not be the subject that the SP/RP knows the user as.

Each service will need to be thought through for webfinger as the account identity may mean different things depending on the protocol, and not every protocol needs per user discovery.

John B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Another example is to look at scim discovery(in contrast with connect).

When asked separately the answers may be different. 

Asking what is the oauth server for scim is yet another relation.  So may be we need a scheme for oauth where query is rs:someval and optionally an acnt value to. 

For example
Get ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:phunt@example.com

Note i probably have the compound query syntax wrong. 

Phil

On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don’t think that having a generic OAuth rel makes sense.   It should be up to each API/Protocol to define it’s own rel value like Connect has done.

It is not reasonable to think that a persons ID provider is going to be the same as the one for calendaring or photo sharing.

So I could go two ways with webfinger,  leave it out completely, or leave it in but make it up to the application to define a rel value.
I expect that some things using UMA in web-finger would point directly to the resource and the resource would point the client at the correct UMA server.

The config file name in .well-known could stay as openid-configuration for historical reasons or we could change it.

I think we first need to decide if every protocol/API is going to have its own config file, we are going to get apps to retrieve multiple files,  or everything is going to go into one config-file and applicatins just add to that?

I prefer not to change the file name if we are going for one config file, but if we do one alias/link is probably not the end of the world, as I doubt people will ever remove openid-configuration one if they have it now.

John B.

 
On Feb 9, 2016, at 2:19 PM, Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes that have been brought up before:

1) The wholesale removal of section 2, Webfinger lookup. 

2) The changing of "/.well-known/openid-configuration†to "/.well-known/oauth-authorization-server†or something else not openid-related.



 — Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.
 
The specification is available at:
 
An HTML-formatted version is also available at:
 
                                                          -- Mike
 
P.S.  This notice was also posted at http://self-issued.info/?p=1534 and as @selfissued.
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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









--------------080109090309050101080206-- From nobody Wed Feb 10 10:10:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900471B2E9B for ; Wed, 10 Feb 2016 10:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 JYx0rbtbHSRn for ; Wed, 10 Feb 2016 10:10:38 -0800 (PST) Received: from omr-m002e.mx.aol.com (omr-m002e.mx.aol.com [204.29.186.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68931B2E84 for ; Wed, 10 Feb 2016 10:10:09 -0800 (PST) Received: from mtaout-laa01.mx.aol.com (mtaout-laa01.mx.aol.com [172.27.2.97]) by omr-m002e.mx.aol.com (Outbound Mail Relay) with ESMTP id 8E6DA380009B; Wed, 10 Feb 2016 13:10:08 -0500 (EST) Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-laa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D789738000083; Wed, 10 Feb 2016 13:10:07 -0500 (EST) To: Justin Richer , John Bradley References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> From: George Fletcher Organization: AOL LLC Message-ID: <56BB7CFF.100@aol.com> Date: Wed, 10 Feb 2016 13:10:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> Content-Type: multipart/alternative; boundary="------------000707040108040601040203" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1455127808; bh=oyML6WPGse7HfKKeHugw265dsRQyMlwjnlviWaZc7Dg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=L2+yVGfYVsPNvQenHpnEnmPJ1/Njf1bPgnwAgA7CNwNhc1jiz9wohKUEJT5zLqsSS oUbqdge4ZqHnbLja7a89mY7J8HMMfq37n4v8UKPbtWRU4DNEEv7sLF7YM+4dMIZT96 MvQT/FA5RQ9nImynWvGet2QIIMo7ivCl5d8KnahM= x-aol-sid: 3039ac1b026156bb7cff18dc X-AOL-IP: 10.172.102.179 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:10:43 -0000 This is a multi-part message in MIME format. --------------000707040108040601040203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have to disagree that Webfinger is just about *per-user* service discovery. It can definitely be used that way, but even in the spec there is the example of finding the meta data about a resource which includes in the JSON response a "rel":"author". Which means webfinger is designed for queries such as "who is the author of this webpage". GET /.well-known/webfinger?resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314&rel=author I do agree that OAuth should focus on the details of the discovery document and possibly its location within .well-known. Thanks, George On 2/9/16 9:00 PM, Justin Richer wrote: > +1 to John’s point. Webfinger is, as designed, about doing per-user > service discovery. Let’s keep the OAuth service discovery away from > that. What does it mean to find the OAuth server for a user, anyway? > Without the context of a resource protocol, I don’t think it does. If > you already have the domain and you don’t need to do a transform from > a user-identifier, just go straight to .well-known and have an OAuth > service discovery document. > > I think the current discovery draft has tried much too hard to copy > what’s in OIDC, where it does make sense to use webfinger and per-user > discovery systems in the context of a specific identity protocol. It’s > a great starting place, but I think we decidedly need to get away from > it now. > > — Justin > >> On Feb 9, 2016, at 7:34 PM, John Bradley > > wrote: >> >> OK I was talking about discovering user services via webfinger, (The >> way connect uses it and most other things) and you are talking about >> using it to discover things about a server. >> >> Your first example had phunt@example.com >> as the account you were querying, and that seemed like a user >> discovery to me. >> >> If you are looking up the OAuth config for a server why would you not >> just go strait to the .wellknown >> >> By the way in your example you would need to run a webfinger server >> on scim.example.com to be able to answer >> the query. >> >> looking for .wellknown on examle.com seems more >> direct. >> >> You seem to be looking more for where is the service for the domain >> rather than the user. >> >> >> John B. >> >>> On Feb 9, 2016, at 9:20 PM, Phil Hunt >> > wrote: >>> >>> John, >>> >>> I am following 7033. The rel parameter is not the query it is the >>> sub set of the resource you want information about. >>> >>> There is nothing complex here. In most cases this would be responded >>> to by a simple transformation pattern. >>> >>> Correcting my previous example (but showing it in easy to read >>> form)…the proper query that returns information for both SCIM and >>> OAuth endpoints would be: >>> >>> GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth >>> >>> This would return something like: >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Origin: * >>> Content-Type: application/jrd+json >>> >>> { >>> "subject" : “http://scim.example.com ", >>> >>> "links" : >>> [ >>> { >>> "rel" : “oauth", >>> "href" : "https://oauth.example.com/" >>> } >>> ] >>> } >>> >>> This tells me that the OAuth server used for SCIM at >>> scim.example.com is at oauth.example.com >>> >>> >>> Note that 7033 has an extension mechanism to define other schemes. >>> E.g. “acct†is just one scheme. Others can be defined. For example, >>> “rs:†could be registered allowing URIs to be used for the resource >>> instead of an actual https endpoint (which is also allowed). >>> >>> GET /.well-known/webfinger?resource=rs:scim&rel=oauth >>> >>> This would return something like: >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Origin: * >>> Content-Type: application/jrd+json >>> >>> { >>> "subject" : “rs:scim", >>> >>> "links" : >>> [ >>> { >>> "rel" : “oauth", >>> "href" : "https://oauth.example.com/" >>> } >>> ] >>> } >>> >>> This says something different. This says that for scim services the >>> oauth service is oauth.example.com . >>> >>> The first example actually has more granularity. The second example >>> does not require the client to know the scim endpoint in advance. >>> >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>>> On Feb 9, 2016, at 3:49 PM, John Bradley >>> > wrote: >>>> >>>> Have a look at >>>> https://tools.ietf.org/html/rfc7033 >>>> >>>> The way to do what you want would mean having multiple array >>>> objects with the same rel and somehow differentiating them via >>>> properties. >>>> >>>> I think that is going to be more complicated for clients to parse. >>>> >>>> I think that the difference is how you look at the actors involved. >>>> I think clients look for a service and then go from there, you >>>> are advocating that they would look for a authorization method and >>>> then find services that support that method. >>>> >>>> So yes we are looking at it from different ends. >>>> >>>> I don’t know that defining OAuth genericly at the webfinger level >>>> of user discovery makes sense. Perhaps for a enterprise custom >>>> API environment it might. >>>> >>>> John B. >>>> >>>>> On Feb 9, 2016, at 8:24 PM, Phil Hunt >>>> > wrote: >>>>> >>>>> Huh? >>>>> >>>>> Our proposals are the opposite of one-another. In your proposal >>>>> you have people querying scim to get oauth. I’m saying you query >>>>> rel=scim to get information about SCIM. Querying rel=SCIM and >>>>> receiving OAuth seems bass- ackwards does it not? >>>>> >>>>> Further, having rel=oauth lets us define one RFC for all that >>>>> covers all the security concerns for oauth discovery. If we do it >>>>> your way then every resource that registers its own discovery also >>>>> has to have an oauth section that copies the oauth discovery stuff >>>>> because there is no longer an oauth discovery relationship. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Feb 9, 2016, at 3:16 PM, John Bradley >>>>> > wrote: >>>>>> >>>>>> Please don’t break the webfinger RFC. >>>>>> >>>>>> If you search for SCIM you can have additional properties >>>>>> returned as part of the entry, but you only search for one thing. >>>>>> Webfinger is designed to be very simple to implement. In general >>>>>> you just get back the whole document with all the rel. >>>>>> The query filter is a optional optimization. >>>>>> >>>>>> The JSON in the doc is by rel. >>>>>> >>>>>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) >>>>>>> > wrote: >>>>>>> >>>>>>> The rel for scim returns the endpoint for scim. >>>>>>> >>>>>>> The rel for oauth returns endpoints for oauth. >>>>>>> >>>>>>> The query lets the client say i want the endpoint for oauth used >>>>>>> for scim. >>>>>>> >>>>>>> I suppose you could reverse it but then we'll have oauth >>>>>>> discovery happening in different ways across many different >>>>>>> specs. One set of considerations is enough. :-) >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Feb 9, 2016, at 14:52, John Bradley >>>>>> > wrote: >>>>>>> >>>>>>>> You would define a rel uri for SCIM. The SCIM entry can have >>>>>>>> sub properties if it supported more than one auth type, or you >>>>>>>> could have a SCIM discovery document that the URI points to. >>>>>>>> >>>>>>>> There are probably multiple ways to do it. >>>>>>>> >>>>>>>> I don’t think trying to have a oauth rel and then sub types is >>>>>>>> going to make sense to developers. It is also not a good fit >>>>>>>> for Webfinger. >>>>>>>> >>>>>>>> I also suspect that SCIM is more naturally part of a >>>>>>>> authentication service It may be that the authentication >>>>>>>> service points at the SCIM service. >>>>>>>> >>>>>>>> Remember that webfinger is a account alias and may not be the >>>>>>>> subject that the SP/RP knows the user as. >>>>>>>> >>>>>>>> Each service will need to be thought through for webfinger as >>>>>>>> the account identity may mean different things depending on the >>>>>>>> protocol, and not every protocol needs per user discovery. >>>>>>>> >>>>>>>> John B >>>>>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Another example is to look at scim discovery(in contrast with >>>>>>>>> connect). >>>>>>>>> >>>>>>>>> When asked separately the answers may be different. >>>>>>>>> >>>>>>>>> Asking what is the oauth server for scim is yet another >>>>>>>>> relation. So may be we need a scheme for oauth where query is >>>>>>>>> rs:someval and optionally an acnt value to. >>>>>>>>> >>>>>>>>> For example >>>>>>>>> Get >>>>>>>>> ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:phunt@example.com >>>>>>>>> >>>>>>>>> >>>>>>>>> Note i probably have the compound query syntax wrong. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> On Feb 9, 2016, at 14:03, John Bradley >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> If we keep webfinger I don’t think that having a generic >>>>>>>>>> OAuth rel makes sense. It should be up to each API/Protocol >>>>>>>>>> to define it’s own rel value like Connect has done. >>>>>>>>>> >>>>>>>>>> It is not reasonable to think that a persons ID provider is >>>>>>>>>> going to be the same as the one for calendaring or photo sharing. >>>>>>>>>> >>>>>>>>>> So I could go two ways with webfinger, leave it out >>>>>>>>>> completely, or leave it in but make it up to the application >>>>>>>>>> to define a rel value. >>>>>>>>>> I expect that some things using UMA in web-finger would point >>>>>>>>>> directly to the resource and the resource would point the >>>>>>>>>> client at the correct UMA server. >>>>>>>>>> >>>>>>>>>> The config file name in .well-known could stay as >>>>>>>>>> openid-configuration for historical reasons or we could >>>>>>>>>> change it. >>>>>>>>>> >>>>>>>>>> I think we first need to decide if every protocol/API is >>>>>>>>>> going to have its own config file, we are going to get apps >>>>>>>>>> to retrieve multiple files, or everything is going to go >>>>>>>>>> into one config-file and applicatins just add to that? >>>>>>>>>> >>>>>>>>>> I prefer not to change the file name if we are going for one >>>>>>>>>> config file, but if we do one alias/link is probably not the >>>>>>>>>> end of the world, as I doubt people will ever remove >>>>>>>>>> openid-configuration one if they have it now. >>>>>>>>>> >>>>>>>>>> John B. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> Mike, thanks for putting this up. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I would like to propose for two changes that have been >>>>>>>>>>> brought up before: >>>>>>>>>>> >>>>>>>>>>> 1) The wholesale removal of section 2, Webfinger lookup. >>>>>>>>>>> >>>>>>>>>>> 2) The changing of "/.well-known/openid-configuration†to >>>>>>>>>>> "/.well-known/oauth-authorization-server†or something else >>>>>>>>>>> not openid-related. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> — Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> We have created the initial working group version of OAuth >>>>>>>>>>>> Discovery based on draft-jones-oauth-discovery-01, with no >>>>>>>>>>>> normative changes. >>>>>>>>>>>> The specification is available at: >>>>>>>>>>>> ·http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 >>>>>>>>>>>> An HTML-formatted version is also available at: >>>>>>>>>>>> ·http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html >>>>>>>>>>>> -- Mike >>>>>>>>>>>> P.S. This notice was also posted >>>>>>>>>>>> athttp://self-issued.info/?p=1534and as@selfissued >>>>>>>>>>>> . >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>> >>>>> >>>> >>> >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000707040108040601040203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have to disagree that Webfinger is just about *per-user* service discovery. It can definitely be used that way, but even in the spec there is the example of finding the meta data about a resource which includes in the JSON response a "rel":"author". Which means webfinger is designed for queries such as "who is the author of this webpage".

GET /.well-known/webfinger?resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314&rel=author

I do agree that OAuth should focus on the details of the discovery document and possibly its location within .well-known.

Thanks,
George


On 2/9/16 9:00 PM, Justin Richer wrote:
+1 to John’s point. Webfinger is, as designed, about doing per-user service discovery. Let’s keep the OAuth service discovery away from that. What does it mean to find the OAuth server for a user, anyway? Without the context of a resource protocol, I don’t think it does. If you already have the domain and you don’t need to do a transform from a user-identifier, just go straight to .well-known and have an OAuth service discovery document.

I think the current discovery draft has tried much too hard to copy what’s in OIDC, where it does make sense to use webfinger and per-user discovery systems in the context of a specific identity protocol. It’s a great starting place, but I think we decidedly need to get away from it now.

 — Justin

On Feb 9, 2016, at 7:34 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

OK I was talking about discovering user services via webfinger, (The way connect uses it and most other things) and you are talking about using it to discover things about a server.

Your first example had phunt@example.com as the account you were querying, and that seemed like a user discovery to me.

If you are looking up the OAuth config for a server why would you not just go strait to the .wellknown 

By the way in your example you would need to run a webfinger server on scim.example.com to be able to answer the query. 

looking for .wellknown on examle.com seems more direct.

You seem to be looking more for where is the service for the domain rather than the user.


John B.

On Feb 9, 2016, at 9:20 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

John,

I am following 7033.  The rel parameter is not the query it is the sub set of the resource you want information about.

There is nothing complex here. In most cases this would be responded to by a simple transformation pattern.

Correcting my previous example (but showing it in easy to read form)…the proper query that returns information for both SCIM and OAuth endpoints would be:

GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth

This would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : “http://scim.example.com",
      
       "links" :
       [
         {
           "rel" : “oauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This tells me that the OAuth server used for SCIM at scim.example.com is at oauth.example.com

Note that 7033 has an extension mechanism to define other schemes. E.g. “acct†is just one scheme. Others can be defined. For example, “rs:†could be registered allowing URIs to be used for the resource instead of an actual https endpoint (which is also allowed).

GET /.well-known/webfinger?resource=rs:scim&rel=oauth

This would return something like:
     HTTP/1.1 200 OK
     Access-Control-Allow-Origin: *
     Content-Type: application/jrd+json

     {
       "subject" : “rs:scim",
      
       "links" :
       [
         {
           "rel" : “oauth",
           "href" : "https://oauth.example.com/"
         }
       ]
     }

This says something different.  This says that for scim services the oauth service is oauth.example.com.

The first example actually has more granularity.  The second example does not require the client to know the scim endpoint in advance.



On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Have a look at
https://tools.ietf.org/html/rfc7033

The way to do what you want would mean having multiple array objects with the same rel and somehow differentiating them via properties.

I think that is going to be more complicated for clients to parse.

I think that the difference is how you look at the actors involved.  I think clients look for a service and then go from there,  you are advocating that they would look for a authorization method and then find services that support that method.   

So yes we are looking at it from different ends.

I don’t know that defining OAuth genericly at the webfinger level of user discovery makes sense.   Perhaps for a enterprise custom API environment it might.

John B.

On Feb 9, 2016, at 8:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Huh?

Our proposals are the opposite of one-another.  In your proposal you have people querying scim to get oauth.  I’m saying you query rel=scim to get information about SCIM.  Querying rel=SCIM and receiving OAuth seems bass- ackwards does it not?

Further, having rel=oauth lets us define one RFC for all that covers all the security concerns for oauth discovery.  If we do it your way then every resource that registers its own discovery also has to have an oauth section that copies the oauth discovery stuff because there is no longer an oauth discovery relationship.


On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Please don’t break the webfinger RFC.

If you search for SCIM you can have additional properties returned as part of the entry, but you only search for one thing.
 
Webfinger is designed to be very simple to implement.  In general you just get back the whole document with all the rel. 
The query filter is a optional optimization. 

The JSON in the doc is by rel.

On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

The rel for scim returns the endpoint for scim. 

The rel for oauth returns endpoints for oauth. 

The query lets the client say i want the endpoint for oauth used for scim. 

I suppose you could reverse it but then we'll have oauth discovery happening in different ways across many different specs. One set of considerations is enough. :-)

Phil

On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> wrote:

You would define a rel uri for SCIM.   The SCIM entry can have sub properties if it supported more than one auth type,  or you could have a SCIM discovery document that the URI points to.

There are probably multiple ways to do it.

I don’t think trying to have a oauth rel and then sub types is going to make sense to developers.  It is also not a good fit for Webfinger.

I also suspect that SCIM is more naturally part of a authentication service It may be that the authentication service points at the SCIM service.

Remember that webfinger is a account alias and may not be the subject that the SP/RP knows the user as.

Each service will need to be thought through for webfinger as the account identity may mean different things depending on the protocol, and not every protocol needs per user discovery.

John B
On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Another example is to look at scim discovery(in contrast with connect).

When asked separately the answers may be different. 

Asking what is the oauth server for scim is yet another relation.  So may be we need a scheme for oauth where query is rs:someval and optionally an acnt value to. 

For example
Get ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:phunt@example.com

Note i probably have the compound query syntax wrong. 

Phil

On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:

If we keep webfinger I don’t think that having a generic OAuth rel makes sense.   It should be up to each API/Protocol to define it’s own rel value like Connect has done.

It is not reasonable to think that a persons ID provider is going to be the same as the one for calendaring or photo sharing.

So I could go two ways with webfinger,  leave it out completely, or leave it in but make it up to the application to define a rel value.
I expect that some things using UMA in web-finger would point directly to the resource and the resource would point the client at the correct UMA server.

The config file name in .well-known could stay as openid-configuration for historical reasons or we could change it.

I think we first need to decide if every protocol/API is going to have its own config file, we are going to get apps to retrieve multiple files,  or everything is going to go into one config-file and applicatins just add to that?

I prefer not to change the file name if we are going for one config file, but if we do one alias/link is probably not the end of the world, as I doubt people will ever remove openid-configuration one if they have it now.

John B.

 
On Feb 9, 2016, at 2:19 PM, Justin Richer <jricher@mit.edu> wrote:

Mike, thanks for putting this up.


I would like to propose for two changes that have been brought up before:

1) The wholesale removal of section 2, Webfinger lookup. 

2) The changing of "/.well-known/openid-configuration†to "/.well-known/oauth-authorization-server†or something else not openid-related.



 — Justin


On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

We have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.
 
The specification is available at:
 
An HTML-formatted version is also available at:
 
                                                          -- Mike
 
P.S.  This notice was also posted at http://self-issued.info/?p=1534 and as @selfissued.
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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









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

--------------000707040108040601040203-- From nobody Thu Feb 11 22:03:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95D91B4008 for ; Thu, 11 Feb 2016 22:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3woWkiImtq5E for ; Thu, 11 Feb 2016 22:03:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FCB1B3FEE for ; Thu, 11 Feb 2016 22:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eQbeMybSSa1jkGXEHnpBeRQkSsqj39YoWD433OGbKpg=; b=a9sWon1kKqP+5QqJlDWkMeMNHDTAnplG4eDYeua8TDtTmyYK4PsI4beJJcjODfWQxV794DE2kKFyo5eDoswmw+K9WjYU4QwmXtZfPwPBu8skuLzN62+aOYy9ZBtN20Yv7+ho6v6GkYK74lN4b1aivtO0J2YhZUrdvbEHnMwVPkE= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 12 Feb 2016 06:02:55 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0396.025; Fri, 12 Feb 2016 06:02:55 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Authentication Method Reference Values spec incorporating adoption feedback Thread-Index: AdFlVTP5TWBUSMtZSvC+K8d5oLcJEA== Date: Fri, 12 Feb 2016 06:02:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: b66ab580-30a0-4666-fc7d-08d333722660 x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:zF1d8wtEee13M0wzUEOo+K9T0QFSxyfqJ1okcRiwegan2GJeFXLc3idEJcVmsoLJ3CA5fYZwAjpygxIUjqgFTT6lkw8HOqxBcdUYr4QysdGasbUjUFWlOzKi0/9F09DZTsw9HTClJ46ctUlPho4HtQ==; 24:lCCPOT/T1m66IDtJUBuQgP3q5+c0WcoALMWqQQcnVlFScSuojvM1S5ggGulqAd0rntnwHO0bDB4vLkFXAz3V9CuvNXCyAQrVplajJxMjjY4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(66066001)(5004730100002)(33656002)(189998001)(110136002)(19617315012)(5003600100002)(102836003)(1096002)(92566002)(19300405004)(19625215002)(107886002)(5001960100002)(5008740100001)(5002640100001)(1730700002)(86362001)(5005710100001)(77096005)(15975445007)(229853001)(3280700002)(87936001)(16236675004)(40100003)(74316001)(586003)(3660700001)(2900100001)(122556002)(99286002)(10090500001)(2351001)(2906002)(86612001)(76576001)(11100500001)(3846002)(19580395003)(1220700001)(10290500002)(50986999)(10400500002)(54356999)(6116002)(790700001)(450100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A9083066AB2DD7EA8547F5A90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2016 06:02:55.0987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] Authentication Method Reference Values spec incorporating adoption feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 06:03:22 -0000 --_000_BY2PR03MB442A9083066AB2DD7EA8547F5A90BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This draft of the Authentication Method Reference Values specification inco= rporates OAuth working group feedback from the call for adoption. The prim= ary change was to remove the "amr_values" request parameter, so that "amr" = values can still be returned as part of an authentication result, but canno= t be explicitly requested. Also, noted that OAuth 2.0 is inadequate for au= thentication without employing appropriate extensions and changed the IANA = registration procedure to no longer require a specification. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-amr-values-05 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-amr-values-05.html -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D153= 9 and as @selfissued. --_000_BY2PR03MB442A9083066AB2DD7EA8547F5A90BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft of the Authentication Method Reference Va= lues specification incorporates OAuth working group feedback from the call = for adoption.  The primary change was to remove the “amr_values” request parameter, so that “amr” values can still be returned as part of an au= thentication result, but cannot be explicitly requested.  Also, noted = that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no l= onger require a specification.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oauth-amr= -values-05

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft-jones-= oauth-amr-values-05.html

 

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

 

P.S.  This announcement was also posted at http://self-issued.info/?p=3D1539 and as @selfissued.

--_000_BY2PR03MB442A9083066AB2DD7EA8547F5A90BY2PR03MB442namprd_-- From nobody Thu Feb 11 22:07:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F551B400C for ; Thu, 11 Feb 2016 22:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VboEBY4cPqEn for ; Thu, 11 Feb 2016 22:07:25 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F331B3FEE for ; Thu, 11 Feb 2016 22:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uZqiEDBvq9WWYMrKiwahTBV4UiWwAs2xtrNA7VBNwvk=; b=lk/B1og+hW1gap1ETkmgkUWdf92tgkf+hxq+OaF9vZiDJ9azXMjVBArhvOJjycyKpffS+rH9/c2PI7PL+Yrf3KMtqznGlYKXmScRzKObX68OWzLGCURIo6EVb4KqQDvv0JH4MW1TKuyYPGBLL9BvlvUJtferJpLzPJN10qzqZJ4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 12 Feb 2016 06:07:06 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0396.025; Fri, 12 Feb 2016 06:07:06 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized Thread-Index: AdFlW5fqU0LQGAlJR6KxWxWGgVl2aA== Date: Fri, 12 Feb 2016 06:07:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 915e0984-c241-49af-3b4e-08d33372bc4c x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:6tjbW7Jj/bUTftUpgYM7IccT2uj2TA8LtkvmwV1JfxPFSD0mOd1YolpIsr8gTovu/KUurzBaNHoc0CMustZU+9VXWdJcX6GueOoA1mFGCL7XVki7uDFSfhiLUbBXs8LTPbrLA/DIVWd7qZ37bTvJpA==; 24:08Los7QRx9gt5FMvF692btehYI95VF8T+cIBCy0nlisN7mhpPRzpQIVC+nF2D/IC6cWQjaiXoVUAIdy9ynBcbEx3ji1Za6nosVxnf06YCK4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(53754006)(377454003)(51694002)(66066001)(5004730100002)(33656002)(189998001)(19617315012)(5003600100002)(102836003)(1096002)(92566002)(561944003)(19300405004)(19625215002)(5001770100001)(107886002)(5001960100002)(5008740100001)(5002640100001)(86362001)(5005710100001)(77096005)(15975445007)(3280700002)(87936001)(16236675004)(40100003)(74316001)(586003)(3660700001)(2900100001)(122556002)(99286002)(10090500001)(2906002)(86612001)(76576001)(11100500001)(3846002)(19580405001)(19580395003)(1220700001)(10290500002)(50986999)(10400500002)(54356999)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4423394CEBFF61B89781BD0F5A90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2016 06:07:06.6522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 06:07:31 -0000 --_000_BY2PR03MB4423394CEBFF61B89781BD0F5A90BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHJhZnQgLTA1PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWFt ci12YWx1ZXMtMDU+IGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sgZGVzY3JpYmVkIGJlbG93IC0g ZGVsZXRpbmcgdGhlIHJlcXVlc3QgcGFyYW1ldGVyLCBub3RpbmcgdGhhdCB0aGlzIHNwZWMgaXNu J3QgYW4gZW5jb3VyYWdlbWVudCB0byB1c2UgT0F1dGggMi4wIGZvciBhdXRoZW50aWNhdGlvbiB3 aXRob3V0IGVtcGxveWluZyBhcHByb3ByaWF0ZSBleHRlbnNpb25zLCBhbmQgbm8gbG9uZ2VyIHJl cXVpcmluZyBhIHNwZWNpZmljYXRpb24gZm9yIElBTkEgcmVnaXN0cmF0aW9uLiAgSSBiZWxpZXZl IHRoYXQgaXTigJlzIG5vdyByZWFkeSBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbi4NCg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1dGgg W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hv ZmVuaWcNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA0LCAyMDE2IDExOjIzIEFNDQpUbzogb2F1 dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJl ZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZA0KDQoNCg0KSGkgYWxs LA0KDQoNCg0KT24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gb2Yg dGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRpb24s IHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9t c2cxNTQwMi5odG1sDQoNCg0KDQpXaGF0IHN1cnByaXNlZCB1cyBpcyB0aGF0IHRoaXMgd29yayBp cyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmluZSBuZXcgY2xhaW1zIGFuZCBjcmVh dGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBhIGJpZyBkZWFsIGJ1dCB0aGF0J3Mg bm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29oYW1hIElFVEYgbWVldGluZyBhbmQg dGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhlIGxpc3Qgc2hvd3MuIFRoZSBm ZWVkYmFjayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBpdCBpcyBhIGJpdCBkaWZmaWN1bHQg Zm9yIERlcmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vuc3VzLg0KDQoNCg0KTGV0IG1lIHRl bGwgeW91IHdoYXQgd2Ugc2VlIGZyb20gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0Lg0KDQoNCg0K SW4gaGlzIHJldmlldyBhdA0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTQyMy5odG1sIEphbWVzIE1hbmdlciBhc2tzIGZvciBzaWduaWZp Y2FudCBjaGFuZ2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhlIHdhbnRzIHRvIHJlbW92ZSBvbmUg b2YgdGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxlZCByZXZpZXcgYW5kIGFjdGlvbmFi bGUgaXRlbXMuDQoNCg0KDQpXaWxsaWFtIERlbm5pc3MgYmVsaWV2ZXMgdGhlIGRvY3VtZW50IGlz IHJlYWR5IGZvciBhZG9wdGlvbiBidXQgYWdyZWVzIHdpdGggc29tZSBvZiB0aGUgY29tbWVudHMg ZnJvbSBKYW1lcy4gSGVyZSBpcyBoaXMgcmV2aWV3Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyNi5odG1sDQoNCg0KDQpKdXN0aW4g aXMgY2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJvbmdlc3Qgb3Bpbmlvbi4gSGVy ZSBpcyBvbmUgb2YgaGlzIHBvc3RzOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ1Ny5odG1sDQoNCg0KDQpBbW9uZyBhbGwgY29uY2Vy bnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5nIG9uZSBpcyBhY3R1YWxseSBhY3Rpb25h YmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQgcmVwb3J0aW5nIGhvdyBhIHBlcnNvbiBh dXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIGVuY291cmFnaW5n IHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRpY2F0aW9uIGlzIGEgZmluZSBsaW5lLiBI ZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9jdW1lbnQgbGVhZHMgcmVhZGVycyB0byBiZWxpZXZlIHRo ZSBsYXR0ZXIuDQoNCg0KDQpKb2huIGFncmVlcyB3aXRoIEp1c3RpbiBpbg0KDQpodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1sIHRo YXQgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9wbGUgYXJlIG5vdCBtaXNsZWFkIGFib3V0 IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBKb2huIGFsc28gcHJvdmlkZXMgYWRkaXRp b25hbCBjb21tZW50cyBpbiB0aGlzIHBvc3QgdG8gdGhlDQoNCmxpc3Q6IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWwNCg0KTW9z dCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGluZyB3b3JrLiBGb3IgZXhhbXBs ZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVsLA0KDQoNCg0KUGhpbCBhZ3Jl ZXMgd2l0aCB0aGUgZG9jdW1lbnQgYWRvcHRpb24gYnV0IGhhcyBzb21lIHJlbWFya3MgYWJvdXQg dGhlIHJlZ2lzdHJ5IGFsdGhvdWdoIGhlIGRvZXMgbm90IHByb3Bvc2Ugc3BlY2lmaWMgdGV4dC4g SGlzIHJldmlldyBpcyBoZXJlOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ2Mi5odG1sDQoNCg0KDQpXaXRoIG15IGNvLWNoYWlyIGhh dCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmcgY2xhaW1zIChh bmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhl IE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXplZCB0aGUgSldUIGluIHRoaXMgZ3Jv dXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdl IGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzIGRyYWZ0cy4gTm90IHN0YW5kYXJkaXpp bmcgSldUIGluIHRoZSBJRVRGIHdvdWxkIGhhdmUgbGVhZCB0byByZWR1Y2VkIGludGVyb3BlcmFi aWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHkuIEkgaGF2ZSBubyBkb3VidHMgdGhhdCB3YXMgYSB3cm9u ZyBkZWNpc2lvbi4NCg0KDQoNCkluIGl0cyBjdXJyZW50IGZvcm0sIHRoZXJlIGlzIG5vdCBlbm91 Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBpdGVtLg0KDQoNCg0KV2Ug YmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBhdXRob3JzIHNob3VsZCBhZGRyZXNzIHNvbWUgb2Yg dGhlIGVhc2llciBjb21tZW50cyBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24uIFRoaXMgd291bGQg YWxsb3cgdXMgdG8gcmVhY2ggb3V0IHRvIHRob3NlIHdobyBoYWQgZXhwcmVzc2VkIGNvbmNlcm5z IGFib3V0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVhdGUgdGhlaXIgZGVj aXNpb24uIEEgbmV3IGRyYWZ0IHZlcnNpb24gc2hvdWxkIGF0IGxlYXN0IGFkZHJlc3MgdGhlIGZv bGxvd2luZyBpc3N1ZXM6DQoNCg0KDQoqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5v dCBhbiBlbmNvdXJhZ2VtZW50IGZvciB1c2luZyBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBw cm90b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNv bmNlcm5zIHJhaXNlZCBieSBKdXN0aW4gYW5kIEpvaG4uDQoNCg0KDQoqIENoYW5nZSB0aGUgcmVn aXN0cnkgcG9saWN5LCB3aGljaCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0aGUgY29tbWVudHMgZnJv bSBKYW1lcywgV2lsbGlhbSwgYW5kIFBoaWwuDQoNCg0KDQpWYXJpb3VzIG90aGVyIGl0ZW1zIHJl cXVpcmUgZGlzY3Vzc2lvbiBzaW5jZSB0aGV5IGFyZSBtb3JlIGRpZmZpY3VsdCB0byBhZGRyZXNz LiBGb3IgZXhhbXBsZSwgSm9obiBub3RlZCB0aGF0IGhlIGRvZXMgbm90IGxpa2UgdGhlIHVzZSBv ZiByZXF1ZXN0IHBhcmFtZXRlcnMuIFVuZm9ydHVuYXRlbHksIG5vIGFsdGVybmF0aXZlIGlzIG9m ZmVyZWQuIEkgdXJnZSBKb2huIHRvIHByb3ZpZGUgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwsIGlm IHRoZXJlIGlzIG9uZS4gQWxzbywgdGhlIHJlbWFyayB0aGF0IHRoZSB2YWx1ZXMgYXJlIG1lYW5p bmdsZXNzIGNvdWxkIGJlIGNvdW50ZXJlZCB3aXRoIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLiBK YW1lcyB3YW50ZWQgdG8gcmVtb3ZlIHRoZSAiYW1yX3ZhbHVlcyIgcGFyYW1ldGVyLg0KDQpJcyB0 aGlzIHdoYXQgb3RoZXJzIHdhbnQgYXMgd2VsbD8NCg0KDQoNCkFmdGVyIHRoZXNlIGl0ZW1zIGhh dmUgYmVlbiBhZGRyZXNzZWQgd2UgYmVsaWV2ZSB0aGF0IG1vcmUgZm9sa3MgaW4gdGhlIGdyb3Vw IHdpbGwgc3VwcG9ydCB0aGUgZG9jdW1lbnQuDQoNCg0KDQpDaWFvDQoNCkhhbm5lcyAmIERlcmVr DQoNCg0KDQoNCg0KDQo= --_000_BY2PR03MB4423394CEBFF61B89781BD0F5A90BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTA1Ij5EcmFmdCAtMDU8L2E+ IGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sgZGVzY3JpYmVkIGJlbG93IC0gZGVsZXRpbmcgdGhl IHJlcXVlc3QgcGFyYW1ldGVyLCBub3RpbmcgdGhhdCB0aGlzIHNwZWMgaXNuJ3QgYW4gZW5jb3Vy YWdlbWVudCB0byB1c2UgT0F1dGggMi4wIGZvciBhdXRoZW50aWNhdGlvbg0KIHdpdGhvdXQgZW1w bG95aW5nIGFwcHJvcHJpYXRlIGV4dGVuc2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEg c3BlY2lmaWNhdGlvbiBmb3IgSUFOQSByZWdpc3RyYXRpb24uJm5ic3A7IEkgYmVsaWV2ZSB0aGF0 IGl04oCZcyBub3cgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9h PjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYg MTE6MjMgQU08YnI+DQpUbzogb2F1dGhAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBbT0FVVEgtV0dd IEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlv biBGaW5hbGl6ZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+T24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24g b2YgdGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRp b24sIHNlZQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h dXRoL2N1cnJlbnQvbXNnMTU0MDIuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9vYXV0aC9jdXJyZW50L21zZzE1NDAyLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5XaGF0IHN1cnByaXNlZCB1cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25j ZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmluZSBuZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSBy ZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBhIGJpZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdo YXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29oYW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1 YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24NCiBvbiB0aGUgbGlzdCBzaG93cy4gVGhlIGZlZWRi YWNrIGxlYWQgdG8gbWl4ZWQgZmVlbGluZ3MgYW5kIGl0IGlzIGEgYml0IGRpZmZpY3VsdCBmb3Ig RGVyZWsgYW5kIG15c2VsZiB0byBqdWRnZSBjb25zZW5zdXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkxldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBv biB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gaGlzIHJldmlldyBh dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRt bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDIz Lmh0bWw8L3NwYW4+PC9hPiBKYW1lcyBNYW5nZXIgYXNrcyBmb3Igc2lnbmlmaWNhbnQNCiBjaGFu Z2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhlIHdhbnRzIHRvIHJlbW92ZSBvbmUgb2YgdGhlIGNs YWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxlZCByZXZpZXcgYW5kIGFjdGlvbmFibGUgaXRlbXMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldpbGxpYW0gRGVubmlzcyBiZWxpZXZlcyB0 aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIGFkb3B0aW9uIGJ1dCBhZ3JlZXMgd2l0aCBzb21lIG9m IHRoZSBjb21tZW50cyBmcm9tIEphbWVzLiBIZXJlIGlzIGhpcyByZXZpZXc6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyNi5odG1sIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjYuaHRtbDwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkp1c3RpbiBpcyBjZXJ0YWlubHkgdGhl IHJldmlld2VyIHdpdGggdGhlIHN0cm9uZ2VzdCBvcGluaW9uLiBIZXJlIGlzIG9uZSBvZiBoaXMg cG9zdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ1 Ny5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn MTU0NTcuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFtb25n IGFsbCBjb25jZXJucyBKdXN0aW4gZXhwcmVzc2VkIHRoZSBmb2xsb3dpbmcgb25lIGlzIGFjdHVh bGx5IGFjdGlvbmFibGUgSU1ITzogSnVzdGluIGlzIHdvcnJpZWQgdGhhdCByZXBvcnRpbmcgaG93 IGEgcGVyc29uIGF1dGhlbnRpY2F0ZWQgdG8gYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhbmQg ZW5jb3VyYWdpbmcgcGVvcGxlIHRvIHVzZSBPQXV0aCBmb3IgYXV0aGVudGljYXRpb24gaXMgYSBm aW5lDQogbGluZS4gSGUgYmVsaWV2ZXMgdGhhdCB0aGlzIGRvY3VtZW50IGxlYWRzIHJlYWRlcnMg dG8gYmVsaWV2ZSB0aGUgbGF0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2hu IGFncmVlcyB3aXRoIEp1c3RpbiBpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMTU0NDguaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzE1NDQ4Lmh0bWw8L3NwYW4+PC9hPiB0aGF0IHdlIG5lZWQgdG8gbWFr ZSBzdXJlIHRoYXQNCiBwZW9wbGUgYXJlIG5vdCBtaXNsZWFkIGFib3V0IHRoZSBpbnRlbnRpb24g b2YgdGhlIGRvY3VtZW50LiBKb2huIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbCBjb21tZW50cyBp biB0aGlzIHBvc3QgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5saXN0OiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1 dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1vc3Qgb2YgdGhlbSByZXF1aXJlIG1vcmUgdGhhbiBq dXN0IGVkaXRpbmcgd29yay4gRm9yIGV4YW1wbGUsIG1ldGhvZHMgbGlzdGVkIGFyZSByZWFsbHkg bm90IHVzZWZ1bCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGhpbCBhZ3JlZXMgd2l0 aCB0aGUgZG9jdW1lbnQgYWRvcHRpb24gYnV0IGhhcyBzb21lIHJlbWFya3MgYWJvdXQgdGhlIHJl Z2lzdHJ5IGFsdGhvdWdoIGhlIGRvZXMgbm90IHByb3Bvc2Ugc3BlY2lmaWMgdGV4dC4gSGlzIHJl dmlldyBpcyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMTU0NjIuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy ZW50L21zZzE1NDYyLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5XaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQg cmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdp dGhpbiB0aGUgc2NvcGUgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXpl ZCB0aGUgSldUIGluIHRoaXMgZ3JvdXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFu ZGFyZGl6ZQ0KIGNsYWltcywgYXMgd2UgYXJlIGN1cnJlbnRseSBkb2luZyB3aXRoIHZhcmlvdXMg ZHJhZnRzLiBOb3Qgc3RhbmRhcmRpemluZyBKV1QgaW4gdGhlIElFVEYgd291bGQgaGF2ZSBsZWFk IHRvIHJlZHVjZWQgaW50ZXJvcGVyYWJpbGl0eSBhbmQgbGVzcyBzZWN1cml0eS4gSSBoYXZlIG5v IGRvdWJ0cyB0aGF0IHdhcyBhIHdyb25nIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JbiBpdHMgY3VycmVudCBmb3JtLCB0aGVyZSBpcyBub3QgZW5vdWdoIHN1cHBvcnQg dG8gaGF2ZSB0aGlzIGRvY3VtZW50IGFzIGEgV0cgaXRlbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBhdXRob3JzIHNob3VsZCBhZGRy ZXNzIHNvbWUgb2YgdGhlIGVhc2llciBjb21tZW50cyBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24u IFRoaXMgd291bGQgYWxsb3cgdXMgdG8gcmVhY2ggb3V0IHRvIHRob3NlIHdobyBoYWQgZXhwcmVz c2VkIGNvbmNlcm5zIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVh dGUgdGhlaXIgZGVjaXNpb24uDQogQSBuZXcgZHJhZnQgdmVyc2lvbiBzaG91bGQgYXQgbGVhc3Qg YWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+KiBDbGFyaWZ5IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBub3QgYW4gZW5jb3VyYWdlbWVudCBm b3IgdXNpbmcgT0F1dGggYXMgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wuIEkgYmVsaWV2ZSB0 aGF0IHRoaXMgd291bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBjb25jZXJucyByYWlzZWQgYnkgSnVz dGluIGFuZCBKb2huLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4qIENoYW5nZSB0aGUg cmVnaXN0cnkgcG9saWN5LCB3aGljaCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0aGUgY29tbWVudHMg ZnJvbSBKYW1lcywgV2lsbGlhbSwgYW5kIFBoaWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9uIHNpbmNlIHRoZXkgYXJl IG1vcmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBKb2huIG5vdGVkIHRoYXQg aGUgZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1ldGVycy4gVW5mb3J0dW5h dGVseSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpvaG4gdG8gcHJvdmlkZSBh biBhbHRlcm5hdGl2ZQ0KIHByb3Bvc2FsLCBpZiB0aGVyZSBpcyBvbmUuIEFsc28sIHRoZSByZW1h cmsgdGhhdCB0aGUgdmFsdWVzIGFyZSBtZWFuaW5nbGVzcyBjb3VsZCBiZSBjb3VudGVyZWQgd2l0 aCBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbC4gSmFtZXMgd2FudGVkIHRvIHJlbW92ZSB0aGUgJnF1 b3Q7YW1yX3ZhbHVlcyZxdW90OyBwYXJhbWV0ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JcyB0aGlzIHdoYXQgb3RoZXJzIHdhbnQgYXMgd2VsbD88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QWZ0ZXIgdGhlc2UgaXRlbXMgaGF2ZSBiZWVuIGFkZHJlc3Nl ZCB3ZSBiZWxpZXZlIHRoYXQgbW9yZSBmb2xrcyBpbiB0aGUgZ3JvdXAgd2lsbCBzdXBwb3J0IHRo ZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2lhbzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGFubmVzICZhbXA7IERlcmVrPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_BY2PR03MB4423394CEBFF61B89781BD0F5A90BY2PR03MB442namprd_-- From nobody Thu Feb 11 22:49:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB611B404B for ; Thu, 11 Feb 2016 22:49:09 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N52ckRuPlMc9 for ; Thu, 11 Feb 2016 22:49:06 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501A31B4034 for ; Thu, 11 Feb 2016 22:49:06 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1C6n30v004224 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Feb 2016 06:49:04 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1C6n3gS029089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 06:49:03 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1C6n3Vx003975; Fri, 12 Feb 2016 06:49:03 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Feb 2016 22:49:02 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-543EEFF9-A706-4830-A8BE-0FF169F440E6 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Thu, 11 Feb 2016 22:49:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: <13D34FA3-9D8D-4460-8E31-A7C8BDCEEF28@oracle.com> References: To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 06:49:09 -0000 --Apple-Mail-543EEFF9-A706-4830-A8BE-0FF169F440E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Mike.=20 Phil > On Feb 11, 2016, at 22:07, Mike Jones wrote:= >=20 > Draft -05 incorporates the feedback described below - deleting the request= parameter, noting that this spec isn't an encouragement to use OAuth 2.0 fo= r authentication without employing appropriate extensions, and no longer req= uiring a specification for IANA registration. I believe that it=E2=80=99s n= ow ready for working group adoption. > =20 > -- Mike > =20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig= > Sent: Thursday, February 4, 2016 11:23 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adopt= ion Finalized > =20 > Hi all, > =20 > On January 19th I posted a call for adoption of the Authentication Method R= eference Values specification, see http://www.ietf.org/mail-archive/web/oaut= h/current/msg15402.html > =20 > What surprised us is that this work is conceptually very simple: we define= new claims and create a registry with new values. Not a big deal but that's= not what the feedback from the Yokohama IETF meeting and the subsequent cal= l for adoption on the list shows. The feedback lead to mixed feelings and it= is a bit difficult for Derek and myself to judge consensus. > =20 > Let me tell you what we see from the comments on the list. > =20 > In his review at > http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James Man= ger asks for significant changes. Among other things, he wants to remove one= of the claims. He provides a detailed review and actionable items. > =20 > William Denniss believes the document is ready for adoption but agrees wit= h some of the comments from James. Here is his review: > http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html > =20 > Justin is certainly the reviewer with the strongest opinion. Here is one o= f his posts: > http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html > =20 > Among all concerns Justin expressed the following one is actually actionab= le IMHO: Justin is worried that reporting how a person authenticated to an a= uthorization endpoint and encouraging people to use OAuth for authentication= is a fine line. He believes that this document leads readers to believe the= latter. > =20 > John agrees with Justin in > http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we n= eed to make sure that people are not mislead about the intention of the docu= ment. John also provides additional comments in this post to the > list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html > Most of them require more than just editing work. For example, methods lis= ted are really not useful, > =20 > Phil agrees with the document adoption but has some remarks about the regi= stry although he does not propose specific text. His review is here: > http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html > =20 > With my co-chair hat on: I just wanted to clarify that registering claims (= and values within those claims) is within the scope of the OAuth working gro= up. We standardized the JWT in this group and we are also chartered to stand= ardize claims, as we are currently doing with various drafts. Not standardiz= ing JWT in the IETF would have lead to reduced interoperability and less sec= urity. I have no doubts that was a wrong decision. > =20 > In its current form, there is not enough support to have this document as a= WG item. > =20 > We believe that the document authors should address some of the easier com= ments and submit a new version. This would allow us to reach out to those wh= o had expressed concerns about the scope of the document to re-evaluate thei= r decision. A new draft version should at least address the following issues= : > =20 > * Clarify that this document is not an encouragement for using OAuth as an= authentication protocol. I believe that this would address some of the conc= erns raised by Justin and John. > =20 > * Change the registry policy, which would address one of the comments from= James, William, and Phil. > =20 > Various other items require discussion since they are more difficult to ad= dress. For example, John noted that he does not like the use of request para= meters. Unfortunately, no alternative is offered. I urge John to provide an a= lternative proposal, if there is one. Also, the remark that the values are m= eaningless could be countered with an alternative proposal. James wanted to r= emove the "amr_values" parameter. > Is this what others want as well? > =20 > After these items have been addressed we believe that more folks in the gr= oup will support the document. > =20 > Ciao > Hannes & Derek > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-543EEFF9-A706-4830-A8BE-0FF169F440E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Mike. 

Phil

On Feb 11, 2016, at 22:07, Mike Jones <Michael.Jones@microsoft.com> wrote:

=

Draft -05 incorporates the feedback described below= - deleting the request parameter, noting that this spec isn't an encouragem= ent to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specifi= cation for IANA registration.  I believe that it=E2=80=99s now ready fo= r working group adoption.

 

        &n= bsp;            =             &nbs= p;            &n= bsp;           -- Mike

 <= /p>

-----Original Message-----
From: OAuth [mailto:oauth-bounces@= ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 4, 2016 11:23 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoptio= n Finalized

 

Hi all,

 

On January 19th I posted a call for adoption of th= e Authentication Method Reference Values specification, see http://www.ietf.org/m= ail-archive/web/oauth/current/msg15402.html

 

What surprised us is that this work is conceptuall= y very simple: we define new claims and create a registry with new values. N= ot a big deal but that's not what the feedback from the Yokohama IETF meetin= g and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit diff= icult for Derek and myself to judge consensus.

 

Let me tell you what we see from the comments on t= he list.

 

In his review at

http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html= James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provi= des a detailed review and actionable items.

 

William Denniss believes the document is ready for= adoption but agrees with some of the comments from James. Here is his revie= w:

http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html=

 

Justin is certainly the reviewer with the stronges= t opinion. Here is one of his posts:

http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html=

 

Among all concerns Justin expressed the following o= ne is actually actionable IMHO: Justin is worried that reporting how a perso= n authenticated to an authorization endpoint and encouraging people to use O= Auth for authentication is a fine line. He believes that this document leads readers to believe the latter.

 

John agrees with Justin in

http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html= that we need to make sure that people are not mislead about the intention of the document. John also provi= des additional comments in this post to the

list: http://www.ietf.org/ma= il-archive/web/oauth/current/msg15441.html

Most of them require more than just editing work. = For example, methods listed are really not useful,

 

Phil agrees with the document adoption but has som= e remarks about the registry although he does not propose specific text. His= review is here:

http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html=

 

With my co-chair hat on: I just wanted to clarify t= hat registering claims (and values within those claims) is within the scope o= f the OAuth working group. We standardized the JWT in this group and we are a= lso chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JW= T in the IETF would have lead to reduced interoperability and less security.= I have no doubts that was a wrong decision.

 

In its current form, there is not enough support t= o have this document as a WG item.

 

We believe that the document authors should addres= s some of the easier comments and submit a new version. This would allow us t= o reach out to those who had expressed concerns about the scope of the docum= ent to re-evaluate their decision. A new draft version should at least address the following issues:

 

* Clarify that this document is not an encourageme= nt for using OAuth as an authentication protocol. I believe that this would a= ddress some of the concerns raised by Justin and John.

 

* Change the registry policy, which would address o= ne of the comments from James, William, and Phil.

 

Various other items require discussion since they a= re more difficult to address. For example, John noted that he does not like t= he use of request parameters. Unfortunately, no alternative is offered. I ur= ge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless= could be countered with an alternative proposal. James wanted to remove the= "amr_values" parameter.

Is this what others want as well?

 

After these items have been addressed we believe t= hat more folks in the group will support the document.

 

Ciao

Hannes & Derek

 

 

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-543EEFF9-A706-4830-A8BE-0FF169F440E6-- From nobody Thu Feb 11 23:44:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E08D1B411B for ; Thu, 11 Feb 2016 23:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 36zJ6J69X5xZ for ; Thu, 11 Feb 2016 23:44:38 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64B51B411A for ; Thu, 11 Feb 2016 23:44:37 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id gc3so9505555obb.3 for ; Thu, 11 Feb 2016 23:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UrpKF+VSlNelfDUwgIdvkq7auYZNcBtaF1063XHhmF4=; b=Et5t4elBqczrWfazsHbOhwYyZ4JP8AgpFxHtUr7w+AAM1CAoxUgOHduZbPaC+Fo/1e z31oCDYufDvwoNwwCn2HHBNIFAF038jP+4TWndHx8uMjdg3aZiw1cFqCmWap0Ipd/zeG 6FVXP173crh4DK2fVknFZ8IvWH6uEIaP9dxnuQ0ZMt43b2Tz8WDv7SluhFkpUQRyCU1n mxqs6XB1dtZEeVcl4cXi09PDlN6VIHXXn4ist9aHzMPkyDAq+wQlDdYhGXv+IqMOJxde VKMd7ys+vNgciuM1W2gl1MPTusxpf+Xk7f45jwga+rYg+FlTgKjc8jcJPq5bsRdBp5Z+ BCzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UrpKF+VSlNelfDUwgIdvkq7auYZNcBtaF1063XHhmF4=; b=HE4lN02GFotffnDopAZXkFHL15ti5QgGjwRM0Bib+j33CeED1JZm7EepKM1/q6FADe o/e2LnqVZkG/GR2S1YdGxZBuN6ygdQQ8U/ottoRB26hAgvAOqLwQB/dufM82csAMyOCV WRfNIK/Z49zlHrBilA37wc0Np/Rfox72fkY8XssGbX5R0qgUeURQCftOS8ITuaPwk/rv hlCHMixAsCfQtniOCXdX6MsLH8z9flZh/1PkuXZ8zLIBAki3FIb/ue0yqpKASI3Shufu 5Q8okfzj/suxjrkAnCnfO9ioyzRrc62ezAEaGCcwjslAwzvLx02hlrJo0QxGW4J/OF3l NO7w== X-Gm-Message-State: AG10YOTeWfRA+xihtz1zgb93/8LM2KYSi1fhkEN0ecDWXouM71Q9MUga/tS+MEtSaV1IFOCSw2DyVGb+dI5vm0vb X-Received: by 10.202.51.195 with SMTP id z186mr99480oiz.12.1455263077082; Thu, 11 Feb 2016 23:44:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Thu, 11 Feb 2016 23:44:17 -0800 (PST) In-Reply-To: References: From: William Denniss Date: Thu, 11 Feb 2016 23:44:17 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113ce568c3e892052b8dd64b Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 07:44:40 -0000 --001a113ce568c3e892052b8dd64b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks good to me, thanks for the revision. We are using some of these reference values in production already ("rba" for example) and are supportive of having a formalized registry. +1 to adopt this draft. On Thu, Feb 11, 2016 at 10:07 PM, Mike Jones wrote: > Draft -05 > incorporates the feedback described below - deleting the request paramete= r, > noting that this spec isn't an encouragement to use OAuth 2.0 for > authentication without employing appropriate extensions, and no longer > requiring a specification for IANA registration. I believe that it=E2=80= =99s now > ready for working group adoption. > > > > -- Mike > > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Thursday, February 4, 2016 11:23 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > > > > Hi all, > > > > On January 19th I posted a call for adoption of the Authentication Method > Reference Values specification, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html > > > > What surprised us is that this work is conceptually very simple: we defin= e > new claims and create a registry with new values. Not a big deal but that= 's > not what the feedback from the Yokohama IETF meeting and the subsequent > call for adoption on the list shows. The feedback lead to mixed feelings > and it is a bit difficult for Derek and myself to judge consensus. > > > > Let me tell you what we see from the comments on the list. > > > > In his review at > > http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James > Manger asks for significant changes. Among other things, he wants to remo= ve > one of the claims. He provides a detailed review and actionable items. > > > > William Denniss believes the document is ready for adoption but agrees > with some of the comments from James. Here is his review: > > http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html > > > > Justin is certainly the reviewer with the strongest opinion. Here is one > of his posts: > > http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html > > > > Among all concerns Justin expressed the following one is actually > actionable IMHO: Justin is worried that reporting how a person > authenticated to an authorization endpoint and encouraging people to use > OAuth for authentication is a fine line. He believes that this document > leads readers to believe the latter. > > > > John agrees with Justin in > > http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we > need to make sure that people are not mislead about the intention of the > document. John also provides additional comments in this post to the > > list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html > > Most of them require more than just editing work. For example, methods > listed are really not useful, > > > > Phil agrees with the document adoption but has some remarks about the > registry although he does not propose specific text. His review is here: > > http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html > > > > With my co-chair hat on: I just wanted to clarify that registering claims > (and values within those claims) is within the scope of the OAuth working > group. We standardized the JWT in this group and we are also chartered to > standardize claims, as we are currently doing with various drafts. Not > standardizing JWT in the IETF would have lead to reduced interoperability > and less security. I have no doubts that was a wrong decision. > > > > In its current form, there is not enough support to have this document as > a WG item. > > > > We believe that the document authors should address some of the easier > comments and submit a new version. This would allow us to reach out to > those who had expressed concerns about the scope of the document to > re-evaluate their decision. A new draft version should at least address t= he > following issues: > > > > * Clarify that this document is not an encouragement for using OAuth as a= n > authentication protocol. I believe that this would address some of the > concerns raised by Justin and John. > > > > * Change the registry policy, which would address one of the comments fro= m > James, William, and Phil. > > > > Various other items require discussion since they are more difficult to > address. For example, John noted that he does not like the use of request > parameters. Unfortunately, no alternative is offered. I urge John to > provide an alternative proposal, if there is one. Also, the remark that t= he > values are meaningless could be countered with an alternative proposal. > James wanted to remove the "amr_values" parameter. > > Is this what others want as well? > > > > After these items have been addressed we believe that more folks in the > group will support the document. > > > > Ciao > > Hannes & Derek > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113ce568c3e892052b8dd64b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good to me, thanks for the revision.

<= div>We are using some of these reference values in production already (&quo= t;rba" for example) and are supportive of having a formalized registry= . +1 to adopt this draft.

On Thu, Feb 11, 2016 at 10:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Draft -05 incorporates the feedback described below - = deleting the request parameter, noting that this spec isn't an encourag= ement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specif= ication for IANA registration.=C2=A0 I believe that it=E2=80=99s now ready = for working group adoption.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 4, 2016 11:23 AM
To: oauth@ietf.org<= br> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adopti= on Finalized

=C2=A0

Hi all,

=C2=A0

On January 19th I posted a call for adoption of the Authentication Metho= d Reference Values specification, see h= ttp://www.ietf.org/mail-archive/web/oauth/current/msg15402.html<= u>

=C2=A0

What surprised us is that this work is conceptually very simple: we defi= ne new claims and create a registry with new values. Not a big deal but tha= t's not what the feedback from the Yokohama IETF meeting and the subseq= uent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit dif= ficult for Derek and myself to judge consensus.

=C2=A0

Let me tell you what we see from the comments on the list.=

=C2=A0

In his review at

http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He prov= ides a detailed review and actionable items.

=C2=A0

William Denniss believes the document is ready for adoption but agrees w= ith some of the comments from James. Here is his review:

http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html

=C2=A0

Justin is certainly the reviewer with the strongest opinion. Here is one= of his posts:

http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html

=C2=A0

Among all concerns Justin expressed the following one is actually action= able IMHO: Justin is worried that reporting how a person authenticated to a= n authorization endpoint and encouraging people to use OAuth for authentica= tion is a fine line. He believes that this document leads readers to believe the latter.<= u>

=C2=A0

John agrees with Justin in

http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we need to make sure that people are not mislead about the intention of the document. John also prov= ides additional comments in this post to the

list: http://www.ietf.org/m= ail-archive/web/oauth/current/msg15441.html

Most of them require more than just editing work. For example, methods l= isted are really not useful,

=C2=A0

Phil agrees with the document adoption but has some remarks about the re= gistry although he does not propose specific text. His review is here:

http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html

=C2=A0

With my co-chair hat on: I just wanted to clarify that registering claim= s (and values within those claims) is within the scope of the OAuth working= group. We standardized the JWT in this group and we are also chartered to = standardize claims, as we are currently doing with various drafts. Not standardizing J= WT in the IETF would have lead to reduced interoperability and less securit= y. I have no doubts that was a wrong decision.

=C2=A0

In its current form, there is not enough support to have this document a= s a WG item.

=C2=A0

We believe that the document authors should address some of the easier c= omments and submit a new version. This would allow us to reach out to those= who had expressed concerns about the scope of the document to re-evaluate = their decision. A new draft version should at least address the following issues:

=C2=A0

* Clarify that this document is not an encouragement for using OAuth as = an authentication protocol. I believe that this would address some of the c= oncerns raised by Justin and John.

=C2=A0

* Change the registry policy, which would address one of the comments fr= om James, William, and Phil.

=C2=A0

Various other items require discussion since they are more difficult to = address. For example, John noted that he does not like the use of request p= arameters. Unfortunately, no alternative is offered. I urge John to provide= an alternative proposal, if there is one. Also, the remark that the values are meaningles= s could be countered with an alternative proposal. James wanted to remove t= he "amr_values" parameter.

Is this what others want as well?

=C2=A0

After these items have been addressed we believe that more folks in the = group will support the document.

=C2=A0

Ciao

Hannes & Derek

=C2=A0

=C2=A0

=C2=A0


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


--001a113ce568c3e892052b8dd64b-- From nobody Fri Feb 12 00:32:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6A1B41C4 for ; Fri, 12 Feb 2016 00:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJlwbxaNscmi for ; Fri, 12 Feb 2016 00:32:02 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 2CB331B41C5 for ; Fri, 12 Feb 2016 00:32:02 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id tk3so29015378lbb.3 for ; Fri, 12 Feb 2016 00:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=THnmucfvt2W5w2mgwq5LiqhpUTEq4J/jCBsDu8PZI5k=; b=Uz/52cAXjIdo0IgXwHtC3C5exm5oFmSPbfKM9sCkVL4mYbel0VHK5Z0wnHQ951JNIs 3N6KVm41uNq1EGXOwnfgpKEzgW6DnX9W3D08sz4D481+uhBHaBXu1qtAsMxGi5/FIqa5 O+v9+mvQ8iHfk6riBL+esNLJrjfvIOgRb/50X031IeAQvAzAEY0bN3GT1TnAgfiTK5xp 6VrIB2ADtm5CWRfhKCnQgOYFyLkDI4iO20M0FdHERryjGk02789NBTEGxvNc/HJMd7d8 vyvr2syJAII/Jjw4dmWrcoPUOQykqErZQuMCcFBIA7WdVz8Rkcsw1JSIRFqG7KooWXAT x62w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=THnmucfvt2W5w2mgwq5LiqhpUTEq4J/jCBsDu8PZI5k=; b=i7AKaicv3WzphBdVNzkxzqK/taCtFImvrBBhfj9qQj1zbhfmwKA9RTz66aeCswclwn y/Rj0WEnMbm2ngSA6fekepx+DinBU43I2O4qpK1DUq2KbVf2IUcAWcCu8zvDbu+nFUJM N8D6VpWx+e29sDFSG/Mm9edOBaueA/ntnxkYJVhcFchXUSdaPbXvx9mKhOb1y+liQWxN PJB/teiGwfYzCx+JGBSgn61vjlSeP6YGAT6VO/p7JRz5ueWQ1+H1GxZ+tvWXCmkrdfVy jtz/IEua8XSGQTlRqHRFTofrMaCymCGixYsvsw0wbymNYHCbVqn+cJMiAqWaMg6opKK8 /JtA== X-Gm-Message-State: AG10YOSGrf1on0z9L0uuOI6tUnY2WZ2zN3xIskOyHf1zSzBei7PrZ0vRglfCWiEkeOCe2BLgnIOIFheUiriahA== X-Received: by 10.112.64.5 with SMTP id k5mr107789lbs.133.1455265920354; Fri, 12 Feb 2016 00:32:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Fri, 12 Feb 2016 08:31:50 +0000 Message-ID: To: Mike Jones , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3eeb63c8f06052b8e8023 Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values spec incorporating adoption feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 08:32:04 -0000 --001a11c3eeb63c8f06052b8e8023 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, you just removed every relationship to OAuth (and the note about OAuth and authentication seems a bit out of context), and I thus wonder why the OAuth WG would adopt this draft; that'd rather be a JOSE thing. Le ven. 12 f=C3=A9vr. 2016 07:03, Mike Jones = a =C3=A9crit : > This draft of the Authentication Method Reference Values specification > incorporates OAuth working group feedback from the call for adoption. Th= e > primary change was to remove the =E2=80=9Camr_values=E2=80=9D request par= ameter, so that =E2=80=9C > amr=E2=80=9D values can still be returned as part of an authentication re= sult, > but cannot be explicitly requested. Also, noted that OAuth 2.0 is > inadequate for authentication without employing appropriate extensions an= d > changed the IANA registration procedure to no longer require a > specification. > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-jones-oauth-amr-values-05 > > > > An HTML-formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-jones-oauth-amr-values-05= .html > > > > -- Mike > > > > P.S. This announcement was also posted at http://self-issued.info/?p=3D1= 539 > and as @selfissued . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c3eeb63c8f06052b8e8023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So, you just removed every relationship to OAuth (and the no= te about OAuth and authentication seems a bit out of context), and I thus w= onder why the OAuth WG would adopt this draft; that'd rather be a JOSE = thing.


Le=C2=A0ven. 12 f=C3=A9vr. = 2016 07:03,=C2=A0Mike Jones <Michael.Jones@microsoft.com> a =C3=A9crit=C2=A0:

This draft of the Authentication Method Reference Va= lues specification incorporates OAuth working group feedback from the call = for adoption.=C2=A0 The primary change was to remove the =E2=80=9Camr_values=E2=80=9D request parameter, so that =E2=80=9Camr=E2=80=9D values can still be returned as part of a= n authentication result, but cannot be explicitly requested.=C2=A0 Also, no= ted that OAuth 2.0 is inadequate for authentication without employing appropriate extensions and changed the IANA registration procedure to no l= onger require a specification.

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-= jones-oauth-amr-values-05

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/do= cs/draft-jones-oauth-amr-values-05.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This announcement was also posted at http://self-issued.info/?p=3D1539 and as @selfissued.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11c3eeb63c8f06052b8e8023-- From nobody Fri Feb 12 01:00:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2D11B4217 for ; Fri, 12 Feb 2016 01:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.009 X-Spam-Level: *** X-Spam-Status: No, score=3.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 fM3C49bEWyMd for ; Fri, 12 Feb 2016 01:00:18 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFD01B419A for ; Fri, 12 Feb 2016 01:00:17 -0800 (PST) Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id 0E8231968A1; Fri, 12 Feb 2016 18:00:16 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u1C90F6N002449; Fri, 12 Feb 2016 18:00:15 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1C90FjS058727; Fri, 12 Feb 2016 18:00:15 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u1C90Fc1058726; Fri, 12 Feb 2016 18:00:15 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1C90FXj058723; Fri, 12 Feb 2016 18:00:15 +0900 From: "Nat Sakimura" To: "'Justin Richer'" , "'Phil Hunt'" References: <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu> <56BB3DCA.9070209@mit.edu> In-Reply-To: <56BB3DCA.9070209@mit.edu> Date: Fri, 12 Feb 2016 18:00:15 +0900 Message-ID: <08f601d16573$ca301c10$5e905430$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08F7_01D165BF.3A2865E0" X-Mailer: Microsoft Outlook 15.0 thread-index: AQEqpkhdJsfoUR4zRG8olMmCsa2lPAIIX0ARAjZWSUUBnSkyjAGw8EkfAmqUCfoBwixONAInubmkAVAAXGsB6JxkdgF1wQobAiFSwCQBTX1sDQLXpAkvn67oRsA= Content-Language: ja X-MailAdviser: 20141126 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 09:00:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08F7_01D165BF.3A2865E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry to chime in a bit late, but IMHO, the discovery document discovery = etc. starting from the protected resource should happen via RFC5988.=20 =20 That is, when the client asks for the access, it gets an error like:=20 =20 HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm=3D"example" Link: ; = rel=3D"duri", ; rel=3D"duri", ; rel=3D"payments" =20 =20 I used .well-known/openid-configuration in the example, but it does not = have to be. It can be anything. It does not pollute the server uri space = this way and can support multiple authorization servers.=20 =20 See: = = http://www.sakimura.org/uploads/draft-sakimura-oauth-meta.html#rfc.sectio= n.2 =20 Best,=20 =20 Nat =20 =20 -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, February 10, 2016 10:40 PM To: Phil Hunt Cc: Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery = specification =20 Yes, it says that because we can't ever talk about people as being the = only things in the world. The purpose of webfinger is to take something = that's easily human-memorizable, like an email-formatted identifier, and = transform it into an HTTPS URL that can be fetched with GET. It's true = that you could have an organization or bot or other entity that you want = to refer to with a username@domain.ext = type of format, sure. But I argue that if you're talking about a = resource server, you're likely to already have a URL that you can put in = to the .well-known discovery step. You don't need the human-readable = transform to do what you're talking about below in any of the use cases, = you just need the service discovery document part.=20 Additionally, we all three actually agree about the importance of = discovery from a resource server, except that John and I couched that in = "knowing the specific API" and having that API define its first-stage = discovery process. OIDC used webfinger because it makes sense to have a = human-readable identifier for an identity protocol. It probably makes = sense to have SCIM define its own webfinger REL as well since you've got = entity identifiers all over the place. But it doesn't really make sense = for OAuth, and especially not the multi-part resource you're talking = about below.=20 And to add just a bit from personal experience, we actually just relaxed = and simplified our webfinger implementation so that it returns the same = document regardless of what REL you asked for anyway, which is pretty = common with the handful of webfinger servers that I've seen in the wild. -- Justin On 2/10/2016 3:10 AM, Phil Hunt wrote: Justin,=20 =20 The abstract to 7033 says.=20 =20 This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. =20 I am pushing on this because I think we really need to bind the resource = service into discovery somehow. The RS is just as important as the other = oauth endpoints. =20 If a client can be convinced or configured to use a fake resource server = (that proxies the real one), then we have the same problem as a client = being convinced to use a fake token endpoint =E2=80=94 only much worse. =20 I don=E2=80=99t get the big taboo against webfinger here. We = don=E2=80=99t have to use webfinger - but are you arguing for something = completely different? A new protocol? Since OIDC already started the = ball rolling with webfinger, it seems worth while trying to use it. =20 What am I missing here? =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 9, 2016, at 6:00 PM, Justin Richer > wrote: =20 +1 to John=E2=80=99s point. Webfinger is, as designed, about doing = per-user service discovery. Let=E2=80=99s keep the OAuth service = discovery away from that. What does it mean to find the OAuth server for = a user, anyway? Without the context of a resource protocol, I = don=E2=80=99t think it does. If you already have the domain and you = don=E2=80=99t need to do a transform from a user-identifier, just go = straight to .well-known and have an OAuth service discovery document.=20 =20 I think the current discovery draft has tried much too hard to copy = what=E2=80=99s in OIDC, where it does make sense to use webfinger and = per-user discovery systems in the context of a specific identity = protocol. It=E2=80=99s a great starting place, but I think we decidedly = need to get away from it now. =20 =E2=80=94 Justin =20 On Feb 9, 2016, at 7:34 PM, John Bradley > wrote: =20 OK I was talking about discovering user services via webfinger, (The way = connect uses it and most other things) and you are talking about using = it to discover things about a server.=20 =20 Your first example had phunt@example.com as = the account you were querying, and that seemed like a user discovery to = me. =20 If you are looking up the OAuth config for a server why would you not = just go strait to the .wellknown=20 =20 By the way in your example you would need to run a webfinger server on = scim.example.com to be able to answer the = query.=20 =20 looking for .wellknown on examle.com seems more = direct. =20 You seem to be looking more for where is the service for the domain = rather than the user. =20 =20 John B. =20 On Feb 9, 2016, at 9:20 PM, Phil Hunt > wrote: =20 John,=20 =20 I am following 7033. The rel parameter is not the query it is the sub = set of the resource you want information about. =20 There is nothing complex here. In most cases this would be responded to = by a simple transformation pattern. =20 Correcting my previous example (but showing it in easy to read = form)=E2=80=A6the proper query that returns information for both SCIM = and OAuth endpoints would be: =20 GET /.well-known/webfinger?resource=3Dhttps://scim.example.com = &rel=3Doauth =20 This would return something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json =20 { "subject" : =E2=80=9Chttp://scim.example.com = ", =20 "links" : [ { "rel" : =E2=80=9Coauth", "href" : "https://oauth.example.com/" } ] } =20 This tells me that the OAuth server used for SCIM at scim.example.com = is at oauth.example.com = =20 =20 Note that 7033 has an extension mechanism to define other schemes. E.g. = =E2=80=9Cacct=E2=80=9D is just one scheme. Others can be defined. For = example, =E2=80=9Crs:=E2=80=9D could be registered allowing URIs to be = used for the resource instead of an actual https endpoint (which is also = allowed). =20 GET /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth =20 This would return something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/jrd+json =20 { "subject" : =E2=80=9Crs:scim", =20 "links" : [ { "rel" : =E2=80=9Coauth", "href" : "https://oauth.example.com/" } ] } =20 This says something different. This says that for scim services the = oauth service is oauth.example.com . =20 The first example actually has more granularity. The second example = does not require the client to know the scim endpoint in advance. =20 =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 9, 2016, at 3:49 PM, John Bradley > wrote: =20 Have a look at https://tools.ietf.org/html/rfc7033=20 =20 The way to do what you want would mean having multiple array objects = with the same rel and somehow differentiating them via properties. =20 I think that is going to be more complicated for clients to parse. =20 I think that the difference is how you look at the actors involved. I = think clients look for a service and then go from there, you are = advocating that they would look for a authorization method and then find = services that support that method. =20 =20 So yes we are looking at it from different ends. =20 I don=E2=80=99t know that defining OAuth genericly at the webfinger = level of user discovery makes sense. Perhaps for a enterprise custom = API environment it might. =20 John B. =20 On Feb 9, 2016, at 8:24 PM, Phil Hunt > wrote: =20 Huh?=20 =20 Our proposals are the opposite of one-another. In your proposal you = have people querying scim to get oauth. I=E2=80=99m saying you query = rel=3Dscim to get information about SCIM. Querying rel=3DSCIM and = receiving OAuth seems bass- ackwards does it not? =20 Further, having rel=3Doauth lets us define one RFC for all that covers = all the security concerns for oauth discovery. If we do it your way = then every resource that registers its own discovery also has to have an = oauth section that copies the oauth discovery stuff because there is no = longer an oauth discovery relationship. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 9, 2016, at 3:16 PM, John Bradley > wrote: =20 Please don=E2=80=99t break the webfinger RFC.=20 =20 If you search for SCIM you can have additional properties returned as = part of the entry, but you only search for one thing. =20 Webfinger is designed to be very simple to implement. In general you = just get back the whole document with all the rel.=20 The query filter is a optional optimization.=20 =20 The JSON in the doc is by rel. =20 On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) > wrote: =20 The rel for scim returns the endpoint for scim.=20 =20 The rel for oauth returns endpoints for oauth.=20 =20 The query lets the client say i want the endpoint for oauth used for = scim.=20 =20 I suppose you could reverse it but then we'll have oauth discovery = happening in different ways across many different specs. One set of = considerations is enough. :-) =20 Phil On Feb 9, 2016, at 14:52, John Bradley > wrote: You would define a rel uri for SCIM. The SCIM entry can have sub = properties if it supported more than one auth type, or you could have a = SCIM discovery document that the URI points to.=20 =20 There are probably multiple ways to do it. =20 I don=E2=80=99t think trying to have a oauth rel and then sub types is = going to make sense to developers. It is also not a good fit for = Webfinger. =20 I also suspect that SCIM is more naturally part of a authentication = service It may be that the authentication service points at the SCIM = service. =20 Remember that webfinger is a account alias and may not be the subject = that the SP/RP knows the user as. =20 Each service will need to be thought through for webfinger as the = account identity may mean different things depending on the protocol, = and not every protocol needs per user discovery. =20 John B On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) > wrote: =20 Another example is to look at scim discovery(in contrast with connect). =20 When asked separately the answers may be different.=20 =20 Asking what is the oauth server for scim is yet another relation. So = may be we need a scheme for oauth where query is rs:someval and = optionally an acnt value to.=20 =20 For example Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com= =20 =20 Note i probably have the compound query syntax wrong.=20 Phil On Feb 9, 2016, at 14:03, John Bradley > wrote: If we keep webfinger I don=E2=80=99t think that having a generic OAuth = rel makes sense. It should be up to each API/Protocol to define = it=E2=80=99s own rel value like Connect has done.=20 =20 It is not reasonable to think that a persons ID provider is going to be = the same as the one for calendaring or photo sharing. =20 So I could go two ways with webfinger, leave it out completely, or = leave it in but make it up to the application to define a rel value. I expect that some things using UMA in web-finger would point directly = to the resource and the resource would point the client at the correct = UMA server. =20 The config file name in .well-known could stay as openid-configuration = for historical reasons or we could change it. =20 I think we first need to decide if every protocol/API is going to have = its own config file, we are going to get apps to retrieve multiple = files, or everything is going to go into one config-file and = applicatins just add to that? =20 I prefer not to change the file name if we are going for one config = file, but if we do one alias/link is probably not the end of the world, = as I doubt people will ever remove openid-configuration one if they have = it now. =20 John B. =20 =20 On Feb 9, 2016, at 2:19 PM, Justin Richer > wrote: =20 Mike, thanks for putting this up.=20 =20 =20 I would like to propose for two changes that have been brought up = before: =20 1) The wholesale removal of section 2, Webfinger lookup.=20 =20 2) The changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else not = openid-related. =20 =20 =20 =E2=80=94 Justin =20 =20 On Feb 9, 2016, at 9:09 AM, Mike Jones > wrote: =20 We have created the initial working group version of OAuth Discovery = based on draft-jones-oauth-discovery-01, with no normative changes. =20 The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-discovery-00 =20 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html =20 -- Mike =20 P.S. This notice was also posted at http://self-issued.info/?p=3D1534 = and as @selfissued . =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_08F7_01D165BF.3A2865E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

S= orry to chime in a bit late, but IMHO, the discovery document discovery = etc. starting from the protected resource should happen via RFC5988. =

<= o:p> 

T= hat is, when the client asks for the access, it gets an error like: =

<= o:p> 

HTTP/1.1 401 = Unauthorized

WWW-Authenticate: Bearer = realm=3D"example"

Link: = <https://example.com/.well-known/openid-configuration>; = rel=3D"duri",

=C2=A0 = <https://example.net/.well-known/openid-configuration>; = rel=3D"duri",

=C2=A0=C2=A0 = <https://example.com/payment-upon-trial-expiry>; = rel=3D"payments"

=C2=A0

<= o:p> 

I= used .well-known/openid-configuration in the example, but it does not = have to be. It can be anything. It does not pollute the server uri space = this way and can support multiple authorization servers. =

<= o:p> 

S= ee: http://www.saki= mura.org/uploads/draft-sakimura-oauth-meta.html#rfc.section.2<= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:"Arial",sans-serif;color:#1F497D'><= o:p>

<= o:p> 

B= est,

<= o:p> 

N= at

<= o:p> 

<= o:p> 

--=

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender=C2=A0 and delete this e-mail.

<= o:p> 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Wednesday, February 10, 2016 10:40 = PM
To: Phil Hunt
Cc: = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Initial OAuth = working group Discovery = specification

 

Yes, = it says that because we can't ever talk about people as being the only = things in the world. The purpose of webfinger is to take something = that's easily human-memorizable, like an email-formatted identifier, and = transform it into an HTTPS URL that can be fetched with GET. It's true = that you could have an organization or bot or other entity that you want = to refer to with a username@domain.ext type of = format, sure. But I argue that if you're talking about a resource = server, you're likely to already have a URL that you can put in to the = .well-known discovery step. You don't need the human-readable transform = to do what you're talking about below in any of the use cases, you just = need the service discovery document part.

Additionally, we all = three actually agree about the importance of discovery from a resource = server, except that John and I couched that in "knowing the = specific API" and having that API define its first-stage discovery = process. OIDC used webfinger because it makes sense to have a = human-readable identifier for an identity protocol. It probably makes = sense to have SCIM define its own webfinger REL as well since you've got = entity identifiers all over the place. But it doesn't really make sense = for OAuth, and especially not the multi-part resource you're talking = about below.

And to add just a bit from personal experience, we = actually just relaxed and simplified our webfinger implementation so = that it returns the same document regardless of what REL you asked for = anyway, which is pretty common with the handful of webfinger servers = that I've seen in the wild.

 -- = Justin

On 2/10/2016 3:10 AM, Phil Hunt = wrote:

Justin, =

 

The abstract to 7033 says. =

 

=C2=A0=C2=A0 This specification =
defines the WebFinger protocol, which can be =
used
=C2=A0=C2=A0 to discover information about =
people or other entities on =
the
=C2=A0=C2=A0 Internet using standard HTTP =
methods.=C2=A0 WebFinger discovers
=C2=A0=C2=A0 information for a =
URI that might not be usable as a =
locator
=C2=A0=C2=A0 otherwise, such as account or =
email URIs.

 

I am pushing on this because I = think we really need to bind the resource service into discovery = somehow. The RS is just as important as the other oauth = endpoints.

 

If a client can be convinced or = configured to use a fake resource server (that proxies the real one), = then we have the same problem as a client being convinced to use a fake = token endpoint =E2=80=94 only much = worse.

 

I don=E2=80=99t get the big taboo = against webfinger here. We don=E2=80=99t have to use webfinger - but are = you arguing for something completely different? A new protocol? Since = OIDC already started the ball rolling with webfinger, it seems worth = while trying to use it.

 

What am I missing = here?

 

Phil

 

 

 

On Feb 9, 2016, at 6:00 PM, Justin = Richer <jricher@mit.edu> = wrote:

 

+1 to John=E2=80=99s point. = Webfinger is, as designed, about doing per-user service discovery. = Let=E2=80=99s keep the OAuth service discovery away from that. What does = it mean to find the OAuth server for a user, anyway? Without the context = of a resource protocol, I don=E2=80=99t think it does. If you already = have the domain and you don=E2=80=99t need to do a transform from a = user-identifier, just go straight to .well-known and have an OAuth = service discovery document.

 

I think the current discovery draft = has tried much too hard to copy what=E2=80=99s in OIDC, where it does = make sense to use webfinger and per-user discovery systems in the = context of a specific identity protocol. It=E2=80=99s a great starting = place, but I think we decidedly need to get away from it = now.

 

 =E2=80=94 = Justin

 

On Feb 9, 2016, at 7:34 PM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

OK I was talking about discovering = user services via webfinger, (The way connect uses it and most other = things) and you are talking about using it to discover things about a = server.

 

Your first example had phunt@example.com as the account = you were querying, and that seemed like a user discovery to = me.

 

If you are looking up the OAuth = config for a server why would you not just go strait to the = .wellknown 

 

By the way in your example you = would need to run a webfinger server on scim.example.com to be able to = answer the query. 

 

looking for .wellknown on examle.com seems more = direct.

 

You seem to be looking more for = where is the service for the domain rather than the = user.

 

 

John = B.

 

On Feb 9, 2016, at 9:20 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

John,

 

I am following 7033.  The rel = parameter is not the query it is the sub set of the resource you want = information about.

 

There is nothing complex here. In = most cases this would be responded to by a simple transformation = pattern.

 

Correcting my previous example (but = showing it in easy to read form)=E2=80=A6the proper query that returns = information for both SCIM and OAuth endpoints would = be:

 

GET = /.well-known/webfinger?resource=3Dhttps://scim.example.co= m&rel=3Doauth

 

This would return something = like:

=C2=A0=C2=A0=C2=A0=C2=A0 HTTP/1.1 200 =
OK
=C2=A0=C2=A0=C2=A0=C2=A0 =
Access-Control-Allow-Origin: *
=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: =
application/jrd+json
 
=C2=A0=C2=A0=C2=A0=C2=A0 =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"subject" : =E2=80=9Chttp://scim.example.com",=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&quo=
t;links" :
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
[
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "rel" : =
=E2=80=9Coauth",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "href" : "https://oauth.example.com/"<=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
]
=C2=A0=C2=A0=C2=A0=C2=A0 =
}

 

This tells me that the OAuth server = used for SCIM at scim.example.com is at oauth.example.com

 

Note that 7033 has an extension = mechanism to define other schemes. E.g. =E2=80=9Cacct=E2=80=9D is just = one scheme. Others can be defined. For example, =E2=80=9Crs:=E2=80=9D = could be registered allowing URIs to be used for the resource instead of = an actual https endpoint (which is also = allowed).

 

GET = /.well-known/webfinger?resource=3Drs:scim&rel=3Doauth

 

This would return something = like:

=C2=A0=C2=A0=C2=A0=C2=A0 HTTP/1.1 200 =
OK
=C2=A0=C2=A0=C2=A0=C2=A0 =
Access-Control-Allow-Origin: *
=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: =
application/jrd+json
 
=C2=A0=C2=A0=C2=A0=C2=A0 =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"subject" : =
=E2=80=9Crs:scim",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&quo=
t;links" :
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
[
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "rel" : =
=E2=80=9Coauth",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 "href" : "https://oauth.example.com/"<=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
]
=C2=A0=C2=A0=C2=A0=C2=A0 =
}

 

This says something different. =  This says that for scim services the oauth service is oauth.example.com.

 

The first example actually has more = granularity.  The second example does not require the client to = know the scim endpoint in advance.

 

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 9, 2016, at 3:49 PM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Have a look = at

https://tools.ietf.org/html/= rfc7033

 

The way to do what you want would = mean having multiple array objects with the same rel and somehow = differentiating them via properties.

 

I think that is going to be more = complicated for clients to parse.

 

I think that the difference is how = you look at the actors involved.  I think clients look for a = service and then go from there,  you are advocating that they would = look for a authorization method and then find services that support that = method.   

 

So yes we are looking at it from = different ends.

 

I don=E2=80=99t know that defining = OAuth genericly at the webfinger level of user discovery makes sense. =   Perhaps for a enterprise custom API environment it = might.

 

John = B.

 

On Feb 9, 2016, at 8:24 PM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

Huh?

 

Our proposals are the opposite of = one-another.  In your proposal you have people querying scim to get = oauth.  I=E2=80=99m saying you query rel=3Dscim to get information = about SCIM.  Querying rel=3DSCIM and receiving OAuth seems bass- = ackwards does it not?

 

Further, having rel=3Doauth lets us = define one RFC for all that covers all the security concerns for oauth = discovery.  If we do it your way then every resource that registers = its own discovery also has to have an oauth section that copies the = oauth discovery stuff because there is no longer an oauth discovery = relationship.

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 9, 2016, at 3:16 PM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Please don=E2=80=99t break the = webfinger RFC.

 

If you search for SCIM you can have = additional properties returned as part of the entry, but you only search = for one thing.

 

Webfinger is designed to be very = simple to implement.  In general you just get back the whole = document with all the rel. 

The query filter is a optional = optimization. 

 

The JSON in the doc is by = rel.

 

On Feb 9, 2016, at 8:03 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> = wrote:

 

The rel for scim returns the = endpoint for scim. 

 

The rel for oauth returns endpoints = for oauth. 

 

The query lets the client say i = want the endpoint for oauth used for = scim. 

 

I suppose you could reverse it but = then we'll have oauth discovery happening in different ways across many = different specs. One set of considerations is enough. = :-)

 

Phil


On Feb 9, 2016, at = 14:52, John Bradley <ve7jtb@ve7jtb.com> = wrote:

You would define a rel uri for = SCIM.   The SCIM entry can have sub properties if it supported more = than one auth type,  or you could have a SCIM discovery document = that the URI points to.

 

There are probably multiple ways to = do it.

 

I don=E2=80=99t think trying to = have a oauth rel and then sub types is going to make sense to = developers.  It is also not a good fit for = Webfinger.

 

I also suspect that SCIM is more = naturally part of a authentication service It may be that the = authentication service points at the SCIM = service.

 

Remember that webfinger is a = account alias and may not be the subject that the SP/RP knows the user = as.

 

Each service will need to be = thought through for webfinger as the account identity may mean different = things depending on the protocol, and not every protocol needs per user = discovery.

 

John = B

On Feb 9, 2016, at 7:39 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> = wrote:

 

Another example is to look at scim = discovery(in contrast with connect).

 

When asked separately the answers = may be different. 

 

Asking what is the oauth server for = scim is yet another relation.  So may be we need a scheme for oauth = where query is rs:someval and optionally an acnt value = to. 

 

For = example

Get = ./well-known/webfinger?rel=3Doauth&query=3Drs:scim&acnt:phunt@example.com

<= div>

 

Note i probably have the compound = query syntax wrong. 


Phil


On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com> = wrote:

If we keep webfinger I = don=E2=80=99t think that having a generic OAuth rel makes sense.   = It should be up to each API/Protocol to define it=E2=80=99s own rel = value like Connect has done.

 

It is not reasonable to think that = a persons ID provider is going to be the same as the one for calendaring = or photo sharing.

 

So I could go two ways with = webfinger,  leave it out completely, or leave it in but make it up = to the application to define a rel = value.

I expect that some things using UMA in web-finger would = point directly to the resource and the resource would point the client = at the correct UMA server.

 

The config file name in .well-known = could stay as openid-configuration for historical reasons or we = could change it.

 

I think we first need to decide if = every protocol/API is going to have its own config file, we are going to = get apps to retrieve multiple files,  or everything = is going to go into one config-file and applicatins just add to = that?

 

I prefer not to change the file = name if we are going for one config file, but if we do one alias/link is = probably not the end of the world, as I doubt people will ever = remove openid-configuration one if they have it = now.

 

John = B.

 

 

On Feb 9, 2016, at 2:19 PM, Justin = Richer <jricher@mit.edu> = wrote:

 

Mike, = thanks for putting this up. =

 <= /o:p>

 <= /o:p>

I would = like to propose for two changes that have been brought up = before:

 <= /o:p>

1) The = wholesale removal of section 2, Webfinger = lookup. 

 <= /o:p>

2) The = changing of "/.well-known/openid-configuration=E2=80=9D to = "/.well-known/oauth-authorization-server=E2=80=9D or something else = not openid-related.

 <= /o:p>

 <= /o:p>

 <= /o:p>

 =E2=80= =94 Justin

 <= /o:p>

 <= /o:p>

On Feb 9, = 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 <= /o:p>

 

An = HTML-formatted version is also available = at:

 

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

 

P.S.  = This notice was also posted at http://self-issued.info/?p=3D1= 534 and as @selfissued.

 

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

 <= /o:p>

____________= ___________________________________
OAuth mailing = list
OAuth@ietf.org
<= span lang=3DEN-US>https://www.ietf.org= /mailman/listinfo/oauth

 

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

 

<= /div>

 

<= /div>

 

<= /div>

 

<= /div>

 

 

 

 

 

------=_NextPart_000_08F7_01D165BF.3A2865E0-- From nobody Fri Feb 12 07:59:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD901A1DBD for ; Fri, 12 Feb 2016 07:59:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkJrhlCd51FF for ; Fri, 12 Feb 2016 07:59:05 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 5ADCE1A1EF5 for ; Fri, 12 Feb 2016 07:59:05 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id y9so65660061qgd.3 for ; Fri, 12 Feb 2016 07:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OO5kKSD0VsWejGEC81bk4JWOEU6H0Zt/B/JZEGcOhac=; b=YKoR27i6CbdlDHstwO1a8SM9OfQJlZ3Tm89RmxYMuxtraS0uAQrD/N8D6aXH4NNxfD 88mGraWBt4WEzFF7UuJmyedEz5K2C3Pfp/bnhOKo8JtZWjYGBHj63M3uLhil99EYNdzC BxPRcOuU6sYJLoh9A0ULbOaoiVy2l58V0DiXgd1vFrwZBwvwYnAhLsWMhnFSwN17WLBf +zMoSElGNQiZzceAJEJCbR4gur63e/havlzvaXcyJrzGNfIS07KEwyGGc2VVRDBTm189 XBpJYlBD5SP/8ekc7VutUxSZpaF2TkAxo4dP8hk0RDKzJTB44kYm4jpGwo7+3rQ4girL Cl7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OO5kKSD0VsWejGEC81bk4JWOEU6H0Zt/B/JZEGcOhac=; b=fZUh1WT4424X/Tzee1wvZPbpBUz2zown+kr9arZUCdr+axdB7c6x46rBf4vsYU5ODL OIjYcts1xVqb2ANlSJ+0IrJ5JO40ktsc+95TdPujTz4IlQF3AKy0vjUGIlEFSIHiKAzW K8naQN6+iSAq+pw4BCDM5lmPitpGpwzrf2OGsEWnpLE3P75yNYyCrAz6JKqn7ddU0A8s L8EwkednlknpSSYA8yNLy1KdioW2WlYyzlhBoGCTljCw36GJ0+vOH1mZD5D2N0x71Hqu 8Z+7Ie0QxGptS4z7h7b1gB/sCUYJ24RGwypc5CMW5LeXtyHOBG+Ej/PeZiCyqoI0z6rD iHCQ== X-Gm-Message-State: AG10YORjEb082SXEVo7CEHFdPmQKxa9yVWWnUurBvqRlJXT7rsJke/GPWlhYO4iBOtHolg== X-Received: by 10.140.171.215 with SMTP id r206mr3047397qhr.51.1455292744368; Fri, 12 Feb 2016 07:59:04 -0800 (PST) Received: from [192.168.8.101] ([181.202.13.82]) by smtp.gmail.com with ESMTPSA id 188sm4911726qhi.1.2016.02.12.07.59.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Feb 2016 07:59:02 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9185DA86-B162-4C5A-98FD-0E20D0138FE1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Fri, 12 Feb 2016 12:58:59 -0300 Message-Id: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> References: To: Michael Jones X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 15:59:08 -0000 --Apple-Mail=_9185DA86-B162-4C5A-98FD-0E20D0138FE1 Content-Type: multipart/alternative; boundary="Apple-Mail=_37702704-950C-4716-B2F5-351AA282EDE6" --Apple-Mail=_37702704-950C-4716-B2F5-351AA282EDE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to adopt this draft. > On Feb 12, 2016, at 3:07 AM, Mike Jones = wrote: >=20 > Draft -05 = incorporates the feedback described below - deleting the request = parameter, noting that this spec isn't an encouragement to use OAuth 2.0 = for authentication without employing appropriate extensions, and no = longer requiring a specification for IANA registration. I believe that = it=E2=80=99s now ready for working group adoption. > =20 > -- Mike > =C2=A0 <> > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Thursday, February 4, 2016 11:23 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized > =20 > Hi all, > =20 > On January 19th I posted a call for adoption of the Authentication = Method Reference Values specification, see = http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html = > =20 > What surprised us is that this work is conceptually very simple: we = define new claims and create a registry with new values. Not a big deal = but that's not what the feedback from the Yokohama IETF meeting and the = subsequent call for adoption on the list shows. The feedback lead to = mixed feelings and it is a bit difficult for Derek and myself to judge = consensus. > =20 > Let me tell you what we see from the comments on the list. > =20 > In his review at > http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items. > =20 > William Denniss believes the document is ready for adoption but agrees = with some of the comments from James. Here is his review: > http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html = > =20 > Justin is certainly the reviewer with the strongest opinion. Here is = one of his posts: > http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html = > =20 > Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. > =20 > John agrees with Justin in > http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html = that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the > list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html = > Most of them require more than just editing work. For example, methods = listed are really not useful, > =20 > Phil agrees with the document adoption but has some remarks about the = registry although he does not propose specific text. His review is here: > http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html = > =20 > With my co-chair hat on: I just wanted to clarify that registering = claims (and values within those claims) is within the scope of the OAuth = working group. We standardized the JWT in this group and we are also = chartered to standardize claims, as we are currently doing with various = drafts. Not standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision. > =20 > In its current form, there is not enough support to have this document = as a WG item. > =20 > We believe that the document authors should address some of the easier = comments and submit a new version. This would allow us to reach out to = those who had expressed concerns about the scope of the document to = re-evaluate their decision. A new draft version should at least address = the following issues: > =20 > * Clarify that this document is not an encouragement for using OAuth = as an authentication protocol. I believe that this would address some of = the concerns raised by Justin and John. > =20 > * Change the registry policy, which would address one of the comments = from James, William, and Phil. > =20 > Various other items require discussion since they are more difficult = to address. For example, John noted that he does not like the use of = request parameters. Unfortunately, no alternative is offered. I urge = John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. > Is this what others want as well? > =20 > After these items have been addressed we believe that more folks in = the group will support the document. > =20 > Ciao > Hannes & Derek > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_37702704-950C-4716-B2F5-351AA282EDE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to adopt this draft.

On = Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Draft -05 incorporates the feedback = described below - deleting the request parameter, noting that this spec = isn't an encouragement to use OAuth 2.0 for authentication without = employing appropriate extensions, and no longer requiring a = specification for IANA registration.  I believe that it=E2=80=99s = now ready for working group adoption.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
Sent: Thursday, February 4, 2016 11:23 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] = Authentication Method Reference Values: Call for Adoption = Finalized
 
Hi = all,
 
On = January 19th I posted a call for adoption of the Authentication Method = Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.htm= l
 
What surprised us is that this work is conceptually very = simple: we define new claims and create a registry with new values. Not = a big deal but that's not what the feedback from the Yokohama IETF = meeting and the subsequent call for adoption on the list shows. The = feedback lead to mixed feelings and it is a bit difficult for Derek and = myself to judge consensus.
 
Let me tell you what we see from the = comments on the list.
 
In his review at
http://www.ietf.org/mail-archive/web/oauth/current/msg15423.htm= l James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items.
 
William Denniss believes the document is ready for adoption = but agrees with some of the comments from James. Here is his review:
http://www.ietf.org/mail-archive/web/oauth/current/msg15426.htm= l
 
Justin is certainly the reviewer with the strongest opinion. = Here is one of his posts:
 
Among all concerns Justin expressed the following one is = actually actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter.
 
John agrees with Justin in
http://www.ietf.org/mail-archive/web/oauth/current/msg15448.htm= l that we = need to make sure that people are not mislead about the intention of the = document. John also provides additional comments in this post to the
list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.htm= l
Most of them require more than just editing work. For = example, methods listed are really not useful,
 
Phil = agrees with the document adoption but has some remarks about the = registry although he does not propose specific text. His review is = here:
http://www.ietf.org/mail-archive/web/oauth/current/msg15462.htm= l
 
With my co-chair hat on: I just wanted to clarify that = registering claims (and values within those claims) is within the scope = of the OAuth working group. We standardized the JWT in this group and we = are also chartered to standardize claims, as we are currently doing with = various drafts. Not standardizing JWT in the IETF would have lead to = reduced interoperability and less security. I have no doubts that was a = wrong decision.
 
In its current form, there is not enough support to have this = document as a WG item.
 
We believe that the document authors should address some of = the easier comments and submit a new version. This would allow us to = reach out to those who had expressed concerns about the scope of the = document to re-evaluate their decision. A new draft version should at = least address the following issues:
 
* Clarify that this document is not an = encouragement for using OAuth as an authentication protocol. I believe = that this would address some of the concerns raised by Justin and = John.
 
* Change = the registry policy, which would address one of the comments from James, = William, and Phil.
 
Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" = parameter.
Is this what others want as well?
 
After = these items have been addressed we believe that more folks in the group = will support the document.
 
Ciao
Hannes & Derek
 
 
 
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_37702704-950C-4716-B2F5-351AA282EDE6-- --Apple-Mail=_9185DA86-B162-4C5A-98FD-0E20D0138FE1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTIxNTU4NTlaMCMGCSqGSIb3DQEJBDEWBBQtMbK6NjGDx14vU6upbHer 5pPifjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBGvm4q2y5VvSFhv/UjcSWMQU6oauVEKr6/SLnijy67FKl93uSdIgsb ubtmP23mIEkweN7dkU2frnRsjAQdX90xRAo7n4vnJPT3z5HmQwddDmL2bgijJ/aSfDxG7/06p7sx UTjy7vbrC1vhV56pAYFAVQLdeQd2daPRx8mcdFiLu1wgmNrI7UIgJTZgXXGeHnSvBzVpcwLi56ua oYNZqSFupiVtqi5p8qJgYjE/vL57ga33rLAn/G9lvslwXVX8QC/PFM/EN5e8lTJLkVAnVYJOTqL4 9rcwGXKAcFPkX8TtPTJxf6OC9OtjzBkEcXvRoM5tRnnuxzIuR4i9UZEGFsicAAAAAAAA --Apple-Mail=_9185DA86-B162-4C5A-98FD-0E20D0138FE1-- From nobody Fri Feb 12 08:04:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F821A2119 for ; Fri, 12 Feb 2016 08:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1UYbXHchHAD for ; Fri, 12 Feb 2016 08:04:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98A01A1F1D for ; Fri, 12 Feb 2016 08:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xpxghUxjWKVkj8MZO9RbTgePKWGIYDtEHqti1XsGDxg=; b=S9CkNQ3a0dLu6w2/jlA2ql3vuN5zBR/xvN8eQGYlRvQTUABIDtt3Inb9mf3XKrznw0X6auGVXfuADpmj0acD1h9GUZfY4NiGN3QhIEwdtHHf2EefpDOEh8a7R97OQyfEyObQuiPjJGEtLSaA3G2Jguo3xiOqgiwjuiu9p2gN20s= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 12 Feb 2016 16:04:23 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0396.025; Fri, 12 Feb 2016 16:04:23 +0000 From: Mike Jones To: Thomas Broyer , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Authentication Method Reference Values spec incorporating adoption feedback Thread-Index: AdFlVTP5TWBUSMtZSvC+K8d5oLcJEAAGp10AAA+39KA= Date: Fri, 12 Feb 2016 16:04:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 8d11770e-3270-43ac-7427-08d333c62c89 x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:7sSqqltH2FQAbbYJ+/l0MXLzxCyjqOc1yXoWiKlPf4cuADYuKyJ1nc3gFQqbHfQXmTOssRbuFmBy1x5QGbs7VBy9VHbxTgmcycCotpheCzlZKNI6LDF70cCwwtGGPwGNJma0EbzSEa+2YRdmqdGh2A==; 24:bSMhOOfqkMiu0TNNZTnyRgNCdAmu3q/n4topVIF9earqg0JJMaVB49WV7LlIHfeIIK2b8P5vLvPFFsWS27NLw4JEONPwjgE2nKD91Yz172A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(66066001)(5004730100002)(189998001)(33656002)(19617315012)(5003600100002)(102836003)(1096002)(92566002)(19300405004)(19625215002)(5001770100001)(107886002)(5001960100002)(5008740100001)(5002640100001)(74316001)(86362001)(575784001)(5005710100001)(77096005)(15975445007)(3280700002)(87936001)(16236675004)(40100003)(8990500004)(586003)(2950100001)(2900100001)(3660700001)(122556002)(2906002)(99286002)(10090500001)(2501003)(3846002)(86612001)(76576001)(11100500001)(19580405001)(19580395003)(10290500002)(1220700001)(10400500002)(76176999)(50986999)(19609705001)(54356999)(6116002)(790700001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44249715BC3660B21FB5CCBF5A90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2016 16:04:23.0149 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values spec incorporating adoption feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:04:47 -0000 --_000_BY2PR03MB44249715BC3660B21FB5CCBF5A90BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSGFubmVzIHdyb3RlIGFib3V0IHRoaXMgZHJhZnQgaW4gaGlzIG5vdGUgb24gRmVicnVhcnkg NHRoIGF0IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvWTdJVU16 bmdLRTBHWFhObG9VV3c0VVBCazFvOg0KDQpXaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0 IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmcNCmNsYWltcyAoYW5kIHZhbHVlcyB3 aXRoaW4gdGhvc2UgY2xhaW1zKSBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBPQXV0aA0Kd29y a2luZyBncm91cC4gV2Ugc3RhbmRhcmRpemVkIHRoZSBKV1QgaW4gdGhpcyBncm91cCBhbmQgd2Ug YXJlIGFsc28NCmNoYXJ0ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJy ZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzDQpkcmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBp biB0aGUgSUVURiB3b3VsZCBoYXZlIGxlYWQgdG8gcmVkdWNlZA0KaW50ZXJvcGVyYWJpbGl0eSBh bmQgbGVzcyBzZWN1cml0eS4NCg0KRnJvbTogVGhvbWFzIEJyb3llciBbbWFpbHRvOnQuYnJveWVy QGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTIsIDIwMTYgMTI6MzIgQU0NClRv OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5j ZSBWYWx1ZXMgc3BlYyBpbmNvcnBvcmF0aW5nIGFkb3B0aW9uIGZlZWRiYWNrDQoNCg0KU28sIHlv dSBqdXN0IHJlbW92ZWQgZXZlcnkgcmVsYXRpb25zaGlwIHRvIE9BdXRoIChhbmQgdGhlIG5vdGUg YWJvdXQgT0F1dGggYW5kIGF1dGhlbnRpY2F0aW9uIHNlZW1zIGEgYml0IG91dCBvZiBjb250ZXh0 KSwgYW5kIEkgdGh1cyB3b25kZXIgd2h5IHRoZSBPQXV0aCBXRyB3b3VsZCBhZG9wdCB0aGlzIGRy YWZ0OyB0aGF0J2QgcmF0aGVyIGJlIGEgSk9TRSB0aGluZy4NCg0KTGUgdmVuLiAxMiBmw6l2ci4g MjAxNiAwNzowMywgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiBhIMOpY3JpdCA6DQpUaGlzIGRyYWZ0IG9m IHRoZSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBzcGVjaWZpY2F0aW9u IGluY29ycG9yYXRlcyBPQXV0aCB3b3JraW5nIGdyb3VwIGZlZWRiYWNrIGZyb20gdGhlIGNhbGwg Zm9yIGFkb3B0aW9uLiAgVGhlIHByaW1hcnkgY2hhbmdlIHdhcyB0byByZW1vdmUgdGhlIOKAnGFt cl92YWx1ZXPigJ0gcmVxdWVzdCBwYXJhbWV0ZXIsIHNvIHRoYXQg4oCcYW1y4oCdIHZhbHVlcyBj YW4gc3RpbGwgYmUgcmV0dXJuZWQgYXMgcGFydCBvZiBhbiBhdXRoZW50aWNhdGlvbiByZXN1bHQs IGJ1dCBjYW5ub3QgYmUgZXhwbGljaXRseSByZXF1ZXN0ZWQuICBBbHNvLCBub3RlZCB0aGF0IE9B dXRoIDIuMCBpcyBpbmFkZXF1YXRlIGZvciBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGVtcGxveWlu ZyBhcHByb3ByaWF0ZSBleHRlbnNpb25zIGFuZCBjaGFuZ2VkIHRoZSBJQU5BIHJlZ2lzdHJhdGlv biBwcm9jZWR1cmUgdG8gbm8gbG9uZ2VyIHJlcXVpcmUgYSBzcGVjaWZpY2F0aW9uLg0KDQpUaGUg c3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCuKAoiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTA1DQoNCkFuIEhUTUwt Zm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6DQoNCuKAoiAgICAgICBodHRw Oi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLWFtci12YWx1ZXMtMDUu aHRtbA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpQLlMuICBUaGlzIGFubm91bmNlbWVudCB3YXMgYWxzbyBwb3N0 ZWQgYXQgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTUzOSBhbmQgYXMgQHNlbGZpc3N1ZWQ8 aHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkPi4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg== --_000_BY2PR03MB44249715BC3660B21FB5CCBF5A90BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BcyBIYW5uZXMgd3JvdGUgYWJvdXQgdGhpcyBkcmFmdCBp biBoaXMgbm90ZSBvbiBGZWJydWFyeSA0PHN1cD50aDwvc3VwPiBhdA0KPGEgaHJlZj0iaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9ZN0lVTXpuZ0tFMEdYWE5sb1VX dzRVUEJrMW8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9Z N0lVTXpuZ0tFMEdYWE5sb1VXdzRVUEJrMW88L2E+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5XaXRoIG15IGNvLWNoYWlyIGhh dCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5jbGFpbXMgKGFuZCB2YWx1ZXMgd2l0aGluIHRo b3NlIGNsYWltcykgaXMgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgT0F1dGg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj53b3JraW5nIGdyb3VwLiBXZSBzdGFuZGFyZGl6ZWQg dGhlIEpXVCBpbiB0aGlzIGdyb3VwIGFuZCB3ZSBhcmUgYWxzbzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPmNoYXJ0ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdl IGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q291cmllciI+ZHJhZnRzLiBOb3Qgc3RhbmRhcmRpemluZyBKV1QgaW4gdGhlIElFVEYg d291bGQgaGF2ZSBsZWFkIHRvIHJlZHVjZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpD b3VyaWVyIj5pbnRlcm9wZXJhYmlsaXR5IGFuZCBsZXNzIHNlY3VyaXR5Ljwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBUaG9tYXMgQnJveWVyIFttYWlsdG86dC5icm95ZXJAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMTIsIDIwMTYgMTI6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+ IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs7IG9hdXRoQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9u IE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWMgaW5jb3Jwb3JhdGluZyBhZG9wdGlvbiBmZWVk YmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHA+U28sIHlvdSBqdXN0IHJlbW92ZWQgZXZlcnkgcmVsYXRpb25zaGlw IHRvIE9BdXRoIChhbmQgdGhlIG5vdGUgYWJvdXQgT0F1dGggYW5kIGF1dGhlbnRpY2F0aW9uIHNl ZW1zIGEgYml0IG91dCBvZiBjb250ZXh0KSwgYW5kIEkgdGh1cyB3b25kZXIgd2h5IHRoZSBPQXV0 aCBXRyB3b3VsZCBhZG9wdCB0aGlzIGRyYWZ0OyB0aGF0J2QgcmF0aGVyIGJlIGEgSk9TRSB0aGlu Zy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlJm5ic3A7dmVuLiAxMiBmw6l2ci4g MjAxNiAwNzowMywmbmJzcDtNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyBh IMOpY3JpdCZuYnNwOzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgZHJhZnQgb2YgdGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhv ZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRpb24gaW5jb3Jwb3JhdGVzIE9BdXRoIHdvcmtp bmcgZ3JvdXAgZmVlZGJhY2sgZnJvbSB0aGUgY2FsbCBmb3IgYWRvcHRpb24uJm5ic3A7IFRoZSBw cmltYXJ5IGNoYW5nZSB3YXMgdG8gcmVtb3ZlIHRoZQ0KIOKAnDxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YW1yX3ZhbHVlczwvc3Bhbj7igJ0gcmVxdWVz dCBwYXJhbWV0ZXIsIHNvIHRoYXQg4oCcPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5hbXI8L3NwYW4+4oCdIHZhbHVlcyBjYW4gc3RpbGwgYmUgcmV0dXJu ZWQgYXMgcGFydCBvZiBhbiBhdXRoZW50aWNhdGlvbiByZXN1bHQsIGJ1dCBjYW5ub3QgYmUgZXhw bGljaXRseSByZXF1ZXN0ZWQuJm5ic3A7IEFsc28sIG5vdGVkIHRoYXQNCiBPQXV0aCAyLjAgaXMg aW5hZGVxdWF0ZSBmb3IgYXV0aGVudGljYXRpb24gd2l0aG91dCBlbXBsb3lpbmcgYXBwcm9wcmlh dGUgZXh0ZW5zaW9ucyBhbmQgY2hhbmdlZCB0aGUgSUFOQSByZWdpc3RyYXRpb24gcHJvY2VkdXJl IHRvIG5vIGxvbmdlciByZXF1aXJlIGEgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25l cy1vYXV0aC1hbXItdmFsdWVzLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVlcy0wNTwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFuIEhUTUwtZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFi bGUgYXQ6PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s Ij7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVk LmluZm8vZG9jcy9kcmFmdC1qb25lcy1vYXV0aC1hbXItdmFsdWVzLTA1Lmh0bWwiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLWFt ci12YWx1ZXMtMDUuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QLlMuJm5ic3A7IFRoaXMgYW5ub3VuY2VtZW50 IHdhcyBhbHNvIHBvc3RlZCBhdA0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9 MTUzOSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE1Mzk8L2E+ IGFuZCBhcw0KPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIiB0YXJnZXQ9 Il9ibGFuayI+QHNlbGZpc3N1ZWQ8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB44249715BC3660B21FB5CCBF5A90BY2PR03MB442namprd_-- From nobody Fri Feb 12 08:45:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206391A6FB7 for ; Fri, 12 Feb 2016 08:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2AzOX93OzCj for ; Fri, 12 Feb 2016 08:45:19 -0800 (PST) Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD8A1A6FAE for ; Fri, 12 Feb 2016 08:45:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,436,1449529200"; d="asc'?scan'208";a="86840581" X-IPAS-Result: A2CoBACOC75W/8kN74JeGQEBAQEPAQEBAYJffW0GiFWzIAIFFwqFbAKCBAEBAQEBAYEAC4RBAQEBAQIBAQEBGgZLEAcEAgEIEQQBAQEnAwICJwsUCQgCBBMJBYgECAEDCrJ3jncBAQEBAQEEAQEBAQEBEgiGEYFsCIJChBMBASOCQjgTGIEPBZZ3gTqBSIFkl2WOPmKCMIE0agGGeTQBewEBAQ Received: from umu-ex01.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.201]) by smtp5.umu.se with ESMTP; 12 Feb 2016 17:45:17 +0100 Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX01.ad.umu.se (2002:82ef:dc9::82ef:dc9) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 12 Feb 2016 17:45:17 +0100 Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Fri, 12 Feb 2016 17:45:17 +0100 From: Roland Hedberg To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized Thread-Index: AQHRZa52NFBVrhv6lEWL98m8SaaO2J8ojV8A Date: Fri, 12 Feb 2016 16:45:17 +0000 Message-ID: References: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> In-Reply-To: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [81.170.242.121] Content-Type: multipart/signed; boundary="Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:45:23 -0000 --Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > 12 feb 2016 kl. 16:58 skrev John Bradley : >=20 > +1 to adopt this draft. >=20 >> On Feb 12, 2016, at 3:07 AM, Mike Jones = wrote: >>=20 >> Draft -05 incorporates the feedback described below - deleting the = request parameter, noting that this spec isn't an encouragement to use = OAuth 2.0 for authentication without employing appropriate extensions, = and no longer requiring a specification for IANA registration. I = believe that it=E2=80=99s now ready for working group adoption. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig >> Sent: Thursday, February 4, 2016 11:23 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized >>=20 >> Hi all, >>=20 >> On January 19th I posted a call for adoption of the Authentication = Method Reference Values specification, see = http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html >>=20 >> What surprised us is that this work is conceptually very simple: we = define new claims and create a registry with new values. Not a big deal = but that's not what the feedback from the Yokohama IETF meeting and the = subsequent call for adoption on the list shows. The feedback lead to = mixed feelings and it is a bit difficult for Derek and myself to judge = consensus. >>=20 >> Let me tell you what we see from the comments on the list. >>=20 >> In his review at >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James Manger asks for significant changes. Among other things, he wants = to remove one of the claims. He provides a detailed review and = actionable items. >>=20 >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>=20 >> Justin is certainly the reviewer with the strongest opinion. Here is = one of his posts: >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>=20 >> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. >>=20 >> John agrees with Justin in >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the >> list: = http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >> Most of them require more than just editing work. For example, = methods listed are really not useful, >>=20 >> Phil agrees with the document adoption but has some remarks about the = registry although he does not propose specific text. His review is here: >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>=20 >> With my co-chair hat on: I just wanted to clarify that registering = claims (and values within those claims) is within the scope of the OAuth = working group. We standardized the JWT in this group and we are also = chartered to standardize claims, as we are currently doing with various = drafts. Not standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision. >>=20 >> In its current form, there is not enough support to have this = document as a WG item. >>=20 >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: >>=20 >> * Clarify that this document is not an encouragement for using OAuth = as an authentication protocol. I believe that this would address some of = the concerns raised by Justin and John. >>=20 >> * Change the registry policy, which would address one of the comments = from James, William, and Phil. >>=20 >> Various other items require discussion since they are more difficult = to address. For example, John noted that he does not like the use of = request parameters. Unfortunately, no alternative is offered. I urge = John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. >> Is this what others want as well? >>=20 >> After these items have been addressed we believe that more folks in = the group will support the document. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth =E2=80=94 Roland =E2=80=9DEverybody should be quiet near a little stream and listen." =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss --Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWvgwcAAoJEMHjX+0KUIOoINcQAKUhOaQV9Iswfm3lAT6WEyAJ VxuHUGnMOOv3J2qCrzYO1XnyUH8p2vtqtHvNYf6lM4RrIUessN8M3MWWmgTcHAbA pWrJ3J+K8v9dDObj9J/95bN1s/7pE5/Y6TItHof+S7Mg6bLQBfSmi4seARw0Nkk1 2ol0oNgiJHOERTW1BGWpAXIprc5sogEsI8BQd0N8u21uyxCflh9plLcRg/ouwTot aOn3shlCS77MkHxweTvA0ma3MZWqXCqKvp4zkzNv5L6HB9kHZ+TRMWRhsBQ4/1bU fwjTxxlVfaAUP9rW91K1Cs/z94k3uR+QRZlyib4fM+mJ8gLZNdd9OpZeWyj9eBua 8QFh/qI+ZvRbk2kSIn367bpqDq/4Ph2tcH0f5agKhyproW+vhl0umT8+UddW7SZd EByMTmHEnNrYDaFuQAURl9YiZprW3O5bJe8NDxa2hO7ISgKRZEAAIwZyASNs2GIq SGhavserv6/cfocOOdAOYcxiXDBeMAxfSiWeaxVeAwQtu1k+V+e1tl8O9EYRRo2P CPuLCX2EeZr4I2XMcaHP/BF9hkHSYyhabYLDv3BrgmWJV2K2/TEymc0BC+IIWm+L j2q5sgBmHZLEUFb7xnGfiNKzq2XAHZb6XDufpEIfTFDjhDA49N9mOjpFNhLAXx+Q kY4hq2Y6RZKhnv5221U/ =cF1Y -----END PGP SIGNATURE----- --Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743-- From nobody Sat Feb 13 04:18:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E191B31A5 for ; Sat, 13 Feb 2016 04:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLmZb2lITm7X for ; Sat, 13 Feb 2016 04:18:41 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAA41B31A3 for ; Sat, 13 Feb 2016 04:18:40 -0800 (PST) Received: from [79.218.87.147] (helo=[192.168.71.137]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aUZ9r-0006MA-Mj; Sat, 13 Feb 2016 13:18:40 +0100 Date: Sat, 13 Feb 2016 13:18:32 +0100 Message-ID: <1ly54p9jm7ym5qagjg42ftlw.1455365912992@com.syntomo.email> In-Reply-To: References: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> From: "torsten@lodderstedt.net" To: roland.hedberg@umu.se, oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_671828510119500" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 12:18:45 -0000 ----_com.syntomo.email_671828510119500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBiYXNpY2FsbHkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBBc3NlcnRpbmcg YXV0aGVudGljYXRpb24gbWV0aG9kcyBpbiBhY2Nlc3MgdG9rZW5zIChpbiB0aGlzIGNhc2UgaW4g SldUUyBmb3JtYXQpIGlzIHJlYXNvbmFibGUuIFdlIHVzZSBpdCB0byBwYXNzIGluZm9ybWF0aW9u IGFib3V0IHRoZSBhdXRoZW50aWNhdGlvbiBwZXJmb3JtZWQgcHJpb3IgaXNzdWluZyBhbiBhY2Nl c3MgdG9rZW4gdG8gdGhlIF9yZXNvdXJjZV8gc2VydmVyLiAKCldoYXQgd29ycmllcyBtZSBpcyB0 aGUgYmFjayBhbmQgZm9ydGggYmV0d2VlbiBvYXV0aCBhbmQgb2lkYy4gVGhlIGFtciBjbGFpbSBp cyBkZWZpbmVkIGluIG9pZGMgKHdoaWNoIHNpdHMgb24gdG9wIG9mIG9hdXRoKSBidXQgdGhlIG9h dXRoIHdnIHNwZWNpZmllcyB0aGUgcmVnaXN0cnk/IE1vcmVvdmVyLCB0aGUgY3VycmVudCB0ZXh0 IGRvZXMgbm90IGdpdmUgYSByYXRpb25hbGUgZm9yIHVzaW5nIGFtciBpbiBjb250ZXh0IG9mIG9h dXRoLgoKQXMgYSBXRyB3ZSBuZWVkIHRvIGZpbmQgYSBjbGVhciBkZWxpbmVhdGlvbiBiZXR3ZWVu IGJvdGggcHJvdG9jb2xzLCBvdGhlcndpc2Ugbm9vbmUgd2lsbCByZWFsbHkgdW5kZXJzdGFuZCB0 aGUgZGlmZmVyZW5jZSBhbmQgd2hlbiB0byB1c2Ugd2hhdC4gV2UgY3JlYXRlIGNvbmZ1c2lvbiEg CgpGb3IgdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1y IHRvIG9hdXRoIG9yIHRoZSByZWdpc3RyeSB0byBvaWRjLiAKCmJlc3QgcmVnYXJkcywgClRvcnN0 ZW4uCgotLS0tLS0tLSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0KVm9uOiBSb2xh bmQgSGVkYmVyZyA8cm9sYW5kLmhlZGJlcmdAdW11LnNlPgpHZXNlbmRldDogRnJpZGF5LCBGZWJy dWFyeSAxMiwgMjAxNiAwNTo0NSBQTQpBbjogb2F1dGhAaWV0Zi5vcmcKQmV0cmVmZjogUmU6IFtP QVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9y IEFkb3B0aW9uIEZpbmFsaXplZAoKPisxCj4KPj4gMTIgZmViIDIwMTYga2wuIDE2OjU4IHNrcmV2 IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+Ogo+PiAKPj4gKzEgdG8gYWRvcHQgdGhp cyBkcmFmdC4KPj4gCj4+PiBPbiBGZWIgMTIsIDIwMTYsIGF0IDM6MDcgQU0sIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4+PiAKPj4+IERyYWZ0IC0wNSBp bmNvcnBvcmF0ZXMgdGhlIGZlZWRiYWNrIGRlc2NyaWJlZCBiZWxvdyAtIGRlbGV0aW5nIHRoZSBy ZXF1ZXN0IHBhcmFtZXRlciwgbm90aW5nIHRoYXQgdGhpcyBzcGVjIGlzbid0IGFuIGVuY291cmFn ZW1lbnQgdG8gdXNlIE9BdXRoIDIuMCBmb3IgYXV0aGVudGljYXRpb24gd2l0aG91dCBlbXBsb3lp bmcgYXBwcm9wcmlhdGUgZXh0ZW5zaW9ucywgYW5kIG5vIGxvbmdlciByZXF1aXJpbmcgYSBzcGVj aWZpY2F0aW9uIGZvciBJQU5BIHJlZ2lzdHJhdGlvbi4gIEkgYmVsaWV2ZSB0aGF0IGl04oCZcyBu b3cgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24uCj4+PiAKPj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlCj4+ PiAKPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+PiBGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZwo+ Pj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgMTE6MjMgQU0KPj4+IFRvOiBvYXV0 aEBpZXRmLm9yZwo+Pj4gU3ViamVjdDogW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2Qg UmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24gRmluYWxpemVkCj4+PiAKPj4+IEhp IGFsbCwKPj4+IAo+Pj4gT24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRp b24gb2YgdGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmlj YXRpb24sIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQwMi5odG1sCj4+PiAKPj4+IFdoYXQgc3VycHJpc2VkIHVzIGlzIHRoYXQgdGhp cyB3b3JrIGlzIGNvbmNlcHR1YWxseSB2ZXJ5IHNpbXBsZTogd2UgZGVmaW5lIG5ldyBjbGFpbXMg YW5kIGNyZWF0ZSBhIHJlZ2lzdHJ5IHdpdGggbmV3IHZhbHVlcy4gTm90IGEgYmlnIGRlYWwgYnV0 IHRoYXQncyBub3Qgd2hhdCB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgWW9rb2hhbWEgSUVURiBtZWV0 aW5nIGFuZCB0aGUgc3Vic2VxdWVudCBjYWxsIGZvciBhZG9wdGlvbiBvbiB0aGUgbGlzdCBzaG93 cy4gVGhlIGZlZWRiYWNrIGxlYWQgdG8gbWl4ZWQgZmVlbGluZ3MgYW5kIGl0IGlzIGEgYml0IGRp ZmZpY3VsdCBmb3IgRGVyZWsgYW5kIG15c2VsZiB0byBqdWRnZSBjb25zZW5zdXMuCj4+PiAKPj4+ IExldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBvbiB0aGUgbGlz dC4KPj4+IAo+Pj4gSW4gaGlzIHJldmlldyBhdAo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRtbCBKYW1lcyBNYW5nZXIgYXNr cyBmb3Igc2lnbmlmaWNhbnQgY2hhbmdlcy4gQW1vbmcgb3RoZXIgdGhpbmdzLCBoZSB3YW50cyB0 byByZW1vdmUgb25lIG9mIHRoZSBjbGFpbXMuIEhlIHByb3ZpZGVzIGEgZGV0YWlsZWQgcmV2aWV3 IGFuZCBhY3Rpb25hYmxlIGl0ZW1zLgo+Pj4gCj4+PiBXaWxsaWFtIERlbm5pc3MgYmVsaWV2ZXMg dGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhZG9wdGlvbiBidXQgYWdyZWVzIHdpdGggc29tZSBv ZiB0aGUgY29tbWVudHMgZnJvbSBKYW1lcy4gSGVyZSBpcyBoaXMgcmV2aWV3Ogo+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjYuaHRt bAo+Pj4gCj4+PiBKdXN0aW4gaXMgY2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJv bmdlc3Qgb3Bpbmlvbi4gSGVyZSBpcyBvbmUgb2YgaGlzIHBvc3RzOgo+Pj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NTcuaHRtbAo+Pj4g Cj4+PiBBbW9uZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5nIG9u ZSBpcyBhY3R1YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQgcmVw b3J0aW5nIGhvdyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgYW5kIGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRpY2F0 aW9uIGlzIGEgZmluZSBsaW5lLiBIZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9jdW1lbnQgbGVhZHMg cmVhZGVycyB0byBiZWxpZXZlIHRoZSBsYXR0ZXIuCj4+PiAKPj4+IEpvaG4gYWdyZWVzIHdpdGgg SnVzdGluIGluCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQ0OC5odG1sIHRoYXQgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9w bGUgYXJlIG5vdCBtaXNsZWFkIGFib3V0IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBK b2huIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbCBjb21tZW50cyBpbiB0aGlzIHBvc3QgdG8gdGhl Cj4+PiBsaXN0OiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQ0MS5odG1sCj4+PiBNb3N0IG9mIHRoZW0gcmVxdWlyZSBtb3JlIHRoYW4ganVz dCBlZGl0aW5nIHdvcmsuIEZvciBleGFtcGxlLCBtZXRob2RzIGxpc3RlZCBhcmUgcmVhbGx5IG5v dCB1c2VmdWwsCj4+PiAKPj4+IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9u IGJ1dCBoYXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2Vz IG5vdCBwcm9wb3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZToKPj4+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDYyLmh0 bWwKPj4+IAo+Pj4gV2l0aCBteSBjby1jaGFpciBoYXQgb246IEkganVzdCB3YW50ZWQgdG8gY2xh cmlmeSB0aGF0IHJlZ2lzdGVyaW5nIGNsYWltcyAoYW5kIHZhbHVlcyB3aXRoaW4gdGhvc2UgY2xh aW1zKSBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLiBXZSBz dGFuZGFyZGl6ZWQgdGhlIEpXVCBpbiB0aGlzIGdyb3VwIGFuZCB3ZSBhcmUgYWxzbyBjaGFydGVy ZWQgdG8gc3RhbmRhcmRpemUgY2xhaW1zLCBhcyB3ZSBhcmUgY3VycmVudGx5IGRvaW5nIHdpdGgg dmFyaW91cyBkcmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBpbiB0aGUgSUVURiB3b3VsZCBo YXZlIGxlYWQgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCBsZXNzIHNlY3VyaXR5LiBJ IGhhdmUgbm8gZG91YnRzIHRoYXQgd2FzIGEgd3JvbmcgZGVjaXNpb24uCj4+PiAKPj4+IEluIGl0 cyBjdXJyZW50IGZvcm0sIHRoZXJlIGlzIG5vdCBlbm91Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMg ZG9jdW1lbnQgYXMgYSBXRyBpdGVtLgo+Pj4gCj4+PiBXZSBiZWxpZXZlIHRoYXQgdGhlIGRvY3Vt ZW50IGF1dGhvcnMgc2hvdWxkIGFkZHJlc3Mgc29tZSBvZiB0aGUgZWFzaWVyIGNvbW1lbnRzIGFu ZCBzdWJtaXQgYSBuZXcgdmVyc2lvbi4gVGhpcyB3b3VsZCBhbGxvdyB1cyB0byByZWFjaCBvdXQg dG8gdGhvc2Ugd2hvIGhhZCBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgdGhlIHNjb3BlIG9mIHRo ZSBkb2N1bWVudCB0byByZS1ldmFsdWF0ZSB0aGVpciBkZWNpc2lvbi4gQSBuZXcgZHJhZnQgdmVy c2lvbiBzaG91bGQgYXQgbGVhc3QgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3VlczoKPj4+IAo+ Pj4gKiBDbGFyaWZ5IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBub3QgYW4gZW5jb3VyYWdlbWVudCBm b3IgdXNpbmcgT0F1dGggYXMgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wuIEkgYmVsaWV2ZSB0 aGF0IHRoaXMgd291bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBjb25jZXJucyByYWlzZWQgYnkgSnVz dGluIGFuZCBKb2huLgo+Pj4gCj4+PiAqIENoYW5nZSB0aGUgcmVnaXN0cnkgcG9saWN5LCB3aGlj aCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0aGUgY29tbWVudHMgZnJvbSBKYW1lcywgV2lsbGlhbSwg YW5kIFBoaWwuCj4+PiAKPj4+IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9u IHNpbmNlIHRoZXkgYXJlIG1vcmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBK b2huIG5vdGVkIHRoYXQgaGUgZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1l dGVycy4gVW5mb3J0dW5hdGVseSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpv aG4gdG8gcHJvdmlkZSBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUgaXMgb25lLiBB bHNvLCB0aGUgcmVtYXJrIHRoYXQgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291bGQgYmUg Y291bnRlcmVkIHdpdGggYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwuIEphbWVzIHdhbnRlZCB0byBy ZW1vdmUgdGhlICJhbXJfdmFsdWVzIiBwYXJhbWV0ZXIuCj4+PiBJcyB0aGlzIHdoYXQgb3RoZXJz IHdhbnQgYXMgd2VsbD8KPj4+IAo+Pj4gQWZ0ZXIgdGhlc2UgaXRlbXMgaGF2ZSBiZWVuIGFkZHJl c3NlZCB3ZSBiZWxpZXZlIHRoYXQgbW9yZSBmb2xrcyBpbiB0aGUgZ3JvdXAgd2lsbCBzdXBwb3J0 IHRoZSBkb2N1bWVudC4KPj4+IAo+Pj4gQ2lhbwo+Pj4gSGFubmVzICYgRGVyZWsKPj4+IAo+Pj4g Cj4+PiAKPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+IE9BdXRoQGlldGYub3JnCj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+IAo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4g T0F1dGhAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aAo+Cj7igJQgUm9sYW5kCj4KPuKAnUV2ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBh IGxpdHRsZSBzdHJlYW0gYW5kIGxpc3Rlbi4iCj5Gcm9tIOKAmU9wZW4gSG91c2UgZm9yIEJ1dHRl cmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzCj4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPk9BdXRoIG1haWxpbmcgbGlzdAo+T0F1dGhAaWV0Zi5vcmcK Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK ----_com.syntomo.email_671828510119500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkkgYmFzaWNhbGx5IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu dC4gQXNzZXJ0aW5nIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgaW4gYWNjZXNzIHRva2VucyAoaW4g dGhpcyBjYXNlIGluIEpXVFMgZm9ybWF0KSBpcyByZWFzb25hYmxlLiBXZSB1c2UgaXQgdG8gcGFz cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIHByaW9yIGlz c3VpbmcgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfIHNlcnZlci4gPC9wPgo8cCBk aXI9Imx0ciI+V2hhdCB3b3JyaWVzIG1lIGlzIHRoZSBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVuIG9h dXRoIGFuZCBvaWRjLiBUaGUgYW1yIGNsYWltIGlzIGRlZmluZWQgaW4gb2lkYyAod2hpY2ggc2l0 cyBvbiB0b3Agb2Ygb2F1dGgpIGJ1dCB0aGUgb2F1dGggd2cgc3BlY2lmaWVzIHRoZSByZWdpc3Ry eT8gTW9yZW92ZXIsIHRoZSBjdXJyZW50IHRleHQgZG9lcyBub3QgZ2l2ZSBhIHJhdGlvbmFsZSBm b3IgdXNpbmcgYW1yIGluIGNvbnRleHQgb2Ygb2F1dGguPC9wPgo8cCBkaXI9Imx0ciI+QXMgYSBX RyB3ZSBuZWVkIHRvIGZpbmQgYSBjbGVhciBkZWxpbmVhdGlvbiBiZXR3ZWVuIGJvdGggcHJvdG9j b2xzLCBvdGhlcndpc2Ugbm9vbmUgd2lsbCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5j ZSBhbmQgd2hlbiB0byB1c2Ugd2hhdC4gV2UgY3JlYXRlIGNvbmZ1c2lvbiEgPC9wPgo8cCBkaXI9 Imx0ciI+Rm9yIHRoaXMgcGFydGljdWxhciBkcmFmdCB0aGlzIG1lYW5zIHRvIGVpdGhlciBtb3Zl IGFtciB0byBvYXV0aCBvciB0aGUgcmVnaXN0cnkgdG8gb2lkYy4gPC9wPgo8cCBkaXI9Imx0ciI+ YmVzdCByZWdhcmRzLCA8YnI+ClRvcnN0ZW4uPC9wPgo8YnI+PGJyPi0tLS0tLS0tIFVyc3Byw7xu Z2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLTxicj5Wb246IFJvbGFuZCBIZWRiZXJnICZsdDtyb2xh bmQuaGVkYmVyZ0B1bXUuc2UmZ3Q7PGJyPkdlc2VuZGV0OiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAy MDE2IDA1OjQ1IFBNPGJyPkFuOiBvYXV0aEBpZXRmLm9yZzxicj5CZXRyZWZmOiBSZTogW09BVVRI LVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRv cHRpb24gRmluYWxpemVkPGJyPjxicj48cD4rMTxicj48YnI+Jmd0OyAxMiBmZWIgMjAxNiBrbC4g MTY6NTggc2tyZXYgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs6PGJyPiZn dDsgPGJyPiZndDsgKzEgdG8gYWRvcHQgdGhpcyBkcmFmdC48YnI+Jmd0OyA8YnI+Jmd0OyZndDsg T24gRmViIDEyLCAyMDE2LCBhdCAzOjA3IEFNLCBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20mZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgRHJhZnQg LTA1IGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sgZGVzY3JpYmVkIGJlbG93IC0gZGVsZXRpbmcg dGhlIHJlcXVlc3QgcGFyYW1ldGVyLCBub3RpbmcgdGhhdCB0aGlzIHNwZWMgaXNuJ3QgYW4gZW5j b3VyYWdlbWVudCB0byB1c2UgT0F1dGggMi4wIGZvciBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGVt cGxveWluZyBhcHByb3ByaWF0ZSBleHRlbnNpb25zLCBhbmQgbm8gbG9uZ2VyIHJlcXVpcmluZyBh IHNwZWNpZmljYXRpb24gZm9yIElBTkEgcmVnaXN0cmF0aW9uLiZuYnNwOyBJIGJlbGlldmUgdGhh dCBpdOKAmXMgbm93IHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLjxicj4mZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsgRnJvbTogT0F1dGggW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWc8YnI+ Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgMTE6MjMgQU08YnI+Jmd0 OyZndDsgVG86IG9hdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10g QXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9u IEZpbmFsaXplZDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgSGkgYWxsLDxicj4mZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsgT24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24g b2YgdGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRp b24sIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cxNTQwMi5odG1sPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBXaGF0IHN1cnByaXNlZCB1 cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmlu ZSBuZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBh IGJpZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29o YW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24g dGhlIGxpc3Qgc2hvd3MuIFRoZSBmZWVkYmFjayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBp dCBpcyBhIGJpdCBkaWZmaWN1bHQgZm9yIERlcmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vu c3VzLjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgTGV0IG1lIHRlbGwgeW91IHdoYXQgd2Ugc2Vl IGZyb20gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0Ljxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsg SW4gaGlzIHJldmlldyBhdDxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyMy5odG1sIEphbWVzIE1hbmdlciBhc2tzIGZv ciBzaWduaWZpY2FudCBjaGFuZ2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhlIHdhbnRzIHRvIHJl bW92ZSBvbmUgb2YgdGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxlZCByZXZpZXcgYW5k IGFjdGlvbmFibGUgaXRlbXMuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBXaWxsaWFtIERlbm5p c3MgYmVsaWV2ZXMgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhZG9wdGlvbiBidXQgYWdyZWVz IHdpdGggc29tZSBvZiB0aGUgY29tbWVudHMgZnJvbSBKYW1lcy4gSGVyZSBpcyBoaXMgcmV2aWV3 Ojxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQyNi5odG1sPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBKdXN0aW4gaXMg Y2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJvbmdlc3Qgb3Bpbmlvbi4gSGVyZSBp cyBvbmUgb2YgaGlzIHBvc3RzOjxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ1Ny5odG1sPGJyPiZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyBBbW9uZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5n IG9uZSBpcyBhY3R1YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQg cmVwb3J0aW5nIGhvdyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQgYW5kIGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRp Y2F0aW9uIGlzIGEgZmluZSBsaW5lLiBIZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9jdW1lbnQgbGVh ZHMgcmVhZGVycyB0byBiZWxpZXZlIHRoZSBsYXR0ZXIuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0 OyBKb2huIGFncmVlcyB3aXRoIEp1c3RpbiBpbjxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1sIHRoYXQgd2Ug bmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9wbGUgYXJlIG5vdCBtaXNsZWFkIGFib3V0IHRoZSBp bnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBKb2huIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbCBj b21tZW50cyBpbiB0aGlzIHBvc3QgdG8gdGhlPGJyPiZndDsmZ3Q7IGxpc3Q6IGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWw8YnI+ Jmd0OyZndDsgTW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGluZyB3b3Jr LiBGb3IgZXhhbXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVsLDxicj4m Z3Q7Jmd0OyA8YnI+Jmd0OyZndDsgUGhpbCBhZ3JlZXMgd2l0aCB0aGUgZG9jdW1lbnQgYWRvcHRp b24gYnV0IGhhcyBzb21lIHJlbWFya3MgYWJvdXQgdGhlIHJlZ2lzdHJ5IGFsdGhvdWdoIGhlIGRv ZXMgbm90IHByb3Bvc2Ugc3BlY2lmaWMgdGV4dC4gSGlzIHJldmlldyBpcyBoZXJlOjxicj4mZ3Q7 Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9t c2cxNTQ2Mi5odG1sPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBXaXRoIG15IGNvLWNoYWlyIGhh dCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmcgY2xhaW1zIChh bmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhl IE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXplZCB0aGUgSldUIGluIHRoaXMgZ3Jv dXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdl IGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzIGRyYWZ0cy4gTm90IHN0YW5kYXJkaXpp bmcgSldUIGluIHRoZSBJRVRGIHdvdWxkIGhhdmUgbGVhZCB0byByZWR1Y2VkIGludGVyb3BlcmFi aWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHkuIEkgaGF2ZSBubyBkb3VidHMgdGhhdCB3YXMgYSB3cm9u ZyBkZWNpc2lvbi48YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEluIGl0cyBjdXJyZW50IGZvcm0s IHRoZXJlIGlzIG5vdCBlbm91Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMgZG9jdW1lbnQgYXMgYSBX RyBpdGVtLjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgV2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1 bWVudCBhdXRob3JzIHNob3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGVhc2llciBjb21tZW50cyBh bmQgc3VibWl0IGEgbmV3IHZlcnNpb24uIFRoaXMgd291bGQgYWxsb3cgdXMgdG8gcmVhY2ggb3V0 IHRvIHRob3NlIHdobyBoYWQgZXhwcmVzc2VkIGNvbmNlcm5zIGFib3V0IHRoZSBzY29wZSBvZiB0 aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVhdGUgdGhlaXIgZGVjaXNpb24uIEEgbmV3IGRyYWZ0IHZl cnNpb24gc2hvdWxkIGF0IGxlYXN0IGFkZHJlc3MgdGhlIGZvbGxvd2luZyBpc3N1ZXM6PGJyPiZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyAqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBh biBlbmNvdXJhZ2VtZW50IGZvciB1c2luZyBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90 b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNl cm5zIHJhaXNlZCBieSBKdXN0aW4gYW5kIEpvaG4uPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyAq IENoYW5nZSB0aGUgcmVnaXN0cnkgcG9saWN5LCB3aGljaCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0 aGUgY29tbWVudHMgZnJvbSBKYW1lcywgV2lsbGlhbSwgYW5kIFBoaWwuPGJyPiZndDsmZ3Q7IDxi cj4mZ3Q7Jmd0OyBWYXJpb3VzIG90aGVyIGl0ZW1zIHJlcXVpcmUgZGlzY3Vzc2lvbiBzaW5jZSB0 aGV5IGFyZSBtb3JlIGRpZmZpY3VsdCB0byBhZGRyZXNzLiBGb3IgZXhhbXBsZSwgSm9obiBub3Rl ZCB0aGF0IGhlIGRvZXMgbm90IGxpa2UgdGhlIHVzZSBvZiByZXF1ZXN0IHBhcmFtZXRlcnMuIFVu Zm9ydHVuYXRlbHksIG5vIGFsdGVybmF0aXZlIGlzIG9mZmVyZWQuIEkgdXJnZSBKb2huIHRvIHBy b3ZpZGUgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwsIGlmIHRoZXJlIGlzIG9uZS4gQWxzbywgdGhl IHJlbWFyayB0aGF0IHRoZSB2YWx1ZXMgYXJlIG1lYW5pbmdsZXNzIGNvdWxkIGJlIGNvdW50ZXJl ZCB3aXRoIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLiBKYW1lcyB3YW50ZWQgdG8gcmVtb3ZlIHRo ZSAiYW1yX3ZhbHVlcyIgcGFyYW1ldGVyLjxicj4mZ3Q7Jmd0OyBJcyB0aGlzIHdoYXQgb3RoZXJz IHdhbnQgYXMgd2VsbD88YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEFmdGVyIHRoZXNlIGl0ZW1z IGhhdmUgYmVlbiBhZGRyZXNzZWQgd2UgYmVsaWV2ZSB0aGF0IG1vcmUgZm9sa3MgaW4gdGhlIGdy b3VwIHdpbGwgc3VwcG9ydCB0aGUgZG9jdW1lbnQuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBD aWFvPGJyPiZndDsmZ3Q7IEhhbm5lcyAmYW1wOyBEZXJlazxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsgPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0 OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy PiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPGJyPjxicj7igJQgUm9sYW5kPGJyPjxicj7igJ1FdmVyeWJvZHkgc2hv dWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIjxicj5Gcm9tIOKA mU9wZW4gSG91c2UgZm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzPGJyPjxicj48YnI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGgg bWFpbGluZyBsaXN0PGJyPk9BdXRoQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+PC9wPg== ----_com.syntomo.email_671828510119500-- From nobody Sat Feb 13 04:18:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B381B31A3 for ; Sat, 13 Feb 2016 04:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwWi9ZoQx4IY for ; Sat, 13 Feb 2016 04:18:41 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAE11B31A4 for ; Sat, 13 Feb 2016 04:18:40 -0800 (PST) Received: from [79.218.87.147] (helo=[192.168.71.137]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aUZ8F-0006KP-9J; Sat, 13 Feb 2016 13:16:59 +0100 Date: Sat, 13 Feb 2016 13:18:32 +0100 Message-ID: <1ly54p9jm7ym5qagjg42ftlw.1455365912992@com.syntomo.email> In-Reply-To: References: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> From: "torsten@lodderstedt.net" To: roland.hedberg@umu.se, oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_671835454102421" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 12:18:45 -0000 ----_com.syntomo.email_671835454102421 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBiYXNpY2FsbHkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBBc3NlcnRpbmcg YXV0aGVudGljYXRpb24gbWV0aG9kcyBpbiBhY2Nlc3MgdG9rZW5zIChpbiB0aGlzIGNhc2UgaW4g SldUUyBmb3JtYXQpIGlzIHJlYXNvbmFibGUuIFdlIHVzZSBpdCB0byBwYXNzIGluZm9ybWF0aW9u IGFib3V0IHRoZSBhdXRoZW50aWNhdGlvbiBwZXJmb3JtZWQgcHJpb3IgaXNzdWluZyBhbiBhY2Nl c3MgdG9rZW4gdG8gdGhlIF9yZXNvdXJjZV8gc2VydmVyLiAKCldoYXQgd29ycmllcyBtZSBpcyB0 aGUgYmFjayBhbmQgZm9ydGggYmV0d2VlbiBvYXV0aCBhbmQgb2lkYy4gVGhlIGFtciBjbGFpbSBp cyBkZWZpbmVkIGluIG9pZGMgKHdoaWNoIHNpdHMgb24gdG9wIG9mIG9hdXRoKSBidXQgdGhlIG9h dXRoIHdnIHNwZWNpZmllcyB0aGUgcmVnaXN0cnk/IE1vcmVvdmVyLCB0aGUgY3VycmVudCB0ZXh0 IGRvZXMgbm90IGdpdmUgYSByYXRpb25hbGUgZm9yIHVzaW5nIGFtciBpbiBjb250ZXh0IG9mIG9h dXRoLgoKQXMgYSBXRyB3ZSBuZWVkIHRvIGZpbmQgYSBjbGVhciBkZWxpbmVhdGlvbiBiZXR3ZWVu IGJvdGggcHJvdG9jb2xzLCBvdGhlcndpc2Ugbm9vbmUgd2lsbCByZWFsbHkgdW5kZXJzdGFuZCB0 aGUgZGlmZmVyZW5jZSBhbmQgd2hlbiB0byB1c2Ugd2hhdC4gV2UgY3JlYXRlIGNvbmZ1c2lvbiEg CgpGb3IgdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1y IHRvIG9hdXRoIG9yIHRoZSByZWdpc3RyeSB0byBvaWRjLiAKCmJlc3QgcmVnYXJkcywgClRvcnN0 ZW4uCgotLS0tLS0tLSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0KVm9uOiBSb2xh bmQgSGVkYmVyZyA8cm9sYW5kLmhlZGJlcmdAdW11LnNlPgpHZXNlbmRldDogRnJpZGF5LCBGZWJy dWFyeSAxMiwgMjAxNiAwNTo0NSBQTQpBbjogb2F1dGhAaWV0Zi5vcmcKQmV0cmVmZjogUmU6IFtP QVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9y IEFkb3B0aW9uIEZpbmFsaXplZAoKPisxCj4KPj4gMTIgZmViIDIwMTYga2wuIDE2OjU4IHNrcmV2 IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+Ogo+PiAKPj4gKzEgdG8gYWRvcHQgdGhp cyBkcmFmdC4KPj4gCj4+PiBPbiBGZWIgMTIsIDIwMTYsIGF0IDM6MDcgQU0sIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4+PiAKPj4+IERyYWZ0IC0wNSBp bmNvcnBvcmF0ZXMgdGhlIGZlZWRiYWNrIGRlc2NyaWJlZCBiZWxvdyAtIGRlbGV0aW5nIHRoZSBy ZXF1ZXN0IHBhcmFtZXRlciwgbm90aW5nIHRoYXQgdGhpcyBzcGVjIGlzbid0IGFuIGVuY291cmFn ZW1lbnQgdG8gdXNlIE9BdXRoIDIuMCBmb3IgYXV0aGVudGljYXRpb24gd2l0aG91dCBlbXBsb3lp bmcgYXBwcm9wcmlhdGUgZXh0ZW5zaW9ucywgYW5kIG5vIGxvbmdlciByZXF1aXJpbmcgYSBzcGVj aWZpY2F0aW9uIGZvciBJQU5BIHJlZ2lzdHJhdGlvbi4gIEkgYmVsaWV2ZSB0aGF0IGl04oCZcyBu b3cgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24uCj4+PiAKPj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlCj4+ PiAKPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+PiBGcm9tOiBPQXV0aCBbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZwo+ Pj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgMTE6MjMgQU0KPj4+IFRvOiBvYXV0 aEBpZXRmLm9yZwo+Pj4gU3ViamVjdDogW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2Qg UmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24gRmluYWxpemVkCj4+PiAKPj4+IEhp IGFsbCwKPj4+IAo+Pj4gT24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRp b24gb2YgdGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmlj YXRpb24sIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQwMi5odG1sCj4+PiAKPj4+IFdoYXQgc3VycHJpc2VkIHVzIGlzIHRoYXQgdGhp cyB3b3JrIGlzIGNvbmNlcHR1YWxseSB2ZXJ5IHNpbXBsZTogd2UgZGVmaW5lIG5ldyBjbGFpbXMg YW5kIGNyZWF0ZSBhIHJlZ2lzdHJ5IHdpdGggbmV3IHZhbHVlcy4gTm90IGEgYmlnIGRlYWwgYnV0 IHRoYXQncyBub3Qgd2hhdCB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgWW9rb2hhbWEgSUVURiBtZWV0 aW5nIGFuZCB0aGUgc3Vic2VxdWVudCBjYWxsIGZvciBhZG9wdGlvbiBvbiB0aGUgbGlzdCBzaG93 cy4gVGhlIGZlZWRiYWNrIGxlYWQgdG8gbWl4ZWQgZmVlbGluZ3MgYW5kIGl0IGlzIGEgYml0IGRp ZmZpY3VsdCBmb3IgRGVyZWsgYW5kIG15c2VsZiB0byBqdWRnZSBjb25zZW5zdXMuCj4+PiAKPj4+ IExldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBvbiB0aGUgbGlz dC4KPj4+IAo+Pj4gSW4gaGlzIHJldmlldyBhdAo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRtbCBKYW1lcyBNYW5nZXIgYXNr cyBmb3Igc2lnbmlmaWNhbnQgY2hhbmdlcy4gQW1vbmcgb3RoZXIgdGhpbmdzLCBoZSB3YW50cyB0 byByZW1vdmUgb25lIG9mIHRoZSBjbGFpbXMuIEhlIHByb3ZpZGVzIGEgZGV0YWlsZWQgcmV2aWV3 IGFuZCBhY3Rpb25hYmxlIGl0ZW1zLgo+Pj4gCj4+PiBXaWxsaWFtIERlbm5pc3MgYmVsaWV2ZXMg dGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhZG9wdGlvbiBidXQgYWdyZWVzIHdpdGggc29tZSBv ZiB0aGUgY29tbWVudHMgZnJvbSBKYW1lcy4gSGVyZSBpcyBoaXMgcmV2aWV3Ogo+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjYuaHRt bAo+Pj4gCj4+PiBKdXN0aW4gaXMgY2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJv bmdlc3Qgb3Bpbmlvbi4gSGVyZSBpcyBvbmUgb2YgaGlzIHBvc3RzOgo+Pj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NTcuaHRtbAo+Pj4g Cj4+PiBBbW9uZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5nIG9u ZSBpcyBhY3R1YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQgcmVw b3J0aW5nIGhvdyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgYW5kIGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRpY2F0 aW9uIGlzIGEgZmluZSBsaW5lLiBIZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9jdW1lbnQgbGVhZHMg cmVhZGVycyB0byBiZWxpZXZlIHRoZSBsYXR0ZXIuCj4+PiAKPj4+IEpvaG4gYWdyZWVzIHdpdGgg SnVzdGluIGluCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQ0OC5odG1sIHRoYXQgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9w bGUgYXJlIG5vdCBtaXNsZWFkIGFib3V0IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBK b2huIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbCBjb21tZW50cyBpbiB0aGlzIHBvc3QgdG8gdGhl Cj4+PiBsaXN0OiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQ0MS5odG1sCj4+PiBNb3N0IG9mIHRoZW0gcmVxdWlyZSBtb3JlIHRoYW4ganVz dCBlZGl0aW5nIHdvcmsuIEZvciBleGFtcGxlLCBtZXRob2RzIGxpc3RlZCBhcmUgcmVhbGx5IG5v dCB1c2VmdWwsCj4+PiAKPj4+IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9u IGJ1dCBoYXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2Vz IG5vdCBwcm9wb3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZToKPj4+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDYyLmh0 bWwKPj4+IAo+Pj4gV2l0aCBteSBjby1jaGFpciBoYXQgb246IEkganVzdCB3YW50ZWQgdG8gY2xh cmlmeSB0aGF0IHJlZ2lzdGVyaW5nIGNsYWltcyAoYW5kIHZhbHVlcyB3aXRoaW4gdGhvc2UgY2xh aW1zKSBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLiBXZSBz dGFuZGFyZGl6ZWQgdGhlIEpXVCBpbiB0aGlzIGdyb3VwIGFuZCB3ZSBhcmUgYWxzbyBjaGFydGVy ZWQgdG8gc3RhbmRhcmRpemUgY2xhaW1zLCBhcyB3ZSBhcmUgY3VycmVudGx5IGRvaW5nIHdpdGgg dmFyaW91cyBkcmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBpbiB0aGUgSUVURiB3b3VsZCBo YXZlIGxlYWQgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCBsZXNzIHNlY3VyaXR5LiBJ IGhhdmUgbm8gZG91YnRzIHRoYXQgd2FzIGEgd3JvbmcgZGVjaXNpb24uCj4+PiAKPj4+IEluIGl0 cyBjdXJyZW50IGZvcm0sIHRoZXJlIGlzIG5vdCBlbm91Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMg ZG9jdW1lbnQgYXMgYSBXRyBpdGVtLgo+Pj4gCj4+PiBXZSBiZWxpZXZlIHRoYXQgdGhlIGRvY3Vt ZW50IGF1dGhvcnMgc2hvdWxkIGFkZHJlc3Mgc29tZSBvZiB0aGUgZWFzaWVyIGNvbW1lbnRzIGFu ZCBzdWJtaXQgYSBuZXcgdmVyc2lvbi4gVGhpcyB3b3VsZCBhbGxvdyB1cyB0byByZWFjaCBvdXQg dG8gdGhvc2Ugd2hvIGhhZCBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgdGhlIHNjb3BlIG9mIHRo ZSBkb2N1bWVudCB0byByZS1ldmFsdWF0ZSB0aGVpciBkZWNpc2lvbi4gQSBuZXcgZHJhZnQgdmVy c2lvbiBzaG91bGQgYXQgbGVhc3QgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3VlczoKPj4+IAo+ Pj4gKiBDbGFyaWZ5IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBub3QgYW4gZW5jb3VyYWdlbWVudCBm b3IgdXNpbmcgT0F1dGggYXMgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wuIEkgYmVsaWV2ZSB0 aGF0IHRoaXMgd291bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBjb25jZXJucyByYWlzZWQgYnkgSnVz dGluIGFuZCBKb2huLgo+Pj4gCj4+PiAqIENoYW5nZSB0aGUgcmVnaXN0cnkgcG9saWN5LCB3aGlj aCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0aGUgY29tbWVudHMgZnJvbSBKYW1lcywgV2lsbGlhbSwg YW5kIFBoaWwuCj4+PiAKPj4+IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9u IHNpbmNlIHRoZXkgYXJlIG1vcmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBK b2huIG5vdGVkIHRoYXQgaGUgZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1l dGVycy4gVW5mb3J0dW5hdGVseSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpv aG4gdG8gcHJvdmlkZSBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUgaXMgb25lLiBB bHNvLCB0aGUgcmVtYXJrIHRoYXQgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291bGQgYmUg Y291bnRlcmVkIHdpdGggYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwuIEphbWVzIHdhbnRlZCB0byBy ZW1vdmUgdGhlICJhbXJfdmFsdWVzIiBwYXJhbWV0ZXIuCj4+PiBJcyB0aGlzIHdoYXQgb3RoZXJz IHdhbnQgYXMgd2VsbD8KPj4+IAo+Pj4gQWZ0ZXIgdGhlc2UgaXRlbXMgaGF2ZSBiZWVuIGFkZHJl c3NlZCB3ZSBiZWxpZXZlIHRoYXQgbW9yZSBmb2xrcyBpbiB0aGUgZ3JvdXAgd2lsbCBzdXBwb3J0 IHRoZSBkb2N1bWVudC4KPj4+IAo+Pj4gQ2lhbwo+Pj4gSGFubmVzICYgRGVyZWsKPj4+IAo+Pj4g Cj4+PiAKPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+IE9BdXRoQGlldGYub3JnCj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+IAo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4g T0F1dGhAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aAo+Cj7igJQgUm9sYW5kCj4KPuKAnUV2ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBh IGxpdHRsZSBzdHJlYW0gYW5kIGxpc3Rlbi4iCj5Gcm9tIOKAmU9wZW4gSG91c2UgZm9yIEJ1dHRl cmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzCj4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPk9BdXRoIG1haWxpbmcgbGlzdAo+T0F1dGhAaWV0Zi5vcmcK Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPg== ----_com.syntomo.email_671835454102421 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkkgYmFzaWNhbGx5IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu dC4gQXNzZXJ0aW5nIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgaW4gYWNjZXNzIHRva2VucyAoaW4g dGhpcyBjYXNlIGluIEpXVFMgZm9ybWF0KSBpcyByZWFzb25hYmxlLiBXZSB1c2UgaXQgdG8gcGFz cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIHByaW9yIGlz c3VpbmcgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfIHNlcnZlci4gPC9wPgo8cCBk aXI9Imx0ciI+V2hhdCB3b3JyaWVzIG1lIGlzIHRoZSBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVuIG9h dXRoIGFuZCBvaWRjLiBUaGUgYW1yIGNsYWltIGlzIGRlZmluZWQgaW4gb2lkYyAod2hpY2ggc2l0 cyBvbiB0b3Agb2Ygb2F1dGgpIGJ1dCB0aGUgb2F1dGggd2cgc3BlY2lmaWVzIHRoZSByZWdpc3Ry eT8gTW9yZW92ZXIsIHRoZSBjdXJyZW50IHRleHQgZG9lcyBub3QgZ2l2ZSBhIHJhdGlvbmFsZSBm b3IgdXNpbmcgYW1yIGluIGNvbnRleHQgb2Ygb2F1dGguPC9wPgo8cCBkaXI9Imx0ciI+QXMgYSBX RyB3ZSBuZWVkIHRvIGZpbmQgYSBjbGVhciBkZWxpbmVhdGlvbiBiZXR3ZWVuIGJvdGggcHJvdG9j b2xzLCBvdGhlcndpc2Ugbm9vbmUgd2lsbCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5j ZSBhbmQgd2hlbiB0byB1c2Ugd2hhdC4gV2UgY3JlYXRlIGNvbmZ1c2lvbiEgPC9wPgo8cCBkaXI9 Imx0ciI+Rm9yIHRoaXMgcGFydGljdWxhciBkcmFmdCB0aGlzIG1lYW5zIHRvIGVpdGhlciBtb3Zl IGFtciB0byBvYXV0aCBvciB0aGUgcmVnaXN0cnkgdG8gb2lkYy4gPC9wPgo8cCBkaXI9Imx0ciI+ YmVzdCByZWdhcmRzLCA8YnI+ClRvcnN0ZW4uPC9wPgo8YnI+PGJyPi0tLS0tLS0tIFVyc3Byw7xu Z2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLTxicj5Wb246IFJvbGFuZCBIZWRiZXJnICZsdDtyb2xh bmQuaGVkYmVyZ0B1bXUuc2UmZ3Q7PGJyPkdlc2VuZGV0OiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAy MDE2IDA1OjQ1IFBNPGJyPkFuOiBvYXV0aEBpZXRmLm9yZzxicj5CZXRyZWZmOiBSZTogW09BVVRI LVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRv cHRpb24gRmluYWxpemVkPGJyPjxicj48cD4rMTxicj48YnI+Jmd0OyAxMiBmZWIgMjAxNiBrbC4g MTY6NTggc2tyZXYgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs6PGJyPiZn dDsgPGJyPiZndDsgKzEgdG8gYWRvcHQgdGhpcyBkcmFmdC48YnI+Jmd0OyA8YnI+Jmd0OyZndDsg T24gRmViIDEyLCAyMDE2LCBhdCAzOjA3IEFNLCBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20mZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgRHJhZnQg LTA1IGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sgZGVzY3JpYmVkIGJlbG93IC0gZGVsZXRpbmcg dGhlIHJlcXVlc3QgcGFyYW1ldGVyLCBub3RpbmcgdGhhdCB0aGlzIHNwZWMgaXNuJ3QgYW4gZW5j b3VyYWdlbWVudCB0byB1c2UgT0F1dGggMi4wIGZvciBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGVt cGxveWluZyBhcHByb3ByaWF0ZSBleHRlbnNpb25zLCBhbmQgbm8gbG9uZ2VyIHJlcXVpcmluZyBh IHNwZWNpZmljYXRpb24gZm9yIElBTkEgcmVnaXN0cmF0aW9uLiZuYnNwOyBJIGJlbGlldmUgdGhh dCBpdOKAmXMgbm93IHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLjxicj4mZ3Q7Jmd0 OyA8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsgRnJvbTogT0F1dGggW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWc8YnI+ Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgMTE6MjMgQU08YnI+Jmd0 OyZndDsgVG86IG9hdXRoQGlldGYub3JnPGJyPiZndDsmZ3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10g QXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9u IEZpbmFsaXplZDxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgSGkgYWxsLDxicj4mZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsgT24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24g b2YgdGhlIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRp b24sIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cxNTQwMi5odG1sPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBXaGF0IHN1cnByaXNlZCB1 cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmlu ZSBuZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBh IGJpZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29o YW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24g dGhlIGxpc3Qgc2hvd3MuIFRoZSBmZWVkYmFjayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBp dCBpcyBhIGJpdCBkaWZmaWN1bHQgZm9yIERlcmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vu c3VzLjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgTGV0IG1lIHRlbGwgeW91IHdoYXQgd2Ugc2Vl IGZyb20gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0Ljxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsg SW4gaGlzIHJldmlldyBhdDxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyMy5odG1sIEphbWVzIE1hbmdlciBhc2tzIGZv ciBzaWduaWZpY2FudCBjaGFuZ2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhlIHdhbnRzIHRvIHJl bW92ZSBvbmUgb2YgdGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxlZCByZXZpZXcgYW5k IGFjdGlvbmFibGUgaXRlbXMuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBXaWxsaWFtIERlbm5p c3MgYmVsaWV2ZXMgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhZG9wdGlvbiBidXQgYWdyZWVz IHdpdGggc29tZSBvZiB0aGUgY29tbWVudHMgZnJvbSBKYW1lcy4gSGVyZSBpcyBoaXMgcmV2aWV3 Ojxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQyNi5odG1sPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBKdXN0aW4gaXMg Y2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJvbmdlc3Qgb3Bpbmlvbi4gSGVyZSBp cyBvbmUgb2YgaGlzIHBvc3RzOjxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ1Ny5odG1sPGJyPiZndDsmZ3Q7IDxicj4m Z3Q7Jmd0OyBBbW9uZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5n IG9uZSBpcyBhY3R1YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQg cmVwb3J0aW5nIGhvdyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQgYW5kIGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRp Y2F0aW9uIGlzIGEgZmluZSBsaW5lLiBIZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9jdW1lbnQgbGVh ZHMgcmVhZGVycyB0byBiZWxpZXZlIHRoZSBsYXR0ZXIuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0 OyBKb2huIGFncmVlcyB3aXRoIEp1c3RpbiBpbjxicj4mZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1sIHRoYXQgd2Ug bmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9wbGUgYXJlIG5vdCBtaXNsZWFkIGFib3V0IHRoZSBp bnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBKb2huIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbCBj b21tZW50cyBpbiB0aGlzIHBvc3QgdG8gdGhlPGJyPiZndDsmZ3Q7IGxpc3Q6IGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWw8YnI+ Jmd0OyZndDsgTW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGluZyB3b3Jr LiBGb3IgZXhhbXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVsLDxicj4m Z3Q7Jmd0OyA8YnI+Jmd0OyZndDsgUGhpbCBhZ3JlZXMgd2l0aCB0aGUgZG9jdW1lbnQgYWRvcHRp b24gYnV0IGhhcyBzb21lIHJlbWFya3MgYWJvdXQgdGhlIHJlZ2lzdHJ5IGFsdGhvdWdoIGhlIGRv ZXMgbm90IHByb3Bvc2Ugc3BlY2lmaWMgdGV4dC4gSGlzIHJldmlldyBpcyBoZXJlOjxicj4mZ3Q7 Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9t c2cxNTQ2Mi5odG1sPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBXaXRoIG15IGNvLWNoYWlyIGhh dCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmcgY2xhaW1zIChh bmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhl IE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXplZCB0aGUgSldUIGluIHRoaXMgZ3Jv dXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdl IGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzIGRyYWZ0cy4gTm90IHN0YW5kYXJkaXpp bmcgSldUIGluIHRoZSBJRVRGIHdvdWxkIGhhdmUgbGVhZCB0byByZWR1Y2VkIGludGVyb3BlcmFi aWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHkuIEkgaGF2ZSBubyBkb3VidHMgdGhhdCB3YXMgYSB3cm9u ZyBkZWNpc2lvbi48YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEluIGl0cyBjdXJyZW50IGZvcm0s IHRoZXJlIGlzIG5vdCBlbm91Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMgZG9jdW1lbnQgYXMgYSBX RyBpdGVtLjxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgV2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1 bWVudCBhdXRob3JzIHNob3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGVhc2llciBjb21tZW50cyBh bmQgc3VibWl0IGEgbmV3IHZlcnNpb24uIFRoaXMgd291bGQgYWxsb3cgdXMgdG8gcmVhY2ggb3V0 IHRvIHRob3NlIHdobyBoYWQgZXhwcmVzc2VkIGNvbmNlcm5zIGFib3V0IHRoZSBzY29wZSBvZiB0 aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVhdGUgdGhlaXIgZGVjaXNpb24uIEEgbmV3IGRyYWZ0IHZl cnNpb24gc2hvdWxkIGF0IGxlYXN0IGFkZHJlc3MgdGhlIGZvbGxvd2luZyBpc3N1ZXM6PGJyPiZn dDsmZ3Q7IDxicj4mZ3Q7Jmd0OyAqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBh biBlbmNvdXJhZ2VtZW50IGZvciB1c2luZyBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90 b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNl cm5zIHJhaXNlZCBieSBKdXN0aW4gYW5kIEpvaG4uPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyAq IENoYW5nZSB0aGUgcmVnaXN0cnkgcG9saWN5LCB3aGljaCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0 aGUgY29tbWVudHMgZnJvbSBKYW1lcywgV2lsbGlhbSwgYW5kIFBoaWwuPGJyPiZndDsmZ3Q7IDxi cj4mZ3Q7Jmd0OyBWYXJpb3VzIG90aGVyIGl0ZW1zIHJlcXVpcmUgZGlzY3Vzc2lvbiBzaW5jZSB0 aGV5IGFyZSBtb3JlIGRpZmZpY3VsdCB0byBhZGRyZXNzLiBGb3IgZXhhbXBsZSwgSm9obiBub3Rl ZCB0aGF0IGhlIGRvZXMgbm90IGxpa2UgdGhlIHVzZSBvZiByZXF1ZXN0IHBhcmFtZXRlcnMuIFVu Zm9ydHVuYXRlbHksIG5vIGFsdGVybmF0aXZlIGlzIG9mZmVyZWQuIEkgdXJnZSBKb2huIHRvIHBy b3ZpZGUgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwsIGlmIHRoZXJlIGlzIG9uZS4gQWxzbywgdGhl IHJlbWFyayB0aGF0IHRoZSB2YWx1ZXMgYXJlIG1lYW5pbmdsZXNzIGNvdWxkIGJlIGNvdW50ZXJl ZCB3aXRoIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLiBKYW1lcyB3YW50ZWQgdG8gcmVtb3ZlIHRo ZSAiYW1yX3ZhbHVlcyIgcGFyYW1ldGVyLjxicj4mZ3Q7Jmd0OyBJcyB0aGlzIHdoYXQgb3RoZXJz IHdhbnQgYXMgd2VsbD88YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IEFmdGVyIHRoZXNlIGl0ZW1z IGhhdmUgYmVlbiBhZGRyZXNzZWQgd2UgYmVsaWV2ZSB0aGF0IG1vcmUgZm9sa3MgaW4gdGhlIGdy b3VwIHdpbGwgc3VwcG9ydCB0aGUgZG9jdW1lbnQuPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBD aWFvPGJyPiZndDsmZ3Q7IEhhbm5lcyAmYW1wOyBEZXJlazxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZn dDsgPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0 OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy PiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPGJyPjxicj7igJQgUm9sYW5kPGJyPjxicj7igJ1FdmVyeWJvZHkgc2hv dWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIjxicj5Gcm9tIOKA mU9wZW4gSG91c2UgZm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzPGJyPjxicj48YnI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGgg bWFpbGluZyBsaXN0PGJyPk9BdXRoQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+PC9wPg== ----_com.syntomo.email_671835454102421-- From nobody Sat Feb 13 06:15:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E731B32DC for ; Sat, 13 Feb 2016 06:15:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beSgZnD0fKfO for ; Sat, 13 Feb 2016 06:15:10 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 F0EBB1B32D9 for ; Sat, 13 Feb 2016 06:15:09 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id y89so82574685qge.2 for ; Sat, 13 Feb 2016 06:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FDQtpYOGio94N8qPHbPk4zUHlcDdhxfQ3kTKMQa0ec8=; b=Z/lNpWHpUTOd++o3ayxQlCV4DQfbY058TgPcXoieNZPZME/JvJmib+Mor57fKnCqEo KI6DXwisxr1htoQrn40XpmCReH01hgFL9+DVkA0pkADJq3Hpc05cU2If+Xr8zj2VoTRF Su4/pUynIjPo/xNOvAqXn6c7iVt7PLgFUaLsVtGRVfi+k09g3u/Gkvi17y01OTY8ALJi 4hrO4cDlkLyvG7hSTzXTbriYG7nAWpiFWPjIpAL+acSL7N7mWnPm+zxThTaNvywB4NOp FMag0X7m4RWw/egU20E5cW3bTZYsR87XcDDThOzayvdxTe4NHCoH2sf7TBrREPr4i7PE Xrtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FDQtpYOGio94N8qPHbPk4zUHlcDdhxfQ3kTKMQa0ec8=; b=kJ6o59jrl3YJ55YGe895jiQ9Gbq/i8BWmxW++Yl6R7JZhyeUfYvFHaqnKfnTsgSacl e0Ra/faFmIgr0Q0OeLUsTl+c8Xd2inNZBQtXoY/AUMMycmlcw/pGq3dp0pvYZ9bznIVv bZ8PKr8ryCGhOeY4l95oDtf9TgY2ETAKVmFIua7oN6gqe5dK6DalXLwS8jrLaDiixlWN kRgmD5dn8rWnzsvlSkViojruCPivsG6d4e4dQN6aWQNkRbSfqcr/1PNfodLRt9S0Q0s8 hM+vTMRmCu1bQRCDvVbDpVCoVgbYUJyrybnV+wzaP/mkJ55tM/emwK9IFyNOztyeavf6 VWYw== X-Gm-Message-State: AG10YOQKU/KHuBuVjFeRhBfV3SGUQJaIFX2qT/1+KnSoSgssYdvliWWG/UU5OTLy5cRcwQ== X-Received: by 10.140.81.80 with SMTP id e74mr8782807qgd.27.1455372909000; Sat, 13 Feb 2016 06:15:09 -0800 (PST) Received: from [192.168.1.68] ([191.115.40.128]) by smtp.gmail.com with ESMTPSA id d37sm1379979qkh.46.2016.02.13.06.15.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Feb 2016 06:15:08 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_FAB45B57-13C5-4F69-8E88-D3F02E029B2D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <1ly54p9jm7ym5qagjg42ftlw.1455365912992@com.syntomo.email> Date: Sat, 13 Feb 2016 11:14:53 -0300 Message-Id: References: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> <1ly54p9jm7ym5qagjg42ftlw.1455365912992@com.syntomo.email> To: "torsten@lodderstedt.net" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 14:15:13 -0000 --Apple-Mail=_FAB45B57-13C5-4F69-8E88-D3F02E029B2D Content-Type: multipart/alternative; boundary="Apple-Mail=_3918FA16-24CF-42C6-9D5F-E9BB5AECC298" --Apple-Mail=_3918FA16-24CF-42C6-9D5F-E9BB5AECC298 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is not a issue between oauth and OIDC. This has to do with the registry for JWT being in OAuth. Many = protocols that use JWT are going to want to register claims. =20 We can=E2=80=99t ask them to all move the parts of there specs that use = JWT to OAuth. Perhaps JWT should have been part of JOSE, but that is water under the = bridge. =20 The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we = will need to deal with registering claims. =20 I guess that we can tell people that they need to publish the specs = defining the claims someplace else, and just do the registry part. However doing that will probably not improve interoperability and = understanding. This document defines the claim for JWT in general. We still have = almost no documentation in the WG about what a JWT access token would = contain other than the POP work. John B. > On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: >=20 > I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server. >=20 > What worries me is the back and forth between oauth and oidc. The amr = claim is defined in oidc (which sits on top of oauth) but the oauth wg = specifies the registry? Moreover, the current text does not give a = rationale for using amr in context of oauth. >=20 > As a WG we need to find a clear delineation between both protocols, = otherwise noone will really understand the difference and when to use = what. We create confusion! >=20 > For this particular draft this means to either move amr to oauth or = the registry to oidc. >=20 > best regards,=20 > Torsten. >=20 >=20 >=20 > -------- Urspr=C3=BCngliche Nachricht -------- > Von: Roland Hedberg > Gesendet: Friday, February 12, 2016 05:45 PM > An: oauth@ietf.org > Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >=20 > +1 >=20 > > 12 feb 2016 kl. 16:58 skrev John Bradley : > >=20 > > +1 to adopt this draft. > >=20 > >> On Feb 12, 2016, at 3:07 AM, Mike Jones = wrote: > >>=20 > >> Draft -05 incorporates the feedback described below - deleting the = request parameter, noting that this spec isn't an encouragement to use = OAuth 2.0 for authentication without employing appropriate extensions, = and no longer requiring a specification for IANA registration. I = believe that it=E2=80=99s now ready for working group adoption. > >>=20 > >> -- Mike > >>=20 > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > >> Sent: Thursday, February 4, 2016 11:23 AM > >> To: oauth@ietf.org > >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized > >>=20 > >> Hi all, > >>=20 > >> On January 19th I posted a call for adoption of the Authentication = Method Reference Values specification, see = http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html > >>=20 > >> What surprised us is that this work is conceptually very simple: we = define new claims and create a registry with new values. Not a big deal = but that's not what the feedback from the Yokohama IETF meeting and the = subsequent call for adoption on the list shows. The feedback lead to = mixed feelings and it is a bit difficult for Derek and myself to judge = consensus. > >>=20 > >> Let me tell you what we see from the comments on the list. > >>=20 > >> In his review at > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James Manger asks for significant changes. Among other things, he wants = to remove one of the claims. He provides a detailed review and = actionable items. > >>=20 > >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html > >>=20 > >> Justin is certainly the reviewer with the strongest opinion. Here = is one of his posts: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html > >>=20 > >> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. > >>=20 > >> John agrees with Justin in > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html = that we need to make sure that people are not mislead about the = intention of the document. John also provides additional comments in = this post to the > >> list: = http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html > >> Most of them require more than just editing work. For example, = methods listed are really not useful, > >>=20 > >> Phil agrees with the document adoption but has some remarks about = the registry although he does not propose specific text. His review is = here: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html > >>=20 > >> With my co-chair hat on: I just wanted to clarify that registering = claims (and values within those claims) is within the scope of the OAuth = working group. We standardized the JWT in this group and we are also = chartered to standardize claims, as we are currently doing with various = drafts. Not standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision. > >>=20 > >> In its current form, there is not enough support to have this = document as a WG item. > >>=20 > >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: > >>=20 > >> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John. > >>=20 > >> * Change the registry policy, which would address one of the = comments from James, William, and Phil. > >>=20 > >> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. > >> Is this what others want as well? > >>=20 > >> After these items have been addressed we believe that more folks in = the group will support the document. > >>=20 > >> Ciao > >> Hannes & Derek > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > =E2=80=94 Roland >=20 > =E2=80=9DEverybody should be quiet near a little stream and listen." > =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3918FA16-24CF-42C6-9D5F-E9BB5AECC298 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is not a issue between oauth and OIDC.

This has to do with the registry for = JWT being in OAuth.   Many protocols that use JWT are going to want = to register claims.  
We can=E2=80=99t ask = them to all move the parts of there specs that use JWT to = OAuth.

Perhaps = JWT should have been part of JOSE, but that is water under the bridge. =  

The = OAuth WG is responsible for JWT and it=E2=80=99s registry, and we will = need to deal with registering claims.  

I guess that we can tell people that = they need to publish the specs defining the claims someplace else, and = just do the registry part.
However doing that will = probably not improve interoperability and understanding.

This document defines = the claim for JWT in general.  We still have almost no = documentation in the WG about what a JWT access token would contain = other than the POP work.

John B.
On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between = oauth and oidc. The amr claim is defined in oidc (which sits on top of = oauth) but the oauth wg specifies the registry? Moreover, the current = text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation = between both protocols, otherwise noone will really understand the = difference and when to use what. We create confusion!

For this particular draft this means to either move amr to = oauth or the registry to oidc.

best = regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht = --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, = February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference = Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 = skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the = feedback described below - deleting the request parameter, noting that = this spec isn't an encouragement to use OAuth 2.0 for authentication = without employing appropriate extensions, and no longer requiring a = specification for IANA registration.  I believe that it=E2=80=99s = now ready for working group adoption.
>>
>>         &= nbsp;           &nb= sp;            = ;            &= nbsp;            = -- Mike
>>
>> -----Original = Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 = AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] = Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>=
>> On January 19th I posted a call for adoption of = the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.htm= l
>>
>> What surprised us = is that this work is conceptually very simple: we define new claims and = create a registry with new values. Not a big deal but that's not what = the feedback from the Yokohama IETF meeting and the subsequent call for = adoption on the list shows. The feedback lead to mixed feelings and it = is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see = from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.htm= l James Manger asks for significant changes. Among other things, he = wants to remove one of the claims. He provides a detailed review and = actionable items.
>>
>> William = Denniss believes the document is ready for adoption but agrees with some = of the comments from James. Here is his review:
>> = http://www.ietf.org/mail-archive/web/oauth/current/msg15426.htm= l
>>
>> Justin is certainly = the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.htm= l
>>
>> Among all concerns = Justin expressed the following one is actually actionable IMHO: Justin = is worried that reporting how a person authenticated to an authorization = endpoint and encouraging people to use OAuth for authentication is a = fine line. He believes that this document leads readers to believe the = latter.
>>
>> John agrees with = Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.htm= l that we need to make sure that people are not mislead about the = intention of the document. John also provides additional comments in = this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.htm= l
>> Most of them require more than just editing = work. For example, methods listed are really not useful,
>>
>> Phil agrees with the = document adoption but has some remarks about the registry although he = does not propose specific text. His review is here:
>>= http://www.ietf.org/mail-archive/web/oauth/current/msg15462.htm= l
>>
>> With my co-chair = hat on: I just wanted to clarify that registering claims (and values = within those claims) is within the scope of the OAuth working group. We = standardized the JWT in this group and we are also chartered to = standardize claims, as we are currently doing with various drafts. Not = standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision.
>>
>> In its current = form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document = authors should address some of the easier comments and submit a new = version. This would allow us to reach out to those who had expressed = concerns about the scope of the document to re-evaluate their decision. = A new draft version should at least address the following issues:
>>
>> * Clarify that this document = is not an encouragement for using OAuth as an authentication protocol. I = believe that this would address some of the concerns raised by Justin = and John.
>>
>> * Change the = registry policy, which would address one of the comments from James, = William, and Phil.
>>
>> = Various other items require discussion since they are more difficult to = address. For example, John noted that he does not like the use of = request parameters. Unfortunately, no alternative is offered. I urge = John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" = parameter.
>> Is this what others want as well?
>>
>> After these items have been = addressed we believe that more folks in the group will support the = document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> = _______________________________________________
>> = OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> = _______________________________________________
> OAuth = mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and = listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99= by Ruth Krauss


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

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

= --Apple-Mail=_3918FA16-24CF-42C6-9D5F-E9BB5AECC298-- --Apple-Mail=_FAB45B57-13C5-4F69-8E88-D3F02E029B2D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTMxNDE0NTNaMCMGCSqGSIb3DQEJBDEWBBQLQRxQUmkTNbvN9dklUjCk pu3gEzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCcZ5AU4/Ko7M4rKoYIduhZSZb35BUa+AQDvPzavuvWWpiKToF16SUC mBcgXlh1pYIhEPDXoUXfvIJq2y445pkGW3u12ENqKvIz+2/EmBDkyJeCBSrWEjGBc82yflr5/QDy 07uFlWIphqCN3f2HfgXwrug5Up+TWmRIpdFv+n2OcRppvpXIAnu+olFHiEG+UvAWtPkweKsqCKEX 4l4XdjFRP145QTLEL7CybKARMSC3EbVZXK/uQYhbgOjX+w3wi8Q8n3xZ9M9yzMiV6kUjns63jqcY BRTwX1lYZvhBw0l3RlqsYcYSutOXACtEXvgA9+QVprG2ocKKRKHXg/uYXIU3AAAAAAAA --Apple-Mail=_FAB45B57-13C5-4F69-8E88-D3F02E029B2D-- From nobody Sat Feb 13 06:37:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D71A0151 for ; Sat, 13 Feb 2016 06:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsIbDNsSK-sQ for ; Sat, 13 Feb 2016 06:36:46 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8E91B3313 for ; Sat, 13 Feb 2016 06:36:44 -0800 (PST) Received: from [79.218.87.147] (helo=[192.168.71.137]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aUbHr-0000Fb-AS; Sat, 13 Feb 2016 15:35:03 +0100 Date: Sat, 13 Feb 2016 15:36:39 +0100 Message-ID: In-Reply-To: References: From: "torsten@lodderstedt.net" To: John Bradley MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_754675955045670" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 14:36:50 -0000 ----_com.syntomo.email_754675955045670 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2UgY2xlYXJseSBoYXZlIHRoaXMgcHJvYmxlbSBiZXR3ZWVuIG9hdXRoIGFuZCBvaWRjLiBKdXN0 IHRha2UgYSBsb29rIGF0IHRoZSBkaXNjb3ZlcnkgdGhyZWFkLgoKQWNjb3JkaW5nIHRvIHlvdSBh cmd1bWVudCBJIHNlZSB0d28gb3B0aW9uczoKKDEpIGFtciBzdGF5cyBhbiBvaWRjIGNsYWltLCBp cyB1c2VkIGluIG9pZGMgb25seSBhbmQgdGhlIG9hdXRoIHdnIGp1c3QgcHVibGlzaGVzIHRoZSBy ZWdpc3RyeSBlbnRyaWVzLiBJbiB0aGlzIGNhc2UsIHRoZSBzcGVjIHNob3VsZCBjbGVhcmx5IGV4 cGxhaW4gdGhpcy4KKDIpIGFtciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoIChhbHRob3VnaCBpdCBo YXMgYmVlbiBpbnZlbnRlZCBpbiBvaWRjKSAtIHRoYW4gZGVmaW5lIGl0IGFuZCBtb3RpdmF0ZSBp dCdzIHVzZSBpbiBvYXV0aCBpbiB0aGlzIHNwZWMuIAoKUmlnaHQgbm93LCBJIHRoaW5rIGl0IGNy ZWF0ZXMgdGhlIGltcHJlc3Npb24gb2F1dGggaXMgZm9yIGF1dGhlbnRpY2F0aW9uLiAKCi0tLS0t LS0tIE9yaWdpbmFsbmFjaHJpY2h0IC0tLS0tLS0tCkJldHJlZmY6IFJlOiBbT0FVVEgtV0ddIEF1 dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBG aW5hbGl6ZWQKVm9uOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPgpBbjogdG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQKQ2M6IHJvbGFuZC5oZWRiZXJnQHVtdS5zZSxvYXV0aEBpZXRmLm9y ZwoKPlRoaXMgaXMgbm90IGEgaXNzdWUgYmV0d2VlbiBvYXV0aCBhbmQgT0lEQy4KPgo+VGhpcyBo YXMgdG8gZG8gd2l0aCB0aGUgcmVnaXN0cnkgZm9yIEpXVCBiZWluZyBpbiBPQXV0aC4gICBNYW55 IHByb3RvY29scyB0aGF0IHVzZSBKV1QgYXJlIGdvaW5nIHRvIHdhbnQgdG8gcmVnaXN0ZXIgY2xh aW1zLiAgCj5XZSBjYW7igJl0IGFzayB0aGVtIHRvIGFsbCBtb3ZlIHRoZSBwYXJ0cyBvZiB0aGVy ZSBzcGVjcyB0aGF0IHVzZSBKV1QgdG8gT0F1dGguCj4KPlBlcmhhcHMgSldUIHNob3VsZCBoYXZl IGJlZW4gcGFydCBvZiBKT1NFLCBidXQgdGhhdCBpcyB3YXRlciB1bmRlciB0aGUgYnJpZGdlLiAg Cj4KPlRoZSBPQXV0aCBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMgcmVnaXN0 cnksIGFuZCB3ZSB3aWxsIG5lZWQgdG8gZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWltcy4gIAo+ Cj5JIGd1ZXNzIHRoYXQgd2UgY2FuIHRlbGwgcGVvcGxlIHRoYXQgdGhleSBuZWVkIHRvIHB1Ymxp c2ggdGhlIHNwZWNzIGRlZmluaW5nIHRoZSBjbGFpbXMgc29tZXBsYWNlIGVsc2UsIGFuZCBqdXN0 IGRvIHRoZSByZWdpc3RyeSBwYXJ0Lgo+SG93ZXZlciBkb2luZyB0aGF0IHdpbGwgcHJvYmFibHkg bm90IGltcHJvdmUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdW5kZXJzdGFuZGluZy4KPgo+VGhpcyBk b2N1bWVudCBkZWZpbmVzIHRoZSBjbGFpbSBmb3IgSldUIGluIGdlbmVyYWwuICBXZSBzdGlsbCBo YXZlIGFsbW9zdCBubyBkb2N1bWVudGF0aW9uIGluIHRoZSBXRyBhYm91dCB3aGF0IGEgSldUIGFj Y2VzcyB0b2tlbiB3b3VsZCBjb250YWluIG90aGVyIHRoYW4gdGhlIFBPUCB3b3JrLgo+Cj5Kb2hu IEIuCj4+IE9uIEZlYiAxMywgMjAxNiwgYXQgOToxOCBBTSwgdG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQgd3JvdGU6Cj4+IAo+PiBJIGJhc2ljYWxseSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9j dW1lbnQuIEFzc2VydGluZyBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGluIGFjY2VzcyB0b2tlbnMg KGluIHRoaXMgY2FzZSBpbiBKV1RTIGZvcm1hdCkgaXMgcmVhc29uYWJsZS4gV2UgdXNlIGl0IHRv IHBhc3MgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0aW9uIHBlcmZvcm1lZCBwcmlv ciBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgX3Jlc291cmNlXyBzZXJ2ZXIuCj4+IAo+ PiBXaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sgYW5kIGZvcnRoIGJldHdlZW4gb2F1dGggYW5k IG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5lZCBpbiBvaWRjICh3aGljaCBzaXRzIG9uIHRv cCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBzcGVjaWZpZXMgdGhlIHJlZ2lzdHJ5PyBNb3Jl b3ZlciwgdGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBnaXZlIGEgcmF0aW9uYWxlIGZvciB1c2lu ZyBhbXIgaW4gY29udGV4dCBvZiBvYXV0aC4KPj4gCj4+IEFzIGEgV0cgd2UgbmVlZCB0byBmaW5k IGEgY2xlYXIgZGVsaW5lYXRpb24gYmV0d2VlbiBib3RoIHByb3RvY29scywgb3RoZXJ3aXNlIG5v b25lIHdpbGwgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYW5kIHdoZW4gdG8gdXNl IHdoYXQuIFdlIGNyZWF0ZSBjb25mdXNpb24hCj4+IAo+PiBGb3IgdGhpcyBwYXJ0aWN1bGFyIGRy YWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1yIHRvIG9hdXRoIG9yIHRoZSByZWdpc3Ry eSB0byBvaWRjLgo+PiAKPj4gYmVzdCByZWdhcmRzLCAKPj4gVG9yc3Rlbi4KPj4gCj4+IAo+PiAK Pj4gLS0tLS0tLS0gVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0IC0tLS0tLS0tCj4+IFZvbjogUm9s YW5kIEhlZGJlcmcgPHJvbGFuZC5oZWRiZXJnQHVtdS5zZT4KPj4gR2VzZW5kZXQ6IEZyaWRheSwg RmVicnVhcnkgMTIsIDIwMTYgMDU6NDUgUE0KPj4gQW46IG9hdXRoQGlldGYub3JnCj4+IEJldHJl ZmY6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVz OiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKPj4gCj4+ICsxCj4+IAo+PiA+IDEyIGZlYiAy MDE2IGtsLiAxNjo1OCBza3JldiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPjoKPj4g PiAKPj4gPiArMSB0byBhZG9wdCB0aGlzIGRyYWZ0Lgo+PiA+IAo+PiA+PiBPbiBGZWIgMTIsIDIw MTYsIGF0IDM6MDcgQU0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4g d3JvdGU6Cj4+ID4+IAo+PiA+PiBEcmFmdCAtMDUgaW5jb3Jwb3JhdGVzIHRoZSBmZWVkYmFjayBk ZXNjcmliZWQgYmVsb3cgLSBkZWxldGluZyB0aGUgcmVxdWVzdCBwYXJhbWV0ZXIsIG5vdGluZyB0 aGF0IHRoaXMgc3BlYyBpc24ndCBhbiBlbmNvdXJhZ2VtZW50IHRvIHVzZSBPQXV0aCAyLjAgZm9y IGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgZW1wbG95aW5nIGFwcHJvcHJpYXRlIGV4dGVuc2lvbnMs IGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgSUFOQSByZWdpc3Ry YXRpb24uICBJIGJlbGlldmUgdGhhdCBpdOKAmXMgbm93IHJlYWR5IGZvciB3b3JraW5nIGdyb3Vw IGFkb3B0aW9uLgo+PiA+PiAKPj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UKPj4gPj4gCj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tCj4+ID4+IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnCj4+ID4+IFNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSA0LCAyMDE2IDExOjIzIEFNCj4+ID4+IFRvOiBvYXV0aEBpZXRmLm9yZwo+ PiA+PiBTdWJqZWN0OiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2Ug VmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKPj4gPj4gCj4+ID4+IEhpIGFsbCwK Pj4gPj4gCj4+ID4+IE9uIEphbnVhcnkgMTl0aCBJIHBvc3RlZCBhIGNhbGwgZm9yIGFkb3B0aW9u IG9mIHRoZSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBzcGVjaWZpY2F0 aW9uLCBzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJl bnQvbXNnMTU0MDIuaHRtbAo+PiA+PiAKPj4gPj4gV2hhdCBzdXJwcmlzZWQgdXMgaXMgdGhhdCB0 aGlzIHdvcmsgaXMgY29uY2VwdHVhbGx5IHZlcnkgc2ltcGxlOiB3ZSBkZWZpbmUgbmV3IGNsYWlt cyBhbmQgY3JlYXRlIGEgcmVnaXN0cnkgd2l0aCBuZXcgdmFsdWVzLiBOb3QgYSBiaWcgZGVhbCBi dXQgdGhhdCdzIG5vdCB3aGF0IHRoZSBmZWVkYmFjayBmcm9tIHRoZSBZb2tvaGFtYSBJRVRGIG1l ZXRpbmcgYW5kIHRoZSBzdWJzZXF1ZW50IGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZSBsaXN0IHNo b3dzLiBUaGUgZmVlZGJhY2sgbGVhZCB0byBtaXhlZCBmZWVsaW5ncyBhbmQgaXQgaXMgYSBiaXQg ZGlmZmljdWx0IGZvciBEZXJlayBhbmQgbXlzZWxmIHRvIGp1ZGdlIGNvbnNlbnN1cy4KPj4gPj4g Cj4+ID4+IExldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBvbiB0 aGUgbGlzdC4KPj4gPj4gCj4+ID4+IEluIGhpcyByZXZpZXcgYXQKPj4gPj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRtbCBKYW1l cyBNYW5nZXIgYXNrcyBmb3Igc2lnbmlmaWNhbnQgY2hhbmdlcy4gQW1vbmcgb3RoZXIgdGhpbmdz LCBoZSB3YW50cyB0byByZW1vdmUgb25lIG9mIHRoZSBjbGFpbXMuIEhlIHByb3ZpZGVzIGEgZGV0 YWlsZWQgcmV2aWV3IGFuZCBhY3Rpb25hYmxlIGl0ZW1zLgo+PiA+PiAKPj4gPj4gV2lsbGlhbSBE ZW5uaXNzIGJlbGlldmVzIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0IGFn cmVlcyB3aXRoIHNvbWUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlzIHJl dmlldzoKPj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTU0MjYuaHRtbAo+PiA+PiAKPj4gPj4gSnVzdGluIGlzIGNlcnRhaW5seSB0aGUg cmV2aWV3ZXIgd2l0aCB0aGUgc3Ryb25nZXN0IG9waW5pb24uIEhlcmUgaXMgb25lIG9mIGhpcyBw b3N0czoKPj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTU0NTcuaHRtbAo+PiA+PiAKPj4gPj4gQW1vbmcgYWxsIGNvbmNlcm5zIEp1c3Rp biBleHByZXNzZWQgdGhlIGZvbGxvd2luZyBvbmUgaXMgYWN0dWFsbHkgYWN0aW9uYWJsZSBJTUhP OiBKdXN0aW4gaXMgd29ycmllZCB0aGF0IHJlcG9ydGluZyBob3cgYSBwZXJzb24gYXV0aGVudGlj YXRlZCB0byBhbiBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFuZCBlbmNvdXJhZ2luZyBwZW9wbGUg dG8gdXNlIE9BdXRoIGZvciBhdXRoZW50aWNhdGlvbiBpcyBhIGZpbmUgbGluZS4gSGUgYmVsaWV2 ZXMgdGhhdCB0aGlzIGRvY3VtZW50IGxlYWRzIHJlYWRlcnMgdG8gYmVsaWV2ZSB0aGUgbGF0dGVy Lgo+PiA+PiAKPj4gPj4gSm9obiBhZ3JlZXMgd2l0aCBKdXN0aW4gaW4KPj4gPj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NDguaHRtbCB0 aGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgcGVvcGxlIGFyZSBub3QgbWlzbGVhZCBhYm91 dCB0aGUgaW50ZW50aW9uIG9mIHRoZSBkb2N1bWVudC4gSm9obiBhbHNvIHByb3ZpZGVzIGFkZGl0 aW9uYWwgY29tbWVudHMgaW4gdGhpcyBwb3N0IHRvIHRoZQo+PiA+PiBsaXN0OiBodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sCj4+ ID4+IE1vc3Qgb2YgdGhlbSByZXF1aXJlIG1vcmUgdGhhbiBqdXN0IGVkaXRpbmcgd29yay4gRm9y IGV4YW1wbGUsIG1ldGhvZHMgbGlzdGVkIGFyZSByZWFsbHkgbm90IHVzZWZ1bCwKPj4gPj4gCj4+ ID4+IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9uIGJ1dCBoYXMgc29tZSBy ZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2VzIG5vdCBwcm9wb3NlIHNw ZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZToKPj4gPj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NjIuaHRtbAo+PiA+PiAKPj4g Pj4gV2l0aCBteSBjby1jaGFpciBoYXQgb246IEkganVzdCB3YW50ZWQgdG8gY2xhcmlmeSB0aGF0 IHJlZ2lzdGVyaW5nIGNsYWltcyAoYW5kIHZhbHVlcyB3aXRoaW4gdGhvc2UgY2xhaW1zKSBpcyB3 aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLiBXZSBzdGFuZGFyZGl6 ZWQgdGhlIEpXVCBpbiB0aGlzIGdyb3VwIGFuZCB3ZSBhcmUgYWxzbyBjaGFydGVyZWQgdG8gc3Rh bmRhcmRpemUgY2xhaW1zLCBhcyB3ZSBhcmUgY3VycmVudGx5IGRvaW5nIHdpdGggdmFyaW91cyBk cmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBpbiB0aGUgSUVURiB3b3VsZCBoYXZlIGxlYWQg dG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCBsZXNzIHNlY3VyaXR5LiBJIGhhdmUgbm8g ZG91YnRzIHRoYXQgd2FzIGEgd3JvbmcgZGVjaXNpb24uCj4+ID4+IAo+PiA+PiBJbiBpdHMgY3Vy cmVudCBmb3JtLCB0aGVyZSBpcyBub3QgZW5vdWdoIHN1cHBvcnQgdG8gaGF2ZSB0aGlzIGRvY3Vt ZW50IGFzIGEgV0cgaXRlbS4KPj4gPj4gCj4+ID4+IFdlIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1l bnQgYXV0aG9ycyBzaG91bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBlYXNpZXIgY29tbWVudHMgYW5k IHN1Ym1pdCBhIG5ldyB2ZXJzaW9uLiBUaGlzIHdvdWxkIGFsbG93IHVzIHRvIHJlYWNoIG91dCB0 byB0aG9zZSB3aG8gaGFkIGV4cHJlc3NlZCBjb25jZXJucyBhYm91dCB0aGUgc2NvcGUgb2YgdGhl IGRvY3VtZW50IHRvIHJlLWV2YWx1YXRlIHRoZWlyIGRlY2lzaW9uLiBBIG5ldyBkcmFmdCB2ZXJz aW9uIHNob3VsZCBhdCBsZWFzdCBhZGRyZXNzIHRoZSBmb2xsb3dpbmcgaXNzdWVzOgo+PiA+PiAK Pj4gPj4gKiBDbGFyaWZ5IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBub3QgYW4gZW5jb3VyYWdlbWVu dCBmb3IgdXNpbmcgT0F1dGggYXMgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wuIEkgYmVsaWV2 ZSB0aGF0IHRoaXMgd291bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBjb25jZXJucyByYWlzZWQgYnkg SnVzdGluIGFuZCBKb2huLgo+PiA+PiAKPj4gPj4gKiBDaGFuZ2UgdGhlIHJlZ2lzdHJ5IHBvbGlj eSwgd2hpY2ggd291bGQgYWRkcmVzcyBvbmUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMsIFdp bGxpYW0sIGFuZCBQaGlsLgo+PiA+PiAKPj4gPj4gVmFyaW91cyBvdGhlciBpdGVtcyByZXF1aXJl IGRpc2N1c3Npb24gc2luY2UgdGhleSBhcmUgbW9yZSBkaWZmaWN1bHQgdG8gYWRkcmVzcy4gRm9y IGV4YW1wbGUsIEpvaG4gbm90ZWQgdGhhdCBoZSBkb2VzIG5vdCBsaWtlIHRoZSB1c2Ugb2YgcmVx dWVzdCBwYXJhbWV0ZXJzLiBVbmZvcnR1bmF0ZWx5LCBubyBhbHRlcm5hdGl2ZSBpcyBvZmZlcmVk LiBJIHVyZ2UgSm9obiB0byBwcm92aWRlIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLCBpZiB0aGVy ZSBpcyBvbmUuIEFsc28sIHRoZSByZW1hcmsgdGhhdCB0aGUgdmFsdWVzIGFyZSBtZWFuaW5nbGVz cyBjb3VsZCBiZSBjb3VudGVyZWQgd2l0aCBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbC4gSmFtZXMg d2FudGVkIHRvIHJlbW92ZSB0aGUgImFtcl92YWx1ZXMiIHBhcmFtZXRlci4KPj4gPj4gSXMgdGhp cyB3aGF0IG90aGVycyB3YW50IGFzIHdlbGw/Cj4+ID4+IAo+PiA+PiBBZnRlciB0aGVzZSBpdGVt cyBoYXZlIGJlZW4gYWRkcmVzc2VkIHdlIGJlbGlldmUgdGhhdCBtb3JlIGZvbGtzIGluIHRoZSBn cm91cCB3aWxsIHN1cHBvcnQgdGhlIGRvY3VtZW50Lgo+PiA+PiAKPj4gPj4gQ2lhbwo+PiA+PiBI YW5uZXMgJiBEZXJlawo+PiA+PiAKPj4gPj4gCj4+ID4+IAo+PiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiA+PiBPQXV0aCBtYWlsaW5nIGxpc3QK Pj4gPj4gT0F1dGhAaWV0Zi5vcmcKPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aAo+PiA+IAo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCj4+ID4gT0F1dGggbWFpbGluZyBsaXN0Cj4+ID4gT0F1dGhAaWV0Zi5v cmcKPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+IAo+ PiDigJQgUm9sYW5kCj4+IAo+PiDigJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBs aXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIgo+PiBGcm9tIOKAmU9wZW4gSG91c2UgZm9yIEJ1dHRl cmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzCj4+IAo+PiAKPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+IE9BdXRo QGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK Pj4gCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+ IE9BdXRoIG1haWxpbmcgbGlzdAo+PiBPQXV0aEBpZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4K ----_com.syntomo.email_754675955045670 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPldlIGNsZWFybHkgaGF2ZSB0aGlzIHByb2JsZW0gYmV0d2VlbiBvYXV0aCBh bmQgb2lkYy4gSnVzdCB0YWtlIGEgbG9vayBhdCB0aGUgZGlzY292ZXJ5IHRocmVhZC48L3A+Cjxw IGRpcj0ibHRyIj5BY2NvcmRpbmcgdG8geW91IGFyZ3VtZW50IEkgc2VlIHR3byBvcHRpb25zOjxi cj4KKDEpIGFtciBzdGF5cyBhbiBvaWRjIGNsYWltLCBpcyB1c2VkIGluIG9pZGMgb25seSBhbmQg dGhlIG9hdXRoIHdnIGp1c3QgcHVibGlzaGVzIHRoZSByZWdpc3RyeSBlbnRyaWVzLiBJbiB0aGlz IGNhc2UsIHRoZSBzcGVjIHNob3VsZCBjbGVhcmx5IGV4cGxhaW4gdGhpcy48YnI+CigyKSBhbXIg aXMgb2YgYW55IHVzZSBpbiBvYXV0aCAoYWx0aG91Z2ggaXQgaGFzIGJlZW4gaW52ZW50ZWQgaW4g b2lkYykgLSB0aGFuIGRlZmluZSBpdCBhbmQgbW90aXZhdGUgaXQncyB1c2UgaW4gb2F1dGggaW4g dGhpcyBzcGVjLiA8L3A+CjxwIGRpcj0ibHRyIj5SaWdodCBub3csIEkgdGhpbmsgaXQgY3JlYXRl cyB0aGUgaW1wcmVzc2lvbiBvYXV0aCBpcyBmb3IgYXV0aGVudGljYXRpb24uIDwvcD4KPGJyPjxi cj4tLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLTxicj5CZXRyZWZmOiBSZTogW09B VVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3Ig QWRvcHRpb24gRmluYWxpemVkPGJyPlZvbjogSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRi LmNvbSZndDs8YnI+QW46IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PGJyPkNjOiByb2xhbmQuaGVk YmVyZ0B1bXUuc2Usb2F1dGhAaWV0Zi5vcmc8YnI+PGJyPlRoaXMgaXMgbm90IGEgaXNzdWUgYmV0 d2VlbiBvYXV0aCBhbmQgT0lEQy48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2 IGNsYXNzPSIiPlRoaXMgaGFzIHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJ5IGZvciBKV1QgYmVpbmcg aW4gT0F1dGguICZuYnNwOyBNYW55IHByb3RvY29scyB0aGF0IHVzZSBKV1QgYXJlIGdvaW5nIHRv IHdhbnQgdG8gcmVnaXN0ZXIgY2xhaW1zLiAmbmJzcDs8L2Rpdj48ZGl2IGNsYXNzPSIiPldlIGNh buKAmXQgYXNrIHRoZW0gdG8gYWxsIG1vdmUgdGhlIHBhcnRzIG9mIHRoZXJlIHNwZWNzIHRoYXQg dXNlIEpXVCB0byBPQXV0aC48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48 ZGl2IGNsYXNzPSIiPlBlcmhhcHMgSldUIHNob3VsZCBoYXZlIGJlZW4gcGFydCBvZiBKT1NFLCBi dXQgdGhhdCBpcyB3YXRlciB1bmRlciB0aGUgYnJpZGdlLiAmbmJzcDs8L2Rpdj48ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPlRoZSBPQXV0aCBXRyBpcyByZXNw b25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMgcmVnaXN0cnksIGFuZCB3ZSB3aWxsIG5lZWQgdG8g ZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWltcy4gJm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5JIGd1ZXNzIHRoYXQgd2UgY2FuIHRlbGwg cGVvcGxlIHRoYXQgdGhleSBuZWVkIHRvIHB1Ymxpc2ggdGhlIHNwZWNzIGRlZmluaW5nIHRoZSBj bGFpbXMgc29tZXBsYWNlIGVsc2UsIGFuZCBqdXN0IGRvIHRoZSByZWdpc3RyeSBwYXJ0LjwvZGl2 PjxkaXYgY2xhc3M9IiI+SG93ZXZlciBkb2luZyB0aGF0IHdpbGwgcHJvYmFibHkgbm90IGltcHJv dmUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdW5kZXJzdGFuZGluZy48L2Rpdj48ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPlRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0 aGUgY2xhaW0gZm9yIEpXVCBpbiBnZW5lcmFsLiAmbmJzcDtXZSBzdGlsbCBoYXZlIGFsbW9zdCBu byBkb2N1bWVudGF0aW9uIGluIHRoZSBXRyBhYm91dCB3aGF0IGEgSldUIGFjY2VzcyB0b2tlbiB3 b3VsZCBjb250YWluIG90aGVyIHRoYW4gdGhlIFBPUCB3b3JrLjwvZGl2PjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+Sm9obiBCLjxiciBjbGFzcz0iIj48ZGl2 PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+T24gRmViIDEz LCAyMDE2LCBhdCA5OjE4IEFNLCA8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQiIGNsYXNzPSIiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPiB3cm90ZTo8L2Rpdj48YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxkaXYgY2xhc3M9IiI+PHAgZGlyPSJs dHIiIGNsYXNzPSIiPkkgYmFzaWNhbGx5IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu dC4gQXNzZXJ0aW5nIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgaW4gYWNjZXNzIHRva2VucyAoaW4g dGhpcyBjYXNlIGluIEpXVFMgZm9ybWF0KSBpcyByZWFzb25hYmxlLiBXZSB1c2UgaXQgdG8gcGFz cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIHByaW9yIGlz c3VpbmcgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfIHNlcnZlci4gPC9wPjxwIGRp cj0ibHRyIiBjbGFzcz0iIj5XaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sgYW5kIGZvcnRoIGJl dHdlZW4gb2F1dGggYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5lZCBpbiBvaWRjICh3 aGljaCBzaXRzIG9uIHRvcCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBzcGVjaWZpZXMgdGhl IHJlZ2lzdHJ5PyBNb3Jlb3ZlciwgdGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBnaXZlIGEgcmF0 aW9uYWxlIGZvciB1c2luZyBhbXIgaW4gY29udGV4dCBvZiBvYXV0aC48L3A+PHAgZGlyPSJsdHIi IGNsYXNzPSIiPkFzIGEgV0cgd2UgbmVlZCB0byBmaW5kIGEgY2xlYXIgZGVsaW5lYXRpb24gYmV0 d2VlbiBib3RoIHByb3RvY29scywgb3RoZXJ3aXNlIG5vb25lIHdpbGwgcmVhbGx5IHVuZGVyc3Rh bmQgdGhlIGRpZmZlcmVuY2UgYW5kIHdoZW4gdG8gdXNlIHdoYXQuIFdlIGNyZWF0ZSBjb25mdXNp b24hIDwvcD48cCBkaXI9Imx0ciIgY2xhc3M9IiI+Rm9yIHRoaXMgcGFydGljdWxhciBkcmFmdCB0 aGlzIG1lYW5zIHRvIGVpdGhlciBtb3ZlIGFtciB0byBvYXV0aCBvciB0aGUgcmVnaXN0cnkgdG8g b2lkYy4gPC9wPjxwIGRpcj0ibHRyIiBjbGFzcz0iIj5iZXN0IHJlZ2FyZHMsIDxiciBjbGFzcz0i Ij4NClRvcnN0ZW4uPC9wPg0KPGJyIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4tLS0tLS0tLSBVcnNw csO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS08YnIgY2xhc3M9IiI+Vm9uOiBSb2xhbmQgSGVk YmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGFuZC5oZWRiZXJnQHVtdS5zZSIgY2xhc3M9IiI+ cm9sYW5kLmhlZGJlcmdAdW11LnNlPC9hPiZndDs8YnIgY2xhc3M9IiI+R2VzZW5kZXQ6IEZyaWRh eSwgRmVicnVhcnkgMTIsIDIwMTYgMDU6NDUgUE08YnIgY2xhc3M9IiI+QW46IDxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNz PSIiPkJldHJlZmY6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQ8YnIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPjxwIGNsYXNzPSIiPisxPGJyIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4mZ3Q7IDEyIGZl YiAyMDE2IGtsLiAxNjo1OCBza3JldiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbSIgY2xhc3M9IiI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozo8YnIg Y2xhc3M9IiI+Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyArMSB0byBhZG9wdCB0aGlzIGRyYWZ0Ljxi ciBjbGFzcz0iIj4mZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBPbiBGZWIgMTIsIDIwMTYsIGF0 IDM6MDcgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iIGNsYXNzPSIiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyZndDsgRHJhZnQg LTA1IGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sgZGVzY3JpYmVkIGJlbG93IC0gZGVsZXRpbmcg dGhlIHJlcXVlc3QgcGFyYW1ldGVyLCBub3RpbmcgdGhhdCB0aGlzIHNwZWMgaXNuJ3QgYW4gZW5j b3VyYWdlbWVudCB0byB1c2UgT0F1dGggMi4wIGZvciBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGVt cGxveWluZyBhcHByb3ByaWF0ZSBleHRlbnNpb25zLCBhbmQgbm8gbG9uZ2VyIHJlcXVpcmluZyBh IHNwZWNpZmljYXRpb24gZm9yIElBTkEgcmVnaXN0cmF0aW9uLiZuYnNwOyBJIGJlbGlldmUgdGhh dCBpdOKAmXMgbm93IHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLjxiciBjbGFzcz0i Ij4mZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxiciBjbGFzcz0i Ij4mZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnIgY2xhc3M9IiI+Jmd0OyZndDsgRnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzwvYT5dIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxiciBjbGFzcz0iIj4mZ3Q7Jmd0 OyBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgNCwgMjAxNiAxMToyMyBBTTxiciBjbGFzcz0iIj4m Z3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiBjbGFzcz0iIj5vYXV0 aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+Jmd0OyZndDsgU3ViamVjdDogW09BVVRILVdHXSBB dXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24g RmluYWxpemVkPGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBIaSBh bGwsPGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBPbiBKYW51YXJ5 IDE5dGggSSBwb3N0ZWQgYSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgQXV0aGVudGljYXRpb24g TWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgc3BlY2lmaWNhdGlvbiwgc2VlIDxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDAyLmh0 bWwiIGNsYXNzPSIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j dXJyZW50L21zZzE1NDAyLmh0bWw8L2E+PGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0i Ij4mZ3Q7Jmd0OyBXaGF0IHN1cnByaXNlZCB1cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0 dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmluZSBuZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSByZWdp c3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBhIGJpZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdoYXQg dGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29oYW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNl cXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhlIGxpc3Qgc2hvd3MuIFRoZSBmZWVkYmFjayBs ZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBpdCBpcyBhIGJpdCBkaWZmaWN1bHQgZm9yIERlcmVr IGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vuc3VzLjxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YnIg Y2xhc3M9IiI+Jmd0OyZndDsgTGV0IG1lIHRlbGwgeW91IHdoYXQgd2Ugc2VlIGZyb20gdGhlIGNv bW1lbnRzIG9uIHRoZSBsaXN0LjxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0 OyZndDsgSW4gaGlzIHJldmlldyBhdDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyMy5o dG1sIiBjbGFzcz0iIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQyMy5odG1sPC9hPiBKYW1lcyBNYW5nZXIgYXNrcyBmb3Igc2lnbmlmaWNh bnQgY2hhbmdlcy4gQW1vbmcgb3RoZXIgdGhpbmdzLCBoZSB3YW50cyB0byByZW1vdmUgb25lIG9m IHRoZSBjbGFpbXMuIEhlIHByb3ZpZGVzIGEgZGV0YWlsZWQgcmV2aWV3IGFuZCBhY3Rpb25hYmxl IGl0ZW1zLjxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyZndDsgV2lsbGlh bSBEZW5uaXNzIGJlbGlldmVzIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0 IGFncmVlcyB3aXRoIHNvbWUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlz IHJldmlldzo8YnIgY2xhc3M9IiI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjYuaHRtbCIgY2xhc3M9IiI+ aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0 MjYuaHRtbDwvYT48YnIgY2xhc3M9IiI+Jmd0OyZndDsgPGJyIGNsYXNzPSIiPiZndDsmZ3Q7IEp1 c3RpbiBpcyBjZXJ0YWlubHkgdGhlIHJldmlld2VyIHdpdGggdGhlIHN0cm9uZ2VzdCBvcGluaW9u LiBIZXJlIGlzIG9uZSBvZiBoaXMgcG9zdHM6PGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1 NDU3Lmh0bWwiIGNsYXNzPSIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzE1NDU3Lmh0bWw8L2E+PGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBj bGFzcz0iIj4mZ3Q7Jmd0OyBBbW9uZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUg Zm9sbG93aW5nIG9uZSBpcyBhY3R1YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3Jy aWVkIHRoYXQgcmVwb3J0aW5nIGhvdyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgYW5kIGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9y IGF1dGhlbnRpY2F0aW9uIGlzIGEgZmluZSBsaW5lLiBIZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9j dW1lbnQgbGVhZHMgcmVhZGVycyB0byBiZWxpZXZlIHRoZSBsYXR0ZXIuPGJyIGNsYXNzPSIiPiZn dDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBKb2huIGFncmVlcyB3aXRoIEp1c3RpbiBpbjxi ciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1sIiBjbGFzcz0iIj5odHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1sPC9h PiB0aGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgcGVvcGxlIGFyZSBub3QgbWlzbGVhZCBh Ym91dCB0aGUgaW50ZW50aW9uIG9mIHRoZSBkb2N1bWVudC4gSm9obiBhbHNvIHByb3ZpZGVzIGFk ZGl0aW9uYWwgY29tbWVudHMgaW4gdGhpcyBwb3N0IHRvIHRoZTxiciBjbGFzcz0iIj4mZ3Q7Jmd0 OyBsaXN0OiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1 dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sIiBjbGFzcz0iIj5odHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sPC9hPjxiciBjbGFzcz0i Ij4mZ3Q7Jmd0OyBNb3N0IG9mIHRoZW0gcmVxdWlyZSBtb3JlIHRoYW4ganVzdCBlZGl0aW5nIHdv cmsuIEZvciBleGFtcGxlLCBtZXRob2RzIGxpc3RlZCBhcmUgcmVhbGx5IG5vdCB1c2VmdWwsPGJy IGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBQaGlsIGFncmVlcyB3aXRo IHRoZSBkb2N1bWVudCBhZG9wdGlvbiBidXQgaGFzIHNvbWUgcmVtYXJrcyBhYm91dCB0aGUgcmVn aXN0cnkgYWx0aG91Z2ggaGUgZG9lcyBub3QgcHJvcG9zZSBzcGVjaWZpYyB0ZXh0LiBIaXMgcmV2 aWV3IGlzIGhlcmU6PGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDYyLmh0bWwiIGNsYXNz PSIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21z ZzE1NDYyLmh0bWw8L2E+PGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0 OyBXaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQg cmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdp dGhpbiB0aGUgc2NvcGUgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXpl ZCB0aGUgSldUIGluIHRoaXMgZ3JvdXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFu ZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzIGRy YWZ0cy4gTm90IHN0YW5kYXJkaXppbmcgSldUIGluIHRoZSBJRVRGIHdvdWxkIGhhdmUgbGVhZCB0 byByZWR1Y2VkIGludGVyb3BlcmFiaWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHkuIEkgaGF2ZSBubyBk b3VidHMgdGhhdCB3YXMgYSB3cm9uZyBkZWNpc2lvbi48YnIgY2xhc3M9IiI+Jmd0OyZndDsgPGJy IGNsYXNzPSIiPiZndDsmZ3Q7IEluIGl0cyBjdXJyZW50IGZvcm0sIHRoZXJlIGlzIG5vdCBlbm91 Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBpdGVtLjxiciBjbGFzcz0i Ij4mZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyZndDsgV2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1 bWVudCBhdXRob3JzIHNob3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGVhc2llciBjb21tZW50cyBh bmQgc3VibWl0IGEgbmV3IHZlcnNpb24uIFRoaXMgd291bGQgYWxsb3cgdXMgdG8gcmVhY2ggb3V0 IHRvIHRob3NlIHdobyBoYWQgZXhwcmVzc2VkIGNvbmNlcm5zIGFib3V0IHRoZSBzY29wZSBvZiB0 aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVhdGUgdGhlaXIgZGVjaXNpb24uIEEgbmV3IGRyYWZ0IHZl cnNpb24gc2hvdWxkIGF0IGxlYXN0IGFkZHJlc3MgdGhlIGZvbGxvd2luZyBpc3N1ZXM6PGJyIGNs YXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyAqIENsYXJpZnkgdGhhdCB0aGlz IGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJhZ2VtZW50IGZvciB1c2luZyBPQXV0aCBhcyBhbiBh dXRoZW50aWNhdGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3VsZCBhZGRyZXNz IHNvbWUgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSBKdXN0aW4gYW5kIEpvaG4uPGJyIGNsYXNz PSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyAqIENoYW5nZSB0aGUgcmVnaXN0cnkg cG9saWN5LCB3aGljaCB3b3VsZCBhZGRyZXNzIG9uZSBvZiB0aGUgY29tbWVudHMgZnJvbSBKYW1l cywgV2lsbGlhbSwgYW5kIFBoaWwuPGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4m Z3Q7Jmd0OyBWYXJpb3VzIG90aGVyIGl0ZW1zIHJlcXVpcmUgZGlzY3Vzc2lvbiBzaW5jZSB0aGV5 IGFyZSBtb3JlIGRpZmZpY3VsdCB0byBhZGRyZXNzLiBGb3IgZXhhbXBsZSwgSm9obiBub3RlZCB0 aGF0IGhlIGRvZXMgbm90IGxpa2UgdGhlIHVzZSBvZiByZXF1ZXN0IHBhcmFtZXRlcnMuIFVuZm9y dHVuYXRlbHksIG5vIGFsdGVybmF0aXZlIGlzIG9mZmVyZWQuIEkgdXJnZSBKb2huIHRvIHByb3Zp ZGUgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwsIGlmIHRoZXJlIGlzIG9uZS4gQWxzbywgdGhlIHJl bWFyayB0aGF0IHRoZSB2YWx1ZXMgYXJlIG1lYW5pbmdsZXNzIGNvdWxkIGJlIGNvdW50ZXJlZCB3 aXRoIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLiBKYW1lcyB3YW50ZWQgdG8gcmVtb3ZlIHRoZSAi YW1yX3ZhbHVlcyIgcGFyYW1ldGVyLjxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBJcyB0aGlzIHdoYXQg b3RoZXJzIHdhbnQgYXMgd2VsbD88YnIgY2xhc3M9IiI+Jmd0OyZndDsgPGJyIGNsYXNzPSIiPiZn dDsmZ3Q7IEFmdGVyIHRoZXNlIGl0ZW1zIGhhdmUgYmVlbiBhZGRyZXNzZWQgd2UgYmVsaWV2ZSB0 aGF0IG1vcmUgZm9sa3MgaW4gdGhlIGdyb3VwIHdpbGwgc3VwcG9ydCB0aGUgZG9jdW1lbnQuPGJy IGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyBDaWFvPGJyIGNsYXNzPSIi PiZndDsmZ3Q7IEhhbm5lcyAmYW1wOyBEZXJlazxiciBjbGFzcz0iIj4mZ3Q7Jmd0OyA8YnIgY2xh c3M9IiI+Jmd0OyZndDsgPGJyIGNsYXNzPSIiPiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4mZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFz cz0iIj4mZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aDwvYT48YnIgY2xhc3M9IiI+Jmd0OyA8YnIgY2xhc3M9IiI+Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4m Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPiZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 YnIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPuKAlCBSb2xhbmQ8YnIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPuKAnUV2ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBzdHJlYW0gYW5k IGxpc3Rlbi4iPGJyIGNsYXNzPSIiPkZyb20g4oCZT3BlbiBIb3VzZSBmb3IgQnV0dGVyZmxpZXPi gJkgYnkgUnV0aCBLcmF1c3M8YnIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjxiciBjbGFzcz0iIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i Ij5PQXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxiciBjbGFzcz0iIj48L3A+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+T0F1 dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyIgY2xhc3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnIgY2xhc3M9IiI+PC9kaXY+PC9ibG9ja3F1 b3RlPjwvZGl2PjxiciBjbGFzcz0iIj48L2Rpdj4= ----_com.syntomo.email_754675955045670-- From nobody Sat Feb 13 07:07:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5F1A002A for ; Sat, 13 Feb 2016 07:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7816dEgbCWD for ; Sat, 13 Feb 2016 07:06:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A811A0026 for ; Sat, 13 Feb 2016 07:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=62O0v4Xoe4/z/uo3hmn2gWPon6Z1Ijge12NRe/uNozA=; b=fb4cV0RbQkcXYqMjsBvbF1U1hcDScJIppCy9LO0xlqsse0QERkpyA47lKJ/MCmF8J9En1mznLr0j5AQq5N8bm0XH0OfA9m0GbbJQLka0h45me6b0zJHxNdPntJvoZyKH+yuB2p4EsMf7rnTG3qxl+o2o/s09bOhWyw2Kdzi8nTY= Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB436.namprd03.prod.outlook.com (10.141.92.26) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 13 Feb 2016 15:06:12 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0409.017; Sat, 13 Feb 2016 15:06:12 +0000 From: Mike Jones To: "torsten@lodderstedt.net" , John Bradley Thread-Topic: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized Thread-Index: AdFlW5fqU0LQGAlJR6KxWxWGgVl2aAAUrDaAAAGd9IAAKPmtAAAEEECAAADCm4AAANkOkA== Date: Sat, 13 Feb 2016 15:06:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lodderstedt.net; dkim=none (message not signed) header.d=none;lodderstedt.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 9f83ee2c-136d-4902-5f59-08d334873659 x-microsoft-exchange-diagnostics: 1; BL2PR03MB436; 5:EkhJexrY0PCmE/xkcpbmtRaeDqpXFaG84TeCt2EM/g+jyONRPvcInK+6UyACcNGpChtwX9ERBIpRQhy8raW0m1m+M2Q2XhSPcLfKqctICcElgzo0FjcPZTSjs+ThkPXfbv5/gzuV43nT/KyG+DDOoA==; 24:3eqm/zlYl0l2B4qq4WEThft4kJ1hCM8bWvpdyiqaSvdlu8mN8XyWHkBVIfJA6JKUYTdZM5nUrshaColTs0pPIyUQPtkGVuWxKW2PGwkKIV8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB436; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BL2PR03MB436; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB436; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(51694002)(377454003)(13464003)(24454002)(76576001)(5003600100002)(2501003)(19609705001)(5001770100001)(86362001)(19617315012)(5001960100002)(10090500001)(99286002)(189998001)(86612001)(19580405001)(5004730100002)(4326007)(77096005)(2950100001)(561944003)(87936001)(2900100001)(15975445007)(74316001)(50986999)(19625215002)(5008740100001)(16236675004)(122556002)(54356999)(76176999)(790700001)(1220700001)(19300405004)(1096002)(3660700001)(102836003)(33656002)(19580395003)(5005710100001)(10290500002)(586003)(6116002)(10400500002)(11100500001)(92566002)(3846002)(3280700002)(2906002)(66066001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB436; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB433E8ACD3609AF27BB9315CF5AA0BL2PR03MB433namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2016 15:06:12.3771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB436 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 15:06:40 -0000 --_000_BL2PR03MB433E8ACD3609AF27BB9315CF5AA0BL2PR03MB433namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNvbnRleHQgdGhhdCBtb3N0IHBlb3BsZSBvbiB0aGlzIHRocmVhZCBwcm9iYWJseSBkb27i gJl0IGhhdmUgaXMgdGhhdCBhbiBJQU5BIHJlZ2lzdHJ5IGNhbiBvbmx5IGJlIGVzdGFibGlzaGVk IGJ5IGFuIFJGQy4gIE5vbi1SRkMgc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgT3BlbklEIHNwZWNp ZmljYXRpb25zLCBjYW4gKnJlZ2lzdGVyKiB2YWx1ZXMgaW4gYSByZWdpc3RyeSwgYnV0IHRoZXkg Y2Fubm90ICplc3RhYmxpc2gqIGEgcmVnaXN0cnkuICBUaGUgT3BlbklEIEZvdW5kYXRpb24gaW5x dWlyZWQgYWJvdXQgdGhpcyB3aXRoIHRoZSBJRVRGIGJlZm9yZSBPcGVuSUQgQ29ubmVjdCB3YXMg ZmluYWxpemVkIGFuZCBsZWFybmVkIHRoYXQgaXRzIHNwZWNpZmljYXRpb25zIGNvdWxkIG5vdCBl c3RhYmxpc2ggSUFOQSByZWdpc3RyaWVzLiAgT3RoZXJ3aXNlLCB0aGV5IHdvdWxkIGhhdmUuDQoN Ckluc3RlYWQsIFJGQ3MgbmVlZCB0byBiZSBjcmVhdGVkIHRvIGVzdGFibGlzaCByZWdpc3RyaWVz IOKAkyBldmVuIGZvciB2YWx1ZXMgZmlyc3QgZGVmaW5lZCBpbiBub24tUkZDIHNwZWNpZmljYXRp b25zLiAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIG9uZSBleGFtcGxlIG9mIGRvaW5nIHRoaXMuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0DQpTZW50OiBTYXR1cmRheSwgRmVi cnVhcnkgMTMsIDIwMTYgNjozNyBBTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5j b20+DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRp Y2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6 ZWQNCg0KDQpXZSBjbGVhcmx5IGhhdmUgdGhpcyBwcm9ibGVtIGJldHdlZW4gb2F1dGggYW5kIG9p ZGMuIEp1c3QgdGFrZSBhIGxvb2sgYXQgdGhlIGRpc2NvdmVyeSB0aHJlYWQuDQoNCkFjY29yZGlu ZyB0byB5b3UgYXJndW1lbnQgSSBzZWUgdHdvIG9wdGlvbnM6DQooMSkgYW1yIHN0YXlzIGFuIG9p ZGMgY2xhaW0sIGlzIHVzZWQgaW4gb2lkYyBvbmx5IGFuZCB0aGUgb2F1dGggd2cganVzdCBwdWJs aXNoZXMgdGhlIHJlZ2lzdHJ5IGVudHJpZXMuIEluIHRoaXMgY2FzZSwgdGhlIHNwZWMgc2hvdWxk IGNsZWFybHkgZXhwbGFpbiB0aGlzLg0KKDIpIGFtciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoIChh bHRob3VnaCBpdCBoYXMgYmVlbiBpbnZlbnRlZCBpbiBvaWRjKSAtIHRoYW4gZGVmaW5lIGl0IGFu ZCBtb3RpdmF0ZSBpdCdzIHVzZSBpbiBvYXV0aCBpbiB0aGlzIHNwZWMuDQoNClJpZ2h0IG5vdywg SSB0aGluayBpdCBjcmVhdGVzIHRoZSBpbXByZXNzaW9uIG9hdXRoIGlzIGZvciBhdXRoZW50aWNh dGlvbi4NCg0KDQotLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLQ0KQmV0cmVmZjog UmU6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENh bGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZA0KVm9uOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdq dGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpBbjogdG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6IHJvbGFuZC5oZWRiZXJn QHVtdS5zZSxvYXV0aEBpZXRmLm9yZzxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlLG9hdXRo QGlldGYub3JnPg0KDQpUaGlzIGlzIG5vdCBhIGlzc3VlIGJldHdlZW4gb2F1dGggYW5kIE9JREMu DQoNClRoaXMgaGFzIHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJ5IGZvciBKV1QgYmVpbmcgaW4gT0F1 dGguICAgTWFueSBwcm90b2NvbHMgdGhhdCB1c2UgSldUIGFyZSBnb2luZyB0byB3YW50IHRvIHJl Z2lzdGVyIGNsYWltcy4NCldlIGNhbuKAmXQgYXNrIHRoZW0gdG8gYWxsIG1vdmUgdGhlIHBhcnRz IG9mIHRoZXJlIHNwZWNzIHRoYXQgdXNlIEpXVCB0byBPQXV0aC4NCg0KUGVyaGFwcyBKV1Qgc2hv dWxkIGhhdmUgYmVlbiBwYXJ0IG9mIEpPU0UsIGJ1dCB0aGF0IGlzIHdhdGVyIHVuZGVyIHRoZSBi cmlkZ2UuDQoNClRoZSBPQXV0aCBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMg cmVnaXN0cnksIGFuZCB3ZSB3aWxsIG5lZWQgdG8gZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWlt cy4NCg0KSSBndWVzcyB0aGF0IHdlIGNhbiB0ZWxsIHBlb3BsZSB0aGF0IHRoZXkgbmVlZCB0byBw dWJsaXNoIHRoZSBzcGVjcyBkZWZpbmluZyB0aGUgY2xhaW1zIHNvbWVwbGFjZSBlbHNlLCBhbmQg anVzdCBkbyB0aGUgcmVnaXN0cnkgcGFydC4NCkhvd2V2ZXIgZG9pbmcgdGhhdCB3aWxsIHByb2Jh Ymx5IG5vdCBpbXByb3ZlIGludGVyb3BlcmFiaWxpdHkgYW5kIHVuZGVyc3RhbmRpbmcuDQoNClRo aXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgY2xhaW0gZm9yIEpXVCBpbiBnZW5lcmFsLiAgV2Ugc3Rp bGwgaGF2ZSBhbG1vc3Qgbm8gZG9jdW1lbnRhdGlvbiBpbiB0aGUgV0cgYWJvdXQgd2hhdCBhIEpX VCBhY2Nlc3MgdG9rZW4gd291bGQgY29udGFpbiBvdGhlciB0aGFuIHRoZSBQT1Agd29yay4NCg0K Sm9obiBCLg0KT24gRmViIDEzLCAyMDE2LCBhdCA5OjE4IEFNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KDQpJIGJhc2ljYWxs eSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIEFzc2VydGluZyBhdXRoZW50aWNh dGlvbiBtZXRob2RzIGluIGFjY2VzcyB0b2tlbnMgKGluIHRoaXMgY2FzZSBpbiBKV1RTIGZvcm1h dCkgaXMgcmVhc29uYWJsZS4gV2UgdXNlIGl0IHRvIHBhc3MgaW5mb3JtYXRpb24gYWJvdXQgdGhl IGF1dGhlbnRpY2F0aW9uIHBlcmZvcm1lZCBwcmlvciBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiB0 byB0aGUgX3Jlc291cmNlXyBzZXJ2ZXIuDQpXaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sgYW5k IGZvcnRoIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5lZCBp biBvaWRjICh3aGljaCBzaXRzIG9uIHRvcCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBzcGVj aWZpZXMgdGhlIHJlZ2lzdHJ5PyBNb3Jlb3ZlciwgdGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBn aXZlIGEgcmF0aW9uYWxlIGZvciB1c2luZyBhbXIgaW4gY29udGV4dCBvZiBvYXV0aC4NCkFzIGEg V0cgd2UgbmVlZCB0byBmaW5kIGEgY2xlYXIgZGVsaW5lYXRpb24gYmV0d2VlbiBib3RoIHByb3Rv Y29scywgb3RoZXJ3aXNlIG5vb25lIHdpbGwgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVu Y2UgYW5kIHdoZW4gdG8gdXNlIHdoYXQuIFdlIGNyZWF0ZSBjb25mdXNpb24hDQpGb3IgdGhpcyBw YXJ0aWN1bGFyIGRyYWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1yIHRvIG9hdXRoIG9y IHRoZSByZWdpc3RyeSB0byBvaWRjLg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQotLS0t LS0tLSBVcnNwcsO8bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0NClZvbjogUm9sYW5kIEhlZGJl cmcgPHJvbGFuZC5oZWRiZXJnQHVtdS5zZTxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlPj4N Ckdlc2VuZGV0OiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDA1OjQ1IFBNDQpBbjogb2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KQmV0cmVmZjogUmU6IFtPQVVUSC1XR10g QXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9u IEZpbmFsaXplZA0KKzENCg0KPiAxMiBmZWIgMjAxNiBrbC4gMTY6NTggc2tyZXYgSm9obiBCcmFk bGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoNCj4NCj4g KzEgdG8gYWRvcHQgdGhpcyBkcmFmdC4NCj4NCj4+IE9uIEZlYiAxMiwgMjAxNiwgYXQgMzowNyBB TSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+DQo+PiBEcmFmdCAtMDUgaW5jb3Jwb3Jh dGVzIHRoZSBmZWVkYmFjayBkZXNjcmliZWQgYmVsb3cgLSBkZWxldGluZyB0aGUgcmVxdWVzdCBw YXJhbWV0ZXIsIG5vdGluZyB0aGF0IHRoaXMgc3BlYyBpc24ndCBhbiBlbmNvdXJhZ2VtZW50IHRv IHVzZSBPQXV0aCAyLjAgZm9yIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgZW1wbG95aW5nIGFwcHJv cHJpYXRlIGV4dGVuc2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlv biBmb3IgSUFOQSByZWdpc3RyYXRpb24uICBJIGJlbGlldmUgdGhhdCBpdOKAmXMgbm93IHJlYWR5 IGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLg0KPj4NCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pg0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQo+PiBTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgNCwgMjAxNiAxMToyMyBBTQ0KPj4gVG86IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aGVudGlj YXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXpl ZA0KPj4NCj4+IEhpIGFsbCwNCj4+DQo+PiBPbiBKYW51YXJ5IDE5dGggSSBwb3N0ZWQgYSBjYWxs IGZvciBhZG9wdGlvbiBvZiB0aGUgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1 ZXMgc3BlY2lmaWNhdGlvbiwgc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9vYXV0aC9jdXJyZW50L21zZzE1NDAyLmh0bWwNCj4+DQo+PiBXaGF0IHN1cnByaXNlZCB1cyBp cyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmluZSBu ZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBhIGJp ZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29oYW1h IElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhl IGxpc3Qgc2hvd3MuIFRoZSBmZWVkYmFjayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBpdCBp cyBhIGJpdCBkaWZmaWN1bHQgZm9yIERlcmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vuc3Vz Lg0KPj4NCj4+IExldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBv biB0aGUgbGlzdC4NCj4+DQo+PiBJbiBoaXMgcmV2aWV3IGF0DQo+PiBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyMy5odG1sIEphbWVzIE1h bmdlciBhc2tzIGZvciBzaWduaWZpY2FudCBjaGFuZ2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhl IHdhbnRzIHRvIHJlbW92ZSBvbmUgb2YgdGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxl ZCByZXZpZXcgYW5kIGFjdGlvbmFibGUgaXRlbXMuDQo+Pg0KPj4gV2lsbGlhbSBEZW5uaXNzIGJl bGlldmVzIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0IGFncmVlcyB3aXRo IHNvbWUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlzIHJldmlldzoNCj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1 NDI2Lmh0bWwNCj4+DQo+PiBKdXN0aW4gaXMgY2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRo ZSBzdHJvbmdlc3Qgb3Bpbmlvbi4gSGVyZSBpcyBvbmUgb2YgaGlzIHBvc3RzOg0KPj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NTcuaHRt bA0KPj4NCj4+IEFtb25nIGFsbCBjb25jZXJucyBKdXN0aW4gZXhwcmVzc2VkIHRoZSBmb2xsb3dp bmcgb25lIGlzIGFjdHVhbGx5IGFjdGlvbmFibGUgSU1ITzogSnVzdGluIGlzIHdvcnJpZWQgdGhh dCByZXBvcnRpbmcgaG93IGEgcGVyc29uIGF1dGhlbnRpY2F0ZWQgdG8gYW4gYXV0aG9yaXphdGlv biBlbmRwb2ludCBhbmQgZW5jb3VyYWdpbmcgcGVvcGxlIHRvIHVzZSBPQXV0aCBmb3IgYXV0aGVu dGljYXRpb24gaXMgYSBmaW5lIGxpbmUuIEhlIGJlbGlldmVzIHRoYXQgdGhpcyBkb2N1bWVudCBs ZWFkcyByZWFkZXJzIHRvIGJlbGlldmUgdGhlIGxhdHRlci4NCj4+DQo+PiBKb2huIGFncmVlcyB3 aXRoIEp1c3RpbiBpbg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h dXRoL2N1cnJlbnQvbXNnMTU0NDguaHRtbCB0aGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQg cGVvcGxlIGFyZSBub3QgbWlzbGVhZCBhYm91dCB0aGUgaW50ZW50aW9uIG9mIHRoZSBkb2N1bWVu dC4gSm9obiBhbHNvIHByb3ZpZGVzIGFkZGl0aW9uYWwgY29tbWVudHMgaW4gdGhpcyBwb3N0IHRv IHRoZQ0KPj4gbGlzdDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMTU0NDEuaHRtbA0KPj4gTW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFu IGp1c3QgZWRpdGluZyB3b3JrLiBGb3IgZXhhbXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxs eSBub3QgdXNlZnVsLA0KPj4NCj4+IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0 aW9uIGJ1dCBoYXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBk b2VzIG5vdCBwcm9wb3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZToNCj4+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDYy Lmh0bWwNCj4+DQo+PiBXaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0IHdhbnRlZCB0byBj bGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBj bGFpbXMpIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdl IHN0YW5kYXJkaXplZCB0aGUgSldUIGluIHRoaXMgZ3JvdXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0 ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0 aCB2YXJpb3VzIGRyYWZ0cy4gTm90IHN0YW5kYXJkaXppbmcgSldUIGluIHRoZSBJRVRGIHdvdWxk IGhhdmUgbGVhZCB0byByZWR1Y2VkIGludGVyb3BlcmFiaWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHku IEkgaGF2ZSBubyBkb3VidHMgdGhhdCB3YXMgYSB3cm9uZyBkZWNpc2lvbi4NCj4+DQo+PiBJbiBp dHMgY3VycmVudCBmb3JtLCB0aGVyZSBpcyBub3QgZW5vdWdoIHN1cHBvcnQgdG8gaGF2ZSB0aGlz IGRvY3VtZW50IGFzIGEgV0cgaXRlbS4NCj4+DQo+PiBXZSBiZWxpZXZlIHRoYXQgdGhlIGRvY3Vt ZW50IGF1dGhvcnMgc2hvdWxkIGFkZHJlc3Mgc29tZSBvZiB0aGUgZWFzaWVyIGNvbW1lbnRzIGFu ZCBzdWJtaXQgYSBuZXcgdmVyc2lvbi4gVGhpcyB3b3VsZCBhbGxvdyB1cyB0byByZWFjaCBvdXQg dG8gdGhvc2Ugd2hvIGhhZCBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgdGhlIHNjb3BlIG9mIHRo ZSBkb2N1bWVudCB0byByZS1ldmFsdWF0ZSB0aGVpciBkZWNpc2lvbi4gQSBuZXcgZHJhZnQgdmVy c2lvbiBzaG91bGQgYXQgbGVhc3QgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3VlczoNCj4+DQo+ PiAqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJhZ2VtZW50IGZv ciB1c2luZyBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRo YXQgdGhpcyB3b3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSBKdXN0 aW4gYW5kIEpvaG4uDQo+Pg0KPj4gKiBDaGFuZ2UgdGhlIHJlZ2lzdHJ5IHBvbGljeSwgd2hpY2gg d291bGQgYWRkcmVzcyBvbmUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMsIFdpbGxpYW0sIGFu ZCBQaGlsLg0KPj4NCj4+IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9uIHNp bmNlIHRoZXkgYXJlIG1vcmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBKb2hu IG5vdGVkIHRoYXQgaGUgZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1ldGVy cy4gVW5mb3J0dW5hdGVseSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpvaG4g dG8gcHJvdmlkZSBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUgaXMgb25lLiBBbHNv LCB0aGUgcmVtYXJrIHRoYXQgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291bGQgYmUgY291 bnRlcmVkIHdpdGggYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwuIEphbWVzIHdhbnRlZCB0byByZW1v dmUgdGhlICJhbXJfdmFsdWVzIiBwYXJhbWV0ZXIuDQo+PiBJcyB0aGlzIHdoYXQgb3RoZXJzIHdh bnQgYXMgd2VsbD8NCj4+DQo+PiBBZnRlciB0aGVzZSBpdGVtcyBoYXZlIGJlZW4gYWRkcmVzc2Vk IHdlIGJlbGlldmUgdGhhdCBtb3JlIGZvbGtzIGluIHRoZSBncm91cCB3aWxsIHN1cHBvcnQgdGhl IGRvY3VtZW50Lg0KPj4NCj4+IENpYW8NCj4+IEhhbm5lcyAmIERlcmVrDQo+Pg0KPj4NCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gT0F1 dGggbWFpbGluZyBsaXN0DQo+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K4oCUIFJvbGFuZA0K DQrigJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBs aXN0ZW4uIg0KRnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEty YXVzcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_BL2PR03MB433E8ACD3609AF27BB9315CF5AA0BL2PR03MB433namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgY29udGV4 dCB0aGF0IG1vc3QgcGVvcGxlIG9uIHRoaXMgdGhyZWFkIHByb2JhYmx5IGRvbuKAmXQgaGF2ZSBp cyB0aGF0IGFuIElBTkEgcmVnaXN0cnkgY2FuIG9ubHkgYmUgZXN0YWJsaXNoZWQgYnkgYW4gUkZD LiZuYnNwOyBOb24tUkZDIHNwZWNpZmljYXRpb25zLCBzdWNoIGFzIE9wZW5JRA0KIHNwZWNpZmlj YXRpb25zLCBjYW4gKjxiPnJlZ2lzdGVyPC9iPiogdmFsdWVzIGluIGEgcmVnaXN0cnksIGJ1dCB0 aGV5IGNhbm5vdCAqPGI+ZXN0YWJsaXNoPC9iPiogYSByZWdpc3RyeS4mbmJzcDsgVGhlIE9wZW5J RCBGb3VuZGF0aW9uIGlucXVpcmVkIGFib3V0IHRoaXMgd2l0aCB0aGUgSUVURiBiZWZvcmUgT3Bl bklEIENvbm5lY3Qgd2FzIGZpbmFsaXplZCBhbmQgbGVhcm5lZCB0aGF0IGl0cyBzcGVjaWZpY2F0 aW9ucyBjb3VsZCBub3QgZXN0YWJsaXNoDQogSUFOQSByZWdpc3RyaWVzLiZuYnNwOyBPdGhlcndp c2UsIHRoZXkgd291bGQgaGF2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPkluc3RlYWQsIFJGQ3MgbmVlZCB0byBiZSBjcmVhdGVkIHRvIGVzdGFibGlzaCByZWdp c3RyaWVzIOKAkyBldmVuIGZvciB2YWx1ZXMgZmlyc3QgZGVmaW5lZCBpbiBub24tUkZDIHNwZWNp ZmljYXRpb25zLiZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gaXMgb25lIGV4YW1wbGUgb2YgZG9p bmcNCiB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEZlYnJ1YXJ5IDEzLCAyMDE2IDY6 MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2Fs bCBmb3IgQWRvcHRpb24gRmluYWxpemVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5XZSBjbGVhcmx5IGhhdmUgdGhp cyBwcm9ibGVtIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIEp1c3QgdGFrZSBhIGxvb2sgYXQgdGhl IGRpc2NvdmVyeSB0aHJlYWQuPG86cD48L286cD48L3A+DQo8cD5BY2NvcmRpbmcgdG8geW91IGFy Z3VtZW50IEkgc2VlIHR3byBvcHRpb25zOjxicj4NCigxKSBhbXIgc3RheXMgYW4gb2lkYyBjbGFp bSwgaXMgdXNlZCBpbiBvaWRjIG9ubHkgYW5kIHRoZSBvYXV0aCB3ZyBqdXN0IHB1Ymxpc2hlcyB0 aGUgcmVnaXN0cnkgZW50cmllcy4gSW4gdGhpcyBjYXNlLCB0aGUgc3BlYyBzaG91bGQgY2xlYXJs eSBleHBsYWluIHRoaXMuPGJyPg0KKDIpIGFtciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoIChhbHRo b3VnaCBpdCBoYXMgYmVlbiBpbnZlbnRlZCBpbiBvaWRjKSAtIHRoYW4gZGVmaW5lIGl0IGFuZCBt b3RpdmF0ZSBpdCdzIHVzZSBpbiBvYXV0aCBpbiB0aGlzIHNwZWMuDQo8bzpwPjwvbzpwPjwvcD4N CjxwPlJpZ2h0IG5vdywgSSB0aGluayBpdCBjcmVhdGVzIHRoZSBpbXByZXNzaW9uIG9hdXRoIGlz IGZvciBhdXRoZW50aWNhdGlvbi4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCi0tLS0tLS0tIE9yaWdpbmFsbmFjaHJpY2h0IC0tLS0tLS0tPGJyPg0K QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBW YWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZDxicj4NClZvbjogSm9obiBCcmFkbGV5 ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29t PC9hPiZndDs8YnI+DQpBbjogPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnJv bGFuZC5oZWRiZXJnQHVtdS5zZSxvYXV0aEBpZXRmLm9yZyI+cm9sYW5kLmhlZGJlcmdAdW11LnNl LG9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxicj4NClRoaXMgaXMgbm90IGEgaXNzdWUgYmV0d2Vl biBvYXV0aCBhbmQgT0lEQy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgaGFzIHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJ5IGZvciBKV1QgYmVpbmcgaW4g T0F1dGguICZuYnNwOyBNYW55IHByb3RvY29scyB0aGF0IHVzZSBKV1QgYXJlIGdvaW5nIHRvIHdh bnQgdG8gcmVnaXN0ZXIgY2xhaW1zLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNhbuKAmXQgYXNrIHRoZW0gdG8gYWxsIG1vdmUg dGhlIHBhcnRzIG9mIHRoZXJlIHNwZWNzIHRoYXQgdXNlIEpXVCB0byBPQXV0aC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBKV1Qg c2hvdWxkIGhhdmUgYmVlbiBwYXJ0IG9mIEpPU0UsIGJ1dCB0aGF0IGlzIHdhdGVyIHVuZGVyIHRo ZSBicmlkZ2UuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgT0F1dGggV0cgaXMgcmVzcG9uc2libGUgZm9yIEpXVCBhbmQgaXTi gJlzIHJlZ2lzdHJ5LCBhbmQgd2Ugd2lsbCBuZWVkIHRvIGRlYWwgd2l0aCByZWdpc3RlcmluZyBj bGFpbXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGd1ZXNzIHRoYXQgd2UgY2FuIHRlbGwgcGVvcGxlIHRoYXQgdGhleSBuZWVk IHRvIHB1Ymxpc2ggdGhlIHNwZWNzIGRlZmluaW5nIHRoZSBjbGFpbXMgc29tZXBsYWNlIGVsc2Us IGFuZCBqdXN0IGRvIHRoZSByZWdpc3RyeSBwYXJ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciBkb2luZyB0aGF0IHdpbGwgcHJvYmFi bHkgbm90IGltcHJvdmUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdW5kZXJzdGFuZGluZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSBjbGFpbSBmb3IgSldUIGluIGdlbmVyYWwuICZuYnNwO1dlIHN0aWxs IGhhdmUgYWxtb3N0IG5vIGRvY3VtZW50YXRpb24gaW4gdGhlIFdHIGFib3V0IHdoYXQgYSBKV1Qg YWNjZXNzIHRva2VuIHdvdWxkIGNvbnRhaW4gb3RoZXIgdGhhbiB0aGUgUE9QIHdvcmsuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG ZWIgMTMsIDIwMTYsIGF0IDk6MTggQU0sIDxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldCI+DQp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4gd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBiYXNpY2FsbHkgc3VwcG9ydCBhZG9wdGlv biBvZiB0aGlzIGRvY3VtZW50LiBBc3NlcnRpbmcgYXV0aGVudGljYXRpb24gbWV0aG9kcyBpbiBh Y2Nlc3MgdG9rZW5zIChpbiB0aGlzIGNhc2UgaW4gSldUUyBmb3JtYXQpIGlzIHJlYXNvbmFibGUu IFdlIHVzZSBpdCB0byBwYXNzIGluZm9ybWF0aW9uIGFib3V0DQogdGhlIGF1dGhlbnRpY2F0aW9u IHBlcmZvcm1lZCBwcmlvciBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgX3Jlc291cmNl XyBzZXJ2ZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCB3 b3JyaWVzIG1lIGlzIHRoZSBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVuIG9hdXRoIGFuZCBvaWRjLiBU aGUgYW1yIGNsYWltIGlzIGRlZmluZWQgaW4gb2lkYyAod2hpY2ggc2l0cyBvbiB0b3Agb2Ygb2F1 dGgpIGJ1dCB0aGUgb2F1dGggd2cgc3BlY2lmaWVzIHRoZSByZWdpc3RyeT8gTW9yZW92ZXIsIHRo ZQ0KIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBnaXZlIGEgcmF0aW9uYWxlIGZvciB1c2luZyBhbXIg aW4gY29udGV4dCBvZiBvYXV0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QXMgYSBXRyB3ZSBuZWVkIHRvIGZpbmQgYSBjbGVhciBkZWxpbmVhdGlvbiBiZXR3ZWVuIGJv dGggcHJvdG9jb2xzLCBvdGhlcndpc2Ugbm9vbmUgd2lsbCByZWFsbHkgdW5kZXJzdGFuZCB0aGUg ZGlmZmVyZW5jZSBhbmQgd2hlbiB0byB1c2Ugd2hhdC4gV2UgY3JlYXRlIGNvbmZ1c2lvbiENCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgdGhpcyBwYXJ0aWN1bGFy IGRyYWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1yIHRvIG9hdXRoIG9yIHRoZSByZWdp c3RyeSB0byBvaWRjLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJl c3QgcmVnYXJkcywNCjxicj4NClRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCi0tLS0tLS0t IFVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodCAtLS0tLS0tLTxicj4NClZvbjogUm9sYW5kIEhlZGJl cmcgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xhbmQuaGVkYmVyZ0B1bXUuc2UiPnJvbGFuZC5oZWRi ZXJnQHVtdS5zZTwvYT4mZ3Q7PGJyPg0KR2VzZW5kZXQ6IEZyaWRheSwgRmVicnVhcnkgMTIsIDIw MTYgMDU6NDUgUE08YnI+DQpBbjogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0 aEBpZXRmLm9yZzwvYT48YnI+DQpCZXRyZWZmOiBSZTogW09BVVRILVdHXSBBdXRoZW50aWNhdGlv biBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24gRmluYWxpemVkPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MTxicj4NCjxicj4NCiZn dDsgMTIgZmViIDIwMTYga2wuIDE2OjU4IHNrcmV2IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7Ojxicj4N CiZndDsgPGJyPg0KJmd0OyAmIzQzOzEgdG8gYWRvcHQgdGhpcyBkcmFmdC48YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7IE9uIEZlYiAxMiwgMjAxNiwgYXQgMzowNyBBTSwgTWlrZSBKb25lcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgRHJhZnQgLTA1IGluY29ycG9yYXRlcyB0aGUgZmVlZGJhY2sgZGVzY3JpYmVkIGJlbG93IC0g ZGVsZXRpbmcgdGhlIHJlcXVlc3QgcGFyYW1ldGVyLCBub3RpbmcgdGhhdCB0aGlzIHNwZWMgaXNu J3QgYW4gZW5jb3VyYWdlbWVudCB0byB1c2UgT0F1dGggMi4wIGZvciBhdXRoZW50aWNhdGlvbiB3 aXRob3V0IGVtcGxveWluZyBhcHByb3ByaWF0ZSBleHRlbnNpb25zLCBhbmQgbm8gbG9uZ2VyIHJl cXVpcmluZyBhIHNwZWNpZmljYXRpb24gZm9yIElBTkENCiByZWdpc3RyYXRpb24uJm5ic3A7IEkg YmVsaWV2ZSB0aGF0IGl04oCZcyBub3cgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24u PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsg RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9m ZW5pZzxicj4NCiZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA0LCAyMDE2IDExOjIz IEFNPGJyPg0KJmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDogW09BVVRILVdHXSBBdXRoZW50 aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24gRmluYWxp emVkPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSGkgYWxsLDxicj4NCiZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7IE9uIEphbnVhcnkgMTl0aCBJIHBvc3RlZCBhIGNhbGwgZm9yIGFkb3B0aW9u IG9mIHRoZSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBzcGVjaWZpY2F0 aW9uLCBzZWUNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzE1NDAyLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDAyLmh0bWw8L2E+PGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgV2hhdCBzdXJwcmlzZWQgdXMgaXMgdGhhdCB0aGlzIHdvcmsgaXMgY29uY2Vw dHVhbGx5IHZlcnkgc2ltcGxlOiB3ZSBkZWZpbmUgbmV3IGNsYWltcyBhbmQgY3JlYXRlIGEgcmVn aXN0cnkgd2l0aCBuZXcgdmFsdWVzLiBOb3QgYSBiaWcgZGVhbCBidXQgdGhhdCdzIG5vdCB3aGF0 IHRoZSBmZWVkYmFjayBmcm9tIHRoZSBZb2tvaGFtYSBJRVRGIG1lZXRpbmcgYW5kIHRoZSBzdWJz ZXF1ZW50IGNhbGwgZm9yIGFkb3B0aW9uIG9uIHRoZSBsaXN0IHNob3dzLg0KIFRoZSBmZWVkYmFj ayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBpdCBpcyBhIGJpdCBkaWZmaWN1bHQgZm9yIERl cmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vuc3VzLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IExldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBvbiB0 aGUgbGlzdC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJbiBoaXMgcmV2aWV3IGF0PGJy Pg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRtbDwvYT4gSmFtZXMgTWFuZ2VyIGFz a3MgZm9yIHNpZ25pZmljYW50IGNoYW5nZXMuIEFtb25nIG90aGVyIHRoaW5ncywgaGUgd2FudHMg dG8gcmVtb3ZlIG9uZSBvZiB0aGUgY2xhaW1zLiBIZSBwcm92aWRlcw0KIGEgZGV0YWlsZWQgcmV2 aWV3IGFuZCBhY3Rpb25hYmxlIGl0ZW1zLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFdp bGxpYW0gRGVubmlzcyBiZWxpZXZlcyB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIGFkb3B0aW9u IGJ1dCBhZ3JlZXMgd2l0aCBzb21lIG9mIHRoZSBjb21tZW50cyBmcm9tIEphbWVzLiBIZXJlIGlz IGhpcyByZXZpZXc6PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjYuaHRtbCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjYuaHRtbDwvYT48 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBKdXN0aW4gaXMgY2VydGFpbmx5IHRoZSByZXZp ZXdlciB3aXRoIHRoZSBzdHJvbmdlc3Qgb3Bpbmlvbi4gSGVyZSBpcyBvbmUgb2YgaGlzIHBvc3Rz Ojxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDU3Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDU3Lmh0bWw8L2E+PGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgQW1vbmcgYWxsIGNvbmNlcm5zIEp1c3RpbiBleHByZXNzZWQgdGhl IGZvbGxvd2luZyBvbmUgaXMgYWN0dWFsbHkgYWN0aW9uYWJsZSBJTUhPOiBKdXN0aW4gaXMgd29y cmllZCB0aGF0IHJlcG9ydGluZyBob3cgYSBwZXJzb24gYXV0aGVudGljYXRlZCB0byBhbiBhdXRo b3JpemF0aW9uIGVuZHBvaW50IGFuZCBlbmNvdXJhZ2luZyBwZW9wbGUgdG8gdXNlIE9BdXRoIGZv ciBhdXRoZW50aWNhdGlvbiBpcyBhIGZpbmUgbGluZS4gSGUgYmVsaWV2ZXMNCiB0aGF0IHRoaXMg ZG9jdW1lbnQgbGVhZHMgcmVhZGVycyB0byBiZWxpZXZlIHRoZSBsYXR0ZXIuPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgSm9obiBhZ3JlZXMgd2l0aCBKdXN0aW4gaW48YnI+DQomZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQ0OC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1sPC9hPiB0aGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJl IHRoYXQgcGVvcGxlIGFyZSBub3QgbWlzbGVhZCBhYm91dCB0aGUgaW50ZW50aW9uIG9mIHRoZSBk b2N1bWVudC4gSm9obiBhbHNvIHByb3ZpZGVzDQogYWRkaXRpb25hbCBjb21tZW50cyBpbiB0aGlz IHBvc3QgdG8gdGhlPGJyPg0KJmd0OyZndDsgbGlzdDogPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NDEuaHRtbCI+DQpodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0MS5o dG1sPC9hPjxicj4NCiZndDsmZ3Q7IE1vc3Qgb2YgdGhlbSByZXF1aXJlIG1vcmUgdGhhbiBqdXN0 IGVkaXRpbmcgd29yay4gRm9yIGV4YW1wbGUsIG1ldGhvZHMgbGlzdGVkIGFyZSByZWFsbHkgbm90 IHVzZWZ1bCw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBQaGlsIGFncmVlcyB3aXRoIHRo ZSBkb2N1bWVudCBhZG9wdGlvbiBidXQgaGFzIHNvbWUgcmVtYXJrcyBhYm91dCB0aGUgcmVnaXN0 cnkgYWx0aG91Z2ggaGUgZG9lcyBub3QgcHJvcG9zZSBzcGVjaWZpYyB0ZXh0LiBIaXMgcmV2aWV3 IGlzIGhlcmU6PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NjIuaHRtbCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NjIuaHRtbDwvYT48YnI+ DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBXaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0 IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgcmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdp dGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIE9BdXRoIHdvcmtp bmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXplZCB0aGUgSldUIGluIHRoaXMgZ3JvdXAgYW5kIHdlIGFy ZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJyZW50 bHkNCiBkb2luZyB3aXRoIHZhcmlvdXMgZHJhZnRzLiBOb3Qgc3RhbmRhcmRpemluZyBKV1QgaW4g dGhlIElFVEYgd291bGQgaGF2ZSBsZWFkIHRvIHJlZHVjZWQgaW50ZXJvcGVyYWJpbGl0eSBhbmQg bGVzcyBzZWN1cml0eS4gSSBoYXZlIG5vIGRvdWJ0cyB0aGF0IHdhcyBhIHdyb25nIGRlY2lzaW9u Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEluIGl0cyBjdXJyZW50IGZvcm0sIHRoZXJl IGlzIG5vdCBlbm91Z2ggc3VwcG9ydCB0byBoYXZlIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBpdGVt Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFdlIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1l bnQgYXV0aG9ycyBzaG91bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBlYXNpZXIgY29tbWVudHMgYW5k IHN1Ym1pdCBhIG5ldyB2ZXJzaW9uLiBUaGlzIHdvdWxkIGFsbG93IHVzIHRvIHJlYWNoIG91dCB0 byB0aG9zZSB3aG8gaGFkIGV4cHJlc3NlZCBjb25jZXJucyBhYm91dCB0aGUgc2NvcGUgb2YgdGhl IGRvY3VtZW50IHRvIHJlLWV2YWx1YXRlIHRoZWlyIGRlY2lzaW9uLiBBIG5ldyBkcmFmdCB2ZXJz aW9uDQogc2hvdWxkIGF0IGxlYXN0IGFkZHJlc3MgdGhlIGZvbGxvd2luZyBpc3N1ZXM6PGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgKiBDbGFyaWZ5IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBu b3QgYW4gZW5jb3VyYWdlbWVudCBmb3IgdXNpbmcgT0F1dGggYXMgYW4gYXV0aGVudGljYXRpb24g cHJvdG9jb2wuIEkgYmVsaWV2ZSB0aGF0IHRoaXMgd291bGQgYWRkcmVzcyBzb21lIG9mIHRoZSBj b25jZXJucyByYWlzZWQgYnkgSnVzdGluIGFuZCBKb2huLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7ICogQ2hhbmdlIHRoZSByZWdpc3RyeSBwb2xpY3ksIHdoaWNoIHdvdWxkIGFkZHJlc3Mg b25lIG9mIHRoZSBjb21tZW50cyBmcm9tIEphbWVzLCBXaWxsaWFtLCBhbmQgUGhpbC48YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBWYXJpb3VzIG90aGVyIGl0ZW1zIHJlcXVpcmUgZGlzY3Vz c2lvbiBzaW5jZSB0aGV5IGFyZSBtb3JlIGRpZmZpY3VsdCB0byBhZGRyZXNzLiBGb3IgZXhhbXBs ZSwgSm9obiBub3RlZCB0aGF0IGhlIGRvZXMgbm90IGxpa2UgdGhlIHVzZSBvZiByZXF1ZXN0IHBh cmFtZXRlcnMuIFVuZm9ydHVuYXRlbHksIG5vIGFsdGVybmF0aXZlIGlzIG9mZmVyZWQuIEkgdXJn ZSBKb2huIHRvIHByb3ZpZGUgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwsIGlmIHRoZXJlDQogaXMg b25lLiBBbHNvLCB0aGUgcmVtYXJrIHRoYXQgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291 bGQgYmUgY291bnRlcmVkIHdpdGggYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwuIEphbWVzIHdhbnRl ZCB0byByZW1vdmUgdGhlICZxdW90O2Ftcl92YWx1ZXMmcXVvdDsgcGFyYW1ldGVyLjxicj4NCiZn dDsmZ3Q7IElzIHRoaXMgd2hhdCBvdGhlcnMgd2FudCBhcyB3ZWxsPzxicj4NCiZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7IEFmdGVyIHRoZXNlIGl0ZW1zIGhhdmUgYmVlbiBhZGRyZXNzZWQgd2UgYmVs aWV2ZSB0aGF0IG1vcmUgZm9sa3MgaW4gdGhlIGdyb3VwIHdpbGwgc3VwcG9ydCB0aGUgZG9jdW1l bnQuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQ2lhbzxicj4NCiZndDsmZ3Q7IEhhbm5l cyAmYW1wOyBEZXJlazxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZn dDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQrigJQgUm9sYW5k PGJyPg0KPGJyPg0K4oCdRXZlcnlib2R5IHNob3VsZCBiZSBxdWlldCBuZWFyIGEgbGl0dGxlIHN0 cmVhbSBhbmQgbGlzdGVuLiZxdW90Ozxicj4NCkZyb20g4oCZT3BlbiBIb3VzZSBmb3IgQnV0dGVy ZmxpZXPigJkgYnkgUnV0aCBLcmF1c3M8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL2PR03MB433E8ACD3609AF27BB9315CF5AA0BL2PR03MB433namprd_-- From nobody Sat Feb 13 07:07:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDAC1A003B for ; Sat, 13 Feb 2016 07:07:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVhIAkR8OGy5 for ; Sat, 13 Feb 2016 07:07:17 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 B15731A0033 for ; Sat, 13 Feb 2016 07:07:17 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id b35so82922948qge.0 for ; Sat, 13 Feb 2016 07:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hS/4AMk9aYuYstoM2YlWJ1tMAW8nGYDw+l3K05fW8Ro=; b=ciZWfaEgqqaXRiMd0ns6Mq+wWJF4/9q/jlBdfE9ijgiV9EzZG/+XiCZRJu8fRe9FOn pvVBkl0UoGTzES8GnXDwSpW12+sZwYXVcWgHs9dD/wA9/inkLBZunt5cz6vYRh+eTYn+ 4gPv9DWcaaStHLQpSAwsiKlbbRf1UbOSSFVYEmbjtJK67/fvspFWb++bXFZUvgxgpKHa EOFCinaF8Wja85nQWnYynmcsY5Zh2saxUbNAH9qk5ZUwglXk21f4PjseeK7biZagLP4Y h1pxUyLIdTnIbzLhoHABRN8CmwsjmLbx6RzmxQl0dZn5qqOnKPnWM/6ltIGP1O38z5zO Z7Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hS/4AMk9aYuYstoM2YlWJ1tMAW8nGYDw+l3K05fW8Ro=; b=OOJwTzbS/oprQUt+Zx56jokjZUIIBEri+r5It7Vorf8dCwO0tTg2tPQvR/Jq5IZUpK uZDYxqqQLNYIrxV0RLWIG5gvMGxfcXmhTi/OVvZ3ATNE850/rCfjmMrQ7A9WChKnUxkY MgiWGDN8s5FqDxaxcsbFectNsWa8xGinpqDcoO26tx0EXZ7SBWMR9c4CJouzQ5O3QQiL ntrJO2MjyakeK8kzF3sPPSxdmu+G/Qy8B1osK6kSGaDJqj54WOJwJrwF/M7crhC9ePkL mF3ylw7pV1RWfN1oKf3G9pV0Udnxtssy+moKz076NtCJ7BkKRYfG4HLoNYETK/woMSwA OwpA== X-Gm-Message-State: AG10YOSXg+LJTmJQMwVBc/FX6t7lUE5pwtrT6PN7fMXp7gGW9EQu6p3BGKmaz9bic4SbeA== X-Received: by 10.140.234.129 with SMTP id f123mr9202130qhc.67.1455376036751; Sat, 13 Feb 2016 07:07:16 -0800 (PST) Received: from [192.168.1.68] ([191.115.40.128]) by smtp.gmail.com with ESMTPSA id w190sm7553200qhw.29.2016.02.13.07.07.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 13 Feb 2016 07:07:15 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_965720D8-DF7C-408B-A247-658F9FD464B6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Sat, 13 Feb 2016 12:06:56 -0300 Message-Id: References: To: torsten@lodderstedt.net X-Mailer: Apple Mail (2.3112) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 15:07:22 -0000 --Apple-Mail=_965720D8-DF7C-408B-A247-658F9FD464B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_A8DCFA92-5FED-4456-A0F0-ADDC8BE095B9" --Apple-Mail=_A8DCFA92-5FED-4456-A0F0-ADDC8BE095B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was trying to say that the issue about other specs using the JWT = registry is not specific to OIDC. Discovery is a separate issue. If we don=E2=80=99t adopt this document it could go as AD sponsored , = but I don=E2=80=99t think that really addresses your issue.=20 The distinction between AD sponsored and WG document will be lost on any = normal person. Remember that the amr claim is already in the registry registered by the = OIDF. http://www.iana.org/assignments/jwt/jwt.xhtml = This discussion is about if there should be a IANA registry for the = claim values and where it should be.=20 If we want to keep the values registries and the claims together then it = should be in the WG.=20 If not then it can be AD sponsored and a separate IANA registry. =20 As I understand it doing it as a OIDF document would not allow for an = IANA registry and the OIDF would need to run the registry due to IANA = policy. John B. > On Feb 13, 2016, at 11:36 AM, torsten@lodderstedt.net wrote: >=20 > We clearly have this problem between oauth and oidc. Just take a look = at the discovery thread. >=20 > According to you argument I see two options: > (1) amr stays an oidc claim, is used in oidc only and the oauth wg = just publishes the registry entries. In this case, the spec should = clearly explain this. > (2) amr is of any use in oauth (although it has been invented in oidc) = - than define it and motivate it's use in oauth in this spec. >=20 > Right now, I think it creates the impression oauth is for = authentication. >=20 >=20 >=20 > -------- Originalnachricht -------- > Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized > Von: John Bradley > An: torsten@lodderstedt.net > Cc: roland.hedberg@umu.se,oauth@ietf.org >=20 > This is not a issue between oauth and OIDC. >=20 > This has to do with the registry for JWT being in OAuth. Many = protocols that use JWT are going to want to register claims. =20 > We can=E2=80=99t ask them to all move the parts of there specs that = use JWT to OAuth. >=20 > Perhaps JWT should have been part of JOSE, but that is water under the = bridge. =20 >=20 > The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we = will need to deal with registering claims. =20 >=20 > I guess that we can tell people that they need to publish the specs = defining the claims someplace else, and just do the registry part. > However doing that will probably not improve interoperability and = understanding. >=20 > This document defines the claim for JWT in general. We still have = almost no documentation in the WG about what a JWT access token would = contain other than the POP work. >=20 > John B. >> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net = wrote: >>=20 >> I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server. >>=20 >> What worries me is the back and forth between oauth and oidc. The amr = claim is defined in oidc (which sits on top of oauth) but the oauth wg = specifies the registry? Moreover, the current text does not give a = rationale for using amr in context of oauth. >>=20 >> As a WG we need to find a clear delineation between both protocols, = otherwise noone will really understand the difference and when to use = what. We create confusion! >>=20 >> For this particular draft this means to either move amr to oauth or = the registry to oidc. >>=20 >> best regards,=20 >> Torsten. >>=20 >>=20 >>=20 >> -------- Urspr=C3=BCngliche Nachricht -------- >> Von: Roland Hedberg > >> Gesendet: Friday, February 12, 2016 05:45 PM >> An: oauth@ietf.org >> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>=20 >> +1 >>=20 >> > 12 feb 2016 kl. 16:58 skrev John Bradley >: >> >=20 >> > +1 to adopt this draft. >> >=20 >> >> On Feb 12, 2016, at 3:07 AM, Mike Jones = > = wrote: >> >>=20 >> >> Draft -05 incorporates the feedback described below - deleting the = request parameter, noting that this spec isn't an encouragement to use = OAuth 2.0 for authentication without employing appropriate extensions, = and no longer requiring a specification for IANA registration. I = believe that it=E2=80=99s now ready for working group adoption. >> >>=20 >> >> -- Mike >> >>=20 >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >> >> Sent: Thursday, February 4, 2016 11:23 AM >> >> To: oauth@ietf.org >> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >> >>=20 >> >> Hi all, >> >>=20 >> >> On January 19th I posted a call for adoption of the Authentication = Method Reference Values specification, see = http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html = >> >>=20 >> >> What surprised us is that this work is conceptually very simple: = we define new claims and create a registry with new values. Not a big = deal but that's not what the feedback from the Yokohama IETF meeting and = the subsequent call for adoption on the list shows. The feedback lead to = mixed feelings and it is a bit difficult for Derek and myself to judge = consensus. >> >>=20 >> >> Let me tell you what we see from the comments on the list. >> >>=20 >> >> In his review at >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items. >> >>=20 >> >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html = >> >>=20 >> >> Justin is certainly the reviewer with the strongest opinion. Here = is one of his posts: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html = >> >>=20 >> >> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. >> >>=20 >> >> John agrees with Justin in >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html = that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the >> >> list: = http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html = >> >> Most of them require more than just editing work. For example, = methods listed are really not useful, >> >>=20 >> >> Phil agrees with the document adoption but has some remarks about = the registry although he does not propose specific text. His review is = here: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html = >> >>=20 >> >> With my co-chair hat on: I just wanted to clarify that registering = claims (and values within those claims) is within the scope of the OAuth = working group. We standardized the JWT in this group and we are also = chartered to standardize claims, as we are currently doing with various = drafts. Not standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision. >> >>=20 >> >> In its current form, there is not enough support to have this = document as a WG item. >> >>=20 >> >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: >> >>=20 >> >> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John. >> >>=20 >> >> * Change the registry policy, which would address one of the = comments from James, William, and Phil. >> >>=20 >> >> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. >> >> Is this what others want as well? >> >>=20 >> >> After these items have been addressed we believe that more folks = in the group will support the document. >> >>=20 >> >> Ciao >> >> Hannes & Derek >> >>=20 >> >>=20 >> >>=20 >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth = >> >=20 >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =E2=80=94 Roland >>=20 >> =E2=80=9DEverybody should be quiet near a little stream and listen." >> =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_A8DCFA92-5FED-4456-A0F0-ADDC8BE095B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I was trying to say that the issue about other specs using = the JWT registry is not specific to OIDC.

Discovery is a separate = issue.

If we = don=E2=80=99t adopt this document it could go as AD sponsored , but I = don=E2=80=99t think that really addresses your issue. 
The distinction between AD sponsored and WG document will be = lost on any normal person.

Remember that the amr claim is already in the registry = registered by the OIDF.
http://www.iana.org/assignments/jwt/jwt.xhtml

This discussion is about = if there should be a IANA registry for the claim values and where it = should be. 

If we want to keep the values registries and the claims = together then it should be in the WG. 

If not then it can be AD sponsored and = a separate IANA registry.   
As I = understand it doing it as a OIDF document would not allow for an IANA = registry and the OIDF would need to run the registry due to IANA = policy.

John = B.

On Feb 13, 2016, at 11:36 AM, torsten@lodderstedt.net wrote:

We clearly have this problem between oauth and oidc. Just = take a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just = publishes the registry entries. In this case, the spec should clearly = explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - = than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression = oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference = Values: Call for Adoption Finalized
Von: John Bradley = <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a = issue between oauth and OIDC.

This has to do with the registry for JWT being in OAuth. =   Many protocols that use JWT are going to want to register claims. =  
We can=E2=80=99t ask them to all move the = parts of there specs that use JWT to OAuth.

Perhaps JWT should have been part of = JOSE, but that is water under the bridge.  

The OAuth WG is responsible for JWT and = it=E2=80=99s registry, and we will need to deal with registering claims. =  

I guess = that we can tell people that they need to publish the specs defining the = claims someplace else, and just do the registry part.
However doing that will probably not improve interoperability = and understanding.

This document defines the claim for JWT in general.  We = still have almost no documentation in the WG about what a JWT access = token would contain other than the POP work.

John B.
On Feb = 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between = oauth and oidc. The amr claim is defined in oidc (which sits on top of = oauth) but the oauth wg specifies the registry? Moreover, the current = text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation = between both protocols, otherwise noone will really understand the = difference and when to use what. We create confusion!

For this particular draft this means to either move amr to = oauth or the registry to oidc.

best = regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht = --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, = February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference = Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 = skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the = feedback described below - deleting the request parameter, noting that = this spec isn't an encouragement to use OAuth 2.0 for authentication = without employing appropriate extensions, and no longer requiring a = specification for IANA registration.  I believe that it=E2=80=99s = now ready for working group adoption.
>>
>>         &= nbsp;           &nb= sp;            = ;            &= nbsp;            = -- Mike
>>
>> -----Original = Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 = AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] = Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>=
>> On January 19th I posted a call for adoption of = the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.htm= l
>>
>> What surprised us = is that this work is conceptually very simple: we define new claims and = create a registry with new values. Not a big deal but that's not what = the feedback from the Yokohama IETF meeting and the subsequent call for = adoption on the list shows. The feedback lead to mixed feelings and it = is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see = from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.htm= l James Manger asks for significant changes. Among other things, he = wants to remove one of the claims. He provides a detailed review and = actionable items.
>>
>> William = Denniss believes the document is ready for adoption but agrees with some = of the comments from James. Here is his review:
>> = http://www.ietf.org/mail-archive/web/oauth/current/msg15426.htm= l
>>
>> Justin is certainly = the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.htm= l
>>
>> Among all concerns = Justin expressed the following one is actually actionable IMHO: Justin = is worried that reporting how a person authenticated to an authorization = endpoint and encouraging people to use OAuth for authentication is a = fine line. He believes that this document leads readers to believe the = latter.
>>
>> John agrees with = Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.htm= l that we need to make sure that people are not mislead about the = intention of the document. John also provides additional comments in = this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.htm= l
>> Most of them require more than just editing = work. For example, methods listed are really not useful,
>>
>> Phil agrees with the = document adoption but has some remarks about the registry although he = does not propose specific text. His review is here:
>>= http://www.ietf.org/mail-archive/web/oauth/current/msg15462.htm= l
>>
>> With my co-chair = hat on: I just wanted to clarify that registering claims (and values = within those claims) is within the scope of the OAuth working group. We = standardized the JWT in this group and we are also chartered to = standardize claims, as we are currently doing with various drafts. Not = standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision.
>>
>> In its current = form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document = authors should address some of the easier comments and submit a new = version. This would allow us to reach out to those who had expressed = concerns about the scope of the document to re-evaluate their decision. = A new draft version should at least address the following issues:
>>
>> * Clarify that this document = is not an encouragement for using OAuth as an authentication protocol. I = believe that this would address some of the concerns raised by Justin = and John.
>>
>> * Change the = registry policy, which would address one of the comments from James, = William, and Phil.
>>
>> = Various other items require discussion since they are more difficult to = address. For example, John noted that he does not like the use of = request parameters. Unfortunately, no alternative is offered. I urge = John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" = parameter.
>> Is this what others want as well?
>>
>> After these items have been = addressed we believe that more folks in the group will support the = document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> = _______________________________________________
>> = OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> = _______________________________________________
> OAuth = mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and = listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99= by Ruth Krauss


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

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


= --Apple-Mail=_A8DCFA92-5FED-4456-A0F0-ADDC8BE095B9-- --Apple-Mail=_965720D8-DF7C-408B-A247-658F9FD464B6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTMxNTA2NTdaMCMGCSqGSIb3DQEJBDEWBBTF/8X1CZota35ZAbeHxSpZ pr5/OTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA90OWeTKwsCNMe0tRrQUYzrRF984dIMiD3iTB+SeDJsIveTHjdZird HwrBGw/Z4qnW2KjwA6AzhZQfVRH9Wt8ydSgZimC7gJDwVNvfL5umtoxlyUbINEfTnmvTlxfDq1ow DlrVpqJhyvFg73/hFHwYUb59xa3pdgiCo/oiE+DJgGnya8i/kkyeQejT5feHTrZTyvxoQ6pzVLzn 3hL2HzPaPDI8juV74sLRI3sOL0NWJRX8Bb5fvfK/P0sikGo/YtQMlfedDIDnpz8WGjlp6jCeXbl3 qeNL7wrNr2IU07gSV2FpKGIDXH8lxxd8BGA/pRQlRPiigLesmZLpTUOlPrKkAAAAAAAA --Apple-Mail=_965720D8-DF7C-408B-A247-658F9FD464B6-- From nobody Sat Feb 13 07:59:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B631A0302 for ; Sat, 13 Feb 2016 07:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqrvrwYjqX_s for ; Sat, 13 Feb 2016 07:59:26 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.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 4D9F41A028A for ; Sat, 13 Feb 2016 07:59:25 -0800 (PST) Received: from [80.187.110.214] (helo=[10.149.145.182]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aUcbS-0004dP-CK; Sat, 13 Feb 2016 16:59:22 +0100 Date: Sat, 13 Feb 2016 16:59:18 +0100 Message-ID: In-Reply-To: References: From: "torsten@lodderstedt.net" To: Michael.Jones@microsoft.com, John Bradley MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_804275889143071" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 15:59:31 -0000 ----_com.syntomo.email_804275889143071 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U28gYmFzaWNhbGx5LCB0aGUgUkZDIGNvdWxkIGFsc28ganVzdCBlc3RhYmxpc2ggdGhlIG5ldyBy ZWdpc3RyeSBhbmQgb2lkZiBjb3VsZCBmZWVsIGluIHRoZSB2YWx1ZXM/CgooanVzdCB0cnlpbmcg dG8gdW5kZXJzdGFuZCkKCi0tLS0tLS0tIE9yaWdpbmFsbmFjaHJpY2h0IC0tLS0tLS0tCkJldHJl ZmY6IFJFOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVz OiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKVm9uOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+CkFuOiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCxKb2huIEJyYWRs ZXkJIDx2ZTdqdGJAdmU3anRiLmNvbT4KQ2M6IG9hdXRoQGlldGYub3JnCgo+VGhlIGNvbnRleHQg dGhhdCBtb3N0IHBlb3BsZSBvbiB0aGlzIHRocmVhZCBwcm9iYWJseSBkb27igJl0IGhhdmUgaXMg dGhhdCBhbiBJQU5BIHJlZ2lzdHJ5IGNhbiBvbmx5IGJlIGVzdGFibGlzaGVkIGJ5IGFuIFJGQy4g IE5vbi1SRkMgc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgT3BlbklEIHNwZWNpZmljYXRpb25zLCBj YW4gKnJlZ2lzdGVyKiB2YWx1ZXMgaW4gYSByZWdpc3RyeSwgYnV0IHRoZXkgY2Fubm90ICplc3Rh Ymxpc2gqIGEgcmVnaXN0cnkuICBUaGUgT3BlbklEIEZvdW5kYXRpb24gaW5xdWlyZWQgYWJvdXQg dGhpcyB3aXRoIHRoZSBJRVRGIGJlZm9yZSBPcGVuSUQgQ29ubmVjdCB3YXMgZmluYWxpemVkIGFu ZCBsZWFybmVkIHRoYXQgaXRzIHNwZWNpZmljYXRpb25zIGNvdWxkIG5vdCBlc3RhYmxpc2ggSUFO QSByZWdpc3RyaWVzLiAgT3RoZXJ3aXNlLCB0aGV5IHdvdWxkIGhhdmUuCj4KPkluc3RlYWQsIFJG Q3MgbmVlZCB0byBiZSBjcmVhdGVkIHRvIGVzdGFibGlzaCByZWdpc3RyaWVzIOKAkyBldmVuIGZv ciB2YWx1ZXMgZmlyc3QgZGVmaW5lZCBpbiBub24tUkZDIHNwZWNpZmljYXRpb25zLiAgVGhpcyBz cGVjaWZpY2F0aW9uIGlzIG9uZSBleGFtcGxlIG9mIGRvaW5nIHRoaXMuCj4KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlCj4K PkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj5TZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTMsIDIw MTYgNjozNyBBTQo+VG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+Cj5DYzogb2F1 dGhAaWV0Zi5vcmcKPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhv ZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKPgo+Cj5XZSBj bGVhcmx5IGhhdmUgdGhpcyBwcm9ibGVtIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIEp1c3QgdGFr ZSBhIGxvb2sgYXQgdGhlIGRpc2NvdmVyeSB0aHJlYWQuCj4KPkFjY29yZGluZyB0byB5b3UgYXJn dW1lbnQgSSBzZWUgdHdvIG9wdGlvbnM6Cj4oMSkgYW1yIHN0YXlzIGFuIG9pZGMgY2xhaW0sIGlz IHVzZWQgaW4gb2lkYyBvbmx5IGFuZCB0aGUgb2F1dGggd2cganVzdCBwdWJsaXNoZXMgdGhlIHJl Z2lzdHJ5IGVudHJpZXMuIEluIHRoaXMgY2FzZSwgdGhlIHNwZWMgc2hvdWxkIGNsZWFybHkgZXhw bGFpbiB0aGlzLgo+KDIpIGFtciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoIChhbHRob3VnaCBpdCBo YXMgYmVlbiBpbnZlbnRlZCBpbiBvaWRjKSAtIHRoYW4gZGVmaW5lIGl0IGFuZCBtb3RpdmF0ZSBp dCdzIHVzZSBpbiBvYXV0aCBpbiB0aGlzIHNwZWMuCj4KPlJpZ2h0IG5vdywgSSB0aGluayBpdCBj cmVhdGVzIHRoZSBpbXByZXNzaW9uIG9hdXRoIGlzIGZvciBhdXRoZW50aWNhdGlvbi4KPgo+Cj4t LS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLQo+QmV0cmVmZjogUmU6IFtPQVVUSC1X R10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0 aW9uIEZpbmFsaXplZAo+Vm9uOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0 bzp2ZTdqdGJAdmU3anRiLmNvbT4+Cj5BbjogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pgo+Q2M6IHJvbGFuZC5oZWRiZXJnQHVtdS5zZSxvYXV0 aEBpZXRmLm9yZzxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlLG9hdXRoQGlldGYub3JnPgo+ Cj5UaGlzIGlzIG5vdCBhIGlzc3VlIGJldHdlZW4gb2F1dGggYW5kIE9JREMuCj4KPlRoaXMgaGFz IHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJ5IGZvciBKV1QgYmVpbmcgaW4gT0F1dGguICAgTWFueSBw cm90b2NvbHMgdGhhdCB1c2UgSldUIGFyZSBnb2luZyB0byB3YW50IHRvIHJlZ2lzdGVyIGNsYWlt cy4KPldlIGNhbuKAmXQgYXNrIHRoZW0gdG8gYWxsIG1vdmUgdGhlIHBhcnRzIG9mIHRoZXJlIHNw ZWNzIHRoYXQgdXNlIEpXVCB0byBPQXV0aC4KPgo+UGVyaGFwcyBKV1Qgc2hvdWxkIGhhdmUgYmVl biBwYXJ0IG9mIEpPU0UsIGJ1dCB0aGF0IGlzIHdhdGVyIHVuZGVyIHRoZSBicmlkZ2UuCj4KPlRo ZSBPQXV0aCBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMgcmVnaXN0cnksIGFu ZCB3ZSB3aWxsIG5lZWQgdG8gZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWltcy4KPgo+SSBndWVz cyB0aGF0IHdlIGNhbiB0ZWxsIHBlb3BsZSB0aGF0IHRoZXkgbmVlZCB0byBwdWJsaXNoIHRoZSBz cGVjcyBkZWZpbmluZyB0aGUgY2xhaW1zIHNvbWVwbGFjZSBlbHNlLCBhbmQganVzdCBkbyB0aGUg cmVnaXN0cnkgcGFydC4KPkhvd2V2ZXIgZG9pbmcgdGhhdCB3aWxsIHByb2JhYmx5IG5vdCBpbXBy b3ZlIGludGVyb3BlcmFiaWxpdHkgYW5kIHVuZGVyc3RhbmRpbmcuCj4KPlRoaXMgZG9jdW1lbnQg ZGVmaW5lcyB0aGUgY2xhaW0gZm9yIEpXVCBpbiBnZW5lcmFsLiAgV2Ugc3RpbGwgaGF2ZSBhbG1v c3Qgbm8gZG9jdW1lbnRhdGlvbiBpbiB0aGUgV0cgYWJvdXQgd2hhdCBhIEpXVCBhY2Nlc3MgdG9r ZW4gd291bGQgY29udGFpbiBvdGhlciB0aGFuIHRoZSBQT1Agd29yay4KPgo+Sm9obiBCLgo+T24g RmViIDEzLCAyMDE2LCBhdCA5OjE4IEFNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOgo+Cj5JIGJhc2ljYWxseSBzdXBwb3J0IGFk b3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIEFzc2VydGluZyBhdXRoZW50aWNhdGlvbiBtZXRob2Rz IGluIGFjY2VzcyB0b2tlbnMgKGluIHRoaXMgY2FzZSBpbiBKV1RTIGZvcm1hdCkgaXMgcmVhc29u YWJsZS4gV2UgdXNlIGl0IHRvIHBhc3MgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0 aW9uIHBlcmZvcm1lZCBwcmlvciBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgX3Jlc291 cmNlXyBzZXJ2ZXIuCj5XaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sgYW5kIGZvcnRoIGJldHdl ZW4gb2F1dGggYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5lZCBpbiBvaWRjICh3aGlj aCBzaXRzIG9uIHRvcCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBzcGVjaWZpZXMgdGhlIHJl Z2lzdHJ5PyBNb3Jlb3ZlciwgdGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBnaXZlIGEgcmF0aW9u YWxlIGZvciB1c2luZyBhbXIgaW4gY29udGV4dCBvZiBvYXV0aC4KPkFzIGEgV0cgd2UgbmVlZCB0 byBmaW5kIGEgY2xlYXIgZGVsaW5lYXRpb24gYmV0d2VlbiBib3RoIHByb3RvY29scywgb3RoZXJ3 aXNlIG5vb25lIHdpbGwgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYW5kIHdoZW4g dG8gdXNlIHdoYXQuIFdlIGNyZWF0ZSBjb25mdXNpb24hCj5Gb3IgdGhpcyBwYXJ0aWN1bGFyIGRy YWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1yIHRvIG9hdXRoIG9yIHRoZSByZWdpc3Ry eSB0byBvaWRjLgo+YmVzdCByZWdhcmRzLAo+VG9yc3Rlbi4KPgo+Cj4tLS0tLS0tLSBVcnNwcsO8 bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0KPlZvbjogUm9sYW5kIEhlZGJlcmcgPHJvbGFuZC5o ZWRiZXJnQHVtdS5zZTxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlPj4KPkdlc2VuZGV0OiBG cmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDA1OjQ1IFBNCj5Bbjogb2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPgo+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gQXV0aGVudGljYXRp b24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZAo+ KzEKPgo+PiAxMiBmZWIgMjAxNiBrbC4gMTY6NTggc2tyZXYgSm9obiBCcmFkbGV5IDx2ZTdqdGJA dmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoKPj4KPj4gKzEgdG8gYWRvcHQg dGhpcyBkcmFmdC4KPj4KPj4+IE9uIEZlYiAxMiwgMjAxNiwgYXQgMzowNyBBTSwgTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+PiB3cm90ZToKPj4+Cj4+PiBEcmFmdCAtMDUgaW5jb3Jwb3JhdGVzIHRoZSBmZWVk YmFjayBkZXNjcmliZWQgYmVsb3cgLSBkZWxldGluZyB0aGUgcmVxdWVzdCBwYXJhbWV0ZXIsIG5v dGluZyB0aGF0IHRoaXMgc3BlYyBpc24ndCBhbiBlbmNvdXJhZ2VtZW50IHRvIHVzZSBPQXV0aCAy LjAgZm9yIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgZW1wbG95aW5nIGFwcHJvcHJpYXRlIGV4dGVu c2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgSUFOQSBy ZWdpc3RyYXRpb24uICBJIGJlbGlldmUgdGhhdCBpdOKAmXMgbm93IHJlYWR5IGZvciB3b3JraW5n IGdyb3VwIGFkb3B0aW9uLgo+Pj4KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlCj4+Pgo+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0KPj4+IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnCj4+PiBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgNCwgMjAxNiAxMToyMyBBTQo+Pj4gVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4KPj4+IFN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9k IFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZAo+Pj4KPj4+IEhp IGFsbCwKPj4+Cj4+PiBPbiBKYW51YXJ5IDE5dGggSSBwb3N0ZWQgYSBjYWxsIGZvciBhZG9wdGlv biBvZiB0aGUgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgc3BlY2lmaWNh dGlvbiwgc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy ZW50L21zZzE1NDAyLmh0bWwKPj4+Cj4+PiBXaGF0IHN1cnByaXNlZCB1cyBpcyB0aGF0IHRoaXMg d29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmluZSBuZXcgY2xhaW1zIGFu ZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBhIGJpZyBkZWFsIGJ1dCB0 aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29oYW1hIElFVEYgbWVldGlu ZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhlIGxpc3Qgc2hvd3Mu IFRoZSBmZWVkYmFjayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBpdCBpcyBhIGJpdCBkaWZm aWN1bHQgZm9yIERlcmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vuc3VzLgo+Pj4KPj4+IExl dCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBvbiB0aGUgbGlzdC4K Pj4+Cj4+PiBJbiBoaXMgcmV2aWV3IGF0Cj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyMy5odG1sIEphbWVzIE1hbmdlciBhc2tzIGZv ciBzaWduaWZpY2FudCBjaGFuZ2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhlIHdhbnRzIHRvIHJl bW92ZSBvbmUgb2YgdGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxlZCByZXZpZXcgYW5k IGFjdGlvbmFibGUgaXRlbXMuCj4+Pgo+Pj4gV2lsbGlhbSBEZW5uaXNzIGJlbGlldmVzIHRoZSBk b2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0IGFncmVlcyB3aXRoIHNvbWUgb2YgdGhl IGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlzIHJldmlldzoKPj4+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDI2Lmh0bWwKPj4+ Cj4+PiBKdXN0aW4gaXMgY2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJvbmdlc3Qg b3Bpbmlvbi4gSGVyZSBpcyBvbmUgb2YgaGlzIHBvc3RzOgo+Pj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NTcuaHRtbAo+Pj4KPj4+IEFt b25nIGFsbCBjb25jZXJucyBKdXN0aW4gZXhwcmVzc2VkIHRoZSBmb2xsb3dpbmcgb25lIGlzIGFj dHVhbGx5IGFjdGlvbmFibGUgSU1ITzogSnVzdGluIGlzIHdvcnJpZWQgdGhhdCByZXBvcnRpbmcg aG93IGEgcGVyc29uIGF1dGhlbnRpY2F0ZWQgdG8gYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBh bmQgZW5jb3VyYWdpbmcgcGVvcGxlIHRvIHVzZSBPQXV0aCBmb3IgYXV0aGVudGljYXRpb24gaXMg YSBmaW5lIGxpbmUuIEhlIGJlbGlldmVzIHRoYXQgdGhpcyBkb2N1bWVudCBsZWFkcyByZWFkZXJz IHRvIGJlbGlldmUgdGhlIGxhdHRlci4KPj4+Cj4+PiBKb2huIGFncmVlcyB3aXRoIEp1c3RpbiBp bgo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMTU0NDguaHRtbCB0aGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgcGVvcGxlIGFyZSBu b3QgbWlzbGVhZCBhYm91dCB0aGUgaW50ZW50aW9uIG9mIHRoZSBkb2N1bWVudC4gSm9obiBhbHNv IHByb3ZpZGVzIGFkZGl0aW9uYWwgY29tbWVudHMgaW4gdGhpcyBwb3N0IHRvIHRoZQo+Pj4gbGlz dDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn MTU0NDEuaHRtbAo+Pj4gTW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGlu ZyB3b3JrLiBGb3IgZXhhbXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVs LAo+Pj4KPj4+IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9uIGJ1dCBoYXMg c29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2VzIG5vdCBwcm9w b3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZToKPj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDYyLmh0bWwKPj4+Cj4+ PiBXaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQg cmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdp dGhpbiB0aGUgc2NvcGUgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXpl ZCB0aGUgSldUIGluIHRoaXMgZ3JvdXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFu ZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzIGRy YWZ0cy4gTm90IHN0YW5kYXJkaXppbmcgSldUIGluIHRoZSBJRVRGIHdvdWxkIGhhdmUgbGVhZCB0 byByZWR1Y2VkIGludGVyb3BlcmFiaWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHkuIEkgaGF2ZSBubyBk b3VidHMgdGhhdCB3YXMgYSB3cm9uZyBkZWNpc2lvbi4KPj4+Cj4+PiBJbiBpdHMgY3VycmVudCBm b3JtLCB0aGVyZSBpcyBub3QgZW5vdWdoIHN1cHBvcnQgdG8gaGF2ZSB0aGlzIGRvY3VtZW50IGFz IGEgV0cgaXRlbS4KPj4+Cj4+PiBXZSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGF1dGhvcnMg c2hvdWxkIGFkZHJlc3Mgc29tZSBvZiB0aGUgZWFzaWVyIGNvbW1lbnRzIGFuZCBzdWJtaXQgYSBu ZXcgdmVyc2lvbi4gVGhpcyB3b3VsZCBhbGxvdyB1cyB0byByZWFjaCBvdXQgdG8gdGhvc2Ugd2hv IGhhZCBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0 byByZS1ldmFsdWF0ZSB0aGVpciBkZWNpc2lvbi4gQSBuZXcgZHJhZnQgdmVyc2lvbiBzaG91bGQg YXQgbGVhc3QgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3VlczoKPj4+Cj4+PiAqIENsYXJpZnkg dGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJhZ2VtZW50IGZvciB1c2luZyBPQXV0 aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3Vs ZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSBKdXN0aW4gYW5kIEpvaG4u Cj4+Pgo+Pj4gKiBDaGFuZ2UgdGhlIHJlZ2lzdHJ5IHBvbGljeSwgd2hpY2ggd291bGQgYWRkcmVz cyBvbmUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMsIFdpbGxpYW0sIGFuZCBQaGlsLgo+Pj4K Pj4+IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9uIHNpbmNlIHRoZXkgYXJl IG1vcmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBKb2huIG5vdGVkIHRoYXQg aGUgZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1ldGVycy4gVW5mb3J0dW5h dGVseSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpvaG4gdG8gcHJvdmlkZSBh biBhbHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUgaXMgb25lLiBBbHNvLCB0aGUgcmVtYXJr IHRoYXQgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291bGQgYmUgY291bnRlcmVkIHdpdGgg YW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwuIEphbWVzIHdhbnRlZCB0byByZW1vdmUgdGhlICJhbXJf dmFsdWVzIiBwYXJhbWV0ZXIuCj4+PiBJcyB0aGlzIHdoYXQgb3RoZXJzIHdhbnQgYXMgd2VsbD8K Pj4+Cj4+PiBBZnRlciB0aGVzZSBpdGVtcyBoYXZlIGJlZW4gYWRkcmVzc2VkIHdlIGJlbGlldmUg dGhhdCBtb3JlIGZvbGtzIGluIHRoZSBncm91cCB3aWxsIHN1cHBvcnQgdGhlIGRvY3VtZW50Lgo+ Pj4KPj4+IENpYW8KPj4+IEhhbm5lcyAmIERlcmVrCj4+Pgo+Pj4KPj4+Cj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gT0F1dGggbWFpbGluZyBs aXN0Cj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Cj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPgo+4oCUIFJvbGFuZAo+Cj7igJ1FdmVyeWJv ZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIgo+RnJv bSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEtyYXVzcwo+Cj4KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5PQXV0aCBtYWls aW5nIGxpc3QKPk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj5PQXV0aCBtYWlsaW5nIGxpc3QKPk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgKPgo+ ----_com.syntomo.email_804275889143071 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPlNvIGJhc2ljYWxseSwgdGhlIFJGQyBjb3VsZCBhbHNvIGp1c3QgZXN0YWJs aXNoIHRoZSBuZXcgcmVnaXN0cnkgYW5kIG9pZGYgY291bGQgZmVlbCBpbiB0aGUgdmFsdWVzPzwv cD4KPHAgZGlyPSJsdHIiPihqdXN0IHRyeWluZyB0byB1bmRlcnN0YW5kKTwvcD4KPGJyPjxicj4t LS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLTxicj5CZXRyZWZmOiBSRTogW09BVVRI LVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRv cHRpb24gRmluYWxpemVkPGJyPlZvbjogTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tJmd0Ozxicj5BbjogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQsSm9obiBCcmFkbGV5 CSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPkNjOiBvYXV0aEBpZXRmLm9yZzxicj48YnI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBjb250ZXh0IHRoYXQgbW9zdCBwZW9wbGUgb24g dGhpcyB0aHJlYWQgcHJvYmFibHkgZG9u4oCZdCBoYXZlIGlzIHRoYXQgYW4gSUFOQSByZWdpc3Ry eSBjYW4gb25seSBiZSBlc3RhYmxpc2hlZCBieSBhbiBSRkMuJm5ic3A7IE5vbi1SRkMgc3BlY2lm aWNhdGlvbnMsIHN1Y2ggYXMgT3BlbklEDQogc3BlY2lmaWNhdGlvbnMsIGNhbiAqPGI+cmVnaXN0 ZXI8L2I+KiB2YWx1ZXMgaW4gYSByZWdpc3RyeSwgYnV0IHRoZXkgY2Fubm90ICo8Yj5lc3RhYmxp c2g8L2I+KiBhIHJlZ2lzdHJ5LiZuYnNwOyBUaGUgT3BlbklEIEZvdW5kYXRpb24gaW5xdWlyZWQg YWJvdXQgdGhpcyB3aXRoIHRoZSBJRVRGIGJlZm9yZSBPcGVuSUQgQ29ubmVjdCB3YXMgZmluYWxp emVkIGFuZCBsZWFybmVkIHRoYXQgaXRzIHNwZWNpZmljYXRpb25zIGNvdWxkIG5vdCBlc3RhYmxp c2gNCiBJQU5BIHJlZ2lzdHJpZXMuJm5ic3A7IE90aGVyd2lzZSwgdGhleSB3b3VsZCBoYXZlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SW5zdGVhZCwgUkZDcyBu ZWVkIHRvIGJlIGNyZWF0ZWQgdG8gZXN0YWJsaXNoIHJlZ2lzdHJpZXMg4oCTIGV2ZW4gZm9yIHZh bHVlcyBmaXJzdCBkZWZpbmVkIGluIG5vbi1SRkMgc3BlY2lmaWNhdGlvbnMuJm5ic3A7IFRoaXMg c3BlY2lmaWNhdGlvbiBpcyBvbmUgZXhhbXBsZSBvZiBkb2luZw0KIHRoaXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxicj4NCjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgRmVicnVhcnkgMTMsIDIwMTYgNjozNyBBTTxicj4NCjxiPlRvOjwvYj4g Sm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9h dXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRp Y2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6 ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwPldlIGNsZWFybHkgaGF2ZSB0aGlzIHByb2JsZW0gYmV0d2VlbiBvYXV0 aCBhbmQgb2lkYy4gSnVzdCB0YWtlIGEgbG9vayBhdCB0aGUgZGlzY292ZXJ5IHRocmVhZC48bzpw PjwvbzpwPjwvcD4NCjxwPkFjY29yZGluZyB0byB5b3UgYXJndW1lbnQgSSBzZWUgdHdvIG9wdGlv bnM6PGJyPg0KKDEpIGFtciBzdGF5cyBhbiBvaWRjIGNsYWltLCBpcyB1c2VkIGluIG9pZGMgb25s eSBhbmQgdGhlIG9hdXRoIHdnIGp1c3QgcHVibGlzaGVzIHRoZSByZWdpc3RyeSBlbnRyaWVzLiBJ biB0aGlzIGNhc2UsIHRoZSBzcGVjIHNob3VsZCBjbGVhcmx5IGV4cGxhaW4gdGhpcy48YnI+DQoo MikgYW1yIGlzIG9mIGFueSB1c2UgaW4gb2F1dGggKGFsdGhvdWdoIGl0IGhhcyBiZWVuIGludmVu dGVkIGluIG9pZGMpIC0gdGhhbiBkZWZpbmUgaXQgYW5kIG1vdGl2YXRlIGl0J3MgdXNlIGluIG9h dXRoIGluIHRoaXMgc3BlYy4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+UmlnaHQgbm93LCBJIHRoaW5r IGl0IGNyZWF0ZXMgdGhlIGltcHJlc3Npb24gb2F1dGggaXMgZm9yIGF1dGhlbnRpY2F0aW9uLiA8 bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0tLS0t LS0gT3JpZ2luYWxuYWNocmljaHQgLS0tLS0tLS08YnI+DQpCZXRyZWZmOiBSZTogW09BVVRILVdH XSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRp b24gRmluYWxpemVkPGJyPg0KVm9uOiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCkFuOiA8YSBo cmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlLG9h dXRoQGlldGYub3JnIj5yb2xhbmQuaGVkYmVyZ0B1bXUuc2Usb2F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGJyPg0KVGhpcyBpcyBub3QgYSBpc3N1ZSBiZXR3ZWVuIG9hdXRoIGFuZCBPSURDLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBoYXMgdG8gZG8g d2l0aCB0aGUgcmVnaXN0cnkgZm9yIEpXVCBiZWluZyBpbiBPQXV0aC4gJm5ic3A7IE1hbnkgcHJv dG9jb2xzIHRoYXQgdXNlIEpXVCBhcmUgZ29pbmcgdG8gd2FudCB0byByZWdpc3RlciBjbGFpbXMu ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2UgY2Fu4oCZdCBhc2sgdGhlbSB0byBhbGwgbW92ZSB0aGUgcGFydHMgb2YgdGhlcmUgc3Bl Y3MgdGhhdCB1c2UgSldUIHRvIE9BdXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIEpXVCBzaG91bGQgaGF2ZSBiZWVuIHBhcnQg b2YgSk9TRSwgYnV0IHRoYXQgaXMgd2F0ZXIgdW5kZXIgdGhlIGJyaWRnZS4gJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPQXV0 aCBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMgcmVnaXN0cnksIGFuZCB3ZSB3 aWxsIG5lZWQgdG8gZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWltcy4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhh dCB3ZSBjYW4gdGVsbCBwZW9wbGUgdGhhdCB0aGV5IG5lZWQgdG8gcHVibGlzaCB0aGUgc3BlY3Mg ZGVmaW5pbmcgdGhlIGNsYWltcyBzb21lcGxhY2UgZWxzZSwgYW5kIGp1c3QgZG8gdGhlIHJlZ2lz dHJ5IHBhcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ib3dldmVyIGRvaW5nIHRoYXQgd2lsbCBwcm9iYWJseSBub3QgaW1wcm92ZSBpbnRlcm9w ZXJhYmlsaXR5IGFuZCB1bmRlcnN0YW5kaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGNsYWlt IGZvciBKV1QgaW4gZ2VuZXJhbC4gJm5ic3A7V2Ugc3RpbGwgaGF2ZSBhbG1vc3Qgbm8gZG9jdW1l bnRhdGlvbiBpbiB0aGUgV0cgYWJvdXQgd2hhdCBhIEpXVCBhY2Nlc3MgdG9rZW4gd291bGQgY29u dGFpbiBvdGhlciB0aGFuIHRoZSBQT1Agd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAxMywgMjAxNiwgYXQgOToxOCBB TSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij4NCnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGJhc2ljYWxseSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIEFz c2VydGluZyBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGluIGFjY2VzcyB0b2tlbnMgKGluIHRoaXMg Y2FzZSBpbiBKV1RTIGZvcm1hdCkgaXMgcmVhc29uYWJsZS4gV2UgdXNlIGl0IHRvIHBhc3MgaW5m b3JtYXRpb24gYWJvdXQNCiB0aGUgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIHByaW9yIGlzc3Vp bmcgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfIHNlcnZlci4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sg YW5kIGZvcnRoIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5l ZCBpbiBvaWRjICh3aGljaCBzaXRzIG9uIHRvcCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBz cGVjaWZpZXMgdGhlIHJlZ2lzdHJ5PyBNb3Jlb3ZlciwgdGhlDQogY3VycmVudCB0ZXh0IGRvZXMg bm90IGdpdmUgYSByYXRpb25hbGUgZm9yIHVzaW5nIGFtciBpbiBjb250ZXh0IG9mIG9hdXRoLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBhIFdHIHdlIG5lZWQgdG8g ZmluZCBhIGNsZWFyIGRlbGluZWF0aW9uIGJldHdlZW4gYm90aCBwcm90b2NvbHMsIG90aGVyd2lz ZSBub29uZSB3aWxsIHJlYWxseSB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGFuZCB3aGVuIHRv IHVzZSB3aGF0LiBXZSBjcmVhdGUgY29uZnVzaW9uIQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkZvciB0aGlzIHBhcnRpY3VsYXIgZHJhZnQgdGhpcyBtZWFucyB0byBl aXRoZXIgbW92ZSBhbXIgdG8gb2F1dGggb3IgdGhlIHJlZ2lzdHJ5IHRvIG9pZGMuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YmVzdCByZWdhcmRzLA0KPGJyPg0KVG9y c3Rlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0IC0tLS0tLS0tPGJyPg0KVm9uOiBSb2xhbmQgSGVkYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvbGFuZC5oZWRiZXJnQHVtdS5zZSI+cm9sYW5kLmhlZGJlcmdAdW11LnNlPC9hPiZndDs8YnI+ DQpHZXNlbmRldDogRnJpZGF5LCBGZWJydWFyeSAxMiwgMjAxNiAwNTo0NSBQTTxicj4NCkFuOiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCkJl dHJlZmY6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFs dWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+JiM0MzsxPGJyPg0KPGJyPg0KJmd0OyAxMiBmZWIgMjAxNiBrbC4gMTY6 NTggc2tyZXYgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5j b20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICYjNDM7 MSB0byBhZG9wdCB0aGlzIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgT24gRmViIDEy LCAyMDE2LCBhdCAzOjA3IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBEcmFmdCAtMDUgaW5jb3Jwb3Jh dGVzIHRoZSBmZWVkYmFjayBkZXNjcmliZWQgYmVsb3cgLSBkZWxldGluZyB0aGUgcmVxdWVzdCBw YXJhbWV0ZXIsIG5vdGluZyB0aGF0IHRoaXMgc3BlYyBpc24ndCBhbiBlbmNvdXJhZ2VtZW50IHRv IHVzZSBPQXV0aCAyLjAgZm9yIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgZW1wbG95aW5nIGFwcHJv cHJpYXRlIGV4dGVuc2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlv biBmb3IgSUFOQQ0KIHJlZ2lzdHJhdGlvbi4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgaXTigJlzIG5v dyByZWFkeSBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBPQXV0aCBbPGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnPC9hPl0gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KJmd0OyZndDsgU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgMTE6MjMgQU08YnI+DQomZ3Q7Jmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7Jmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQ8YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gSmFudWFy eSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlIEF1dGhlbnRpY2F0aW9u IE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRpb24sIHNlZQ0KPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MDIu aHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMTU0MDIuaHRtbDwvYT48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBXaGF0IHN1cnBy aXNlZCB1cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdl IGRlZmluZSBuZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMu IE5vdCBhIGJpZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhl IFlva29oYW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRp b24gb24gdGhlIGxpc3Qgc2hvd3MuDQogVGhlIGZlZWRiYWNrIGxlYWQgdG8gbWl4ZWQgZmVlbGlu Z3MgYW5kIGl0IGlzIGEgYml0IGRpZmZpY3VsdCBmb3IgRGVyZWsgYW5kIG15c2VsZiB0byBqdWRn ZSBjb25zZW5zdXMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgTGV0IG1lIHRlbGwgeW91 IHdoYXQgd2Ugc2VlIGZyb20gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0Ljxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IEluIGhpcyByZXZpZXcgYXQ8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQy My5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cxNTQyMy5odG1sPC9hPiBKYW1lcyBNYW5nZXIgYXNrcyBmb3Igc2lnbmlmaWNhbnQgY2hh bmdlcy4gQW1vbmcgb3RoZXIgdGhpbmdzLCBoZSB3YW50cyB0byByZW1vdmUgb25lIG9mIHRoZSBj bGFpbXMuIEhlIHByb3ZpZGVzDQogYSBkZXRhaWxlZCByZXZpZXcgYW5kIGFjdGlvbmFibGUgaXRl bXMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgV2lsbGlhbSBEZW5uaXNzIGJlbGlldmVz IHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0IGFncmVlcyB3aXRoIHNvbWUg b2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlzIHJldmlldzo8YnI+DQomZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQyNi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyNi5odG1sPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IEp1c3RpbiBpcyBjZXJ0YWlubHkgdGhlIHJldmlld2VyIHdpdGggdGhlIHN0cm9uZ2Vz dCBvcGluaW9uLiBIZXJlIGlzIG9uZSBvZiBoaXMgcG9zdHM6PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn MTU0NTcuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTU0NTcuaHRtbDwvYT48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBbW9u ZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5nIG9uZSBpcyBhY3R1 YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQgcmVwb3J0aW5nIGhv dyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5k IGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRpY2F0aW9uIGlzIGEg ZmluZSBsaW5lLiBIZSBiZWxpZXZlcw0KIHRoYXQgdGhpcyBkb2N1bWVudCBsZWFkcyByZWFkZXJz IHRvIGJlbGlldmUgdGhlIGxhdHRlci48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBKb2hu IGFncmVlcyB3aXRoIEp1c3RpbiBpbjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQ4Lmh0bWwiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQ4 Lmh0bWw8L2E+IHRoYXQgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9wbGUgYXJlIG5vdCBt aXNsZWFkIGFib3V0IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBKb2huIGFsc28gcHJv dmlkZXMNCiBhZGRpdGlvbmFsIGNvbW1lbnRzIGluIHRoaXMgcG9zdCB0byB0aGU8YnI+DQomZ3Q7 Jmd0OyBsaXN0OiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWw8L2E+PGJyPg0KJmd0OyZndDsg TW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGluZyB3b3JrLiBGb3IgZXhh bXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVsLDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9uIGJ1 dCBoYXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2VzIG5v dCBwcm9wb3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZTo8YnI+DQomZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQ2Mi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTQ2Mi5odG1sPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7IFdpdGggbXkgY28tY2hhaXIgaGF0IG9uOiBJIGp1c3Qgd2FudGVkIHRvIGNsYXJpZnkgdGhh dCByZWdpc3RlcmluZyBjbGFpbXMgKGFuZCB2YWx1ZXMgd2l0aGluIHRob3NlIGNsYWltcykgaXMg d2l0aGluIHRoZSBzY29wZSBvZiB0aGUgT0F1dGggd29ya2luZyBncm91cC4gV2Ugc3RhbmRhcmRp emVkIHRoZSBKV1QgaW4gdGhpcyBncm91cCBhbmQgd2UgYXJlIGFsc28gY2hhcnRlcmVkIHRvIHN0 YW5kYXJkaXplIGNsYWltcywgYXMgd2UgYXJlIGN1cnJlbnRseQ0KIGRvaW5nIHdpdGggdmFyaW91 cyBkcmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBpbiB0aGUgSUVURiB3b3VsZCBoYXZlIGxl YWQgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCBsZXNzIHNlY3VyaXR5LiBJIGhhdmUg bm8gZG91YnRzIHRoYXQgd2FzIGEgd3JvbmcgZGVjaXNpb24uPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgSW4gaXRzIGN1cnJlbnQgZm9ybSwgdGhlcmUgaXMgbm90IGVub3VnaCBzdXBwb3J0 IHRvIGhhdmUgdGhpcyBkb2N1bWVudCBhcyBhIFdHIGl0ZW0uPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgV2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBhdXRob3JzIHNob3VsZCBhZGRy ZXNzIHNvbWUgb2YgdGhlIGVhc2llciBjb21tZW50cyBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24u IFRoaXMgd291bGQgYWxsb3cgdXMgdG8gcmVhY2ggb3V0IHRvIHRob3NlIHdobyBoYWQgZXhwcmVz c2VkIGNvbmNlcm5zIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVh dGUgdGhlaXIgZGVjaXNpb24uIEEgbmV3IGRyYWZ0IHZlcnNpb24NCiBzaG91bGQgYXQgbGVhc3Qg YWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3Vlczo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyAqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJhZ2VtZW50IGZv ciB1c2luZyBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRo YXQgdGhpcyB3b3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSBKdXN0 aW4gYW5kIEpvaG4uPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgKiBDaGFuZ2UgdGhlIHJl Z2lzdHJ5IHBvbGljeSwgd2hpY2ggd291bGQgYWRkcmVzcyBvbmUgb2YgdGhlIGNvbW1lbnRzIGZy b20gSmFtZXMsIFdpbGxpYW0sIGFuZCBQaGlsLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9uIHNpbmNlIHRoZXkgYXJlIG1v cmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBKb2huIG5vdGVkIHRoYXQgaGUg ZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1ldGVycy4gVW5mb3J0dW5hdGVs eSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpvaG4gdG8gcHJvdmlkZSBhbiBh bHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUNCiBpcyBvbmUuIEFsc28sIHRoZSByZW1hcmsg dGhhdCB0aGUgdmFsdWVzIGFyZSBtZWFuaW5nbGVzcyBjb3VsZCBiZSBjb3VudGVyZWQgd2l0aCBh biBhbHRlcm5hdGl2ZSBwcm9wb3NhbC4gSmFtZXMgd2FudGVkIHRvIHJlbW92ZSB0aGUgJnF1b3Q7 YW1yX3ZhbHVlcyZxdW90OyBwYXJhbWV0ZXIuPGJyPg0KJmd0OyZndDsgSXMgdGhpcyB3aGF0IG90 aGVycyB3YW50IGFzIHdlbGw/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQWZ0ZXIgdGhl c2UgaXRlbXMgaGF2ZSBiZWVuIGFkZHJlc3NlZCB3ZSBiZWxpZXZlIHRoYXQgbW9yZSBmb2xrcyBp biB0aGUgZ3JvdXAgd2lsbCBzdXBwb3J0IHRoZSBkb2N1bWVudC48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBDaWFvPGJyPg0KJmd0OyZndDsgSGFubmVzICZhbXA7IERlcmVrPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxicj4NCjxicj4NCuKAlCBSb2xhbmQ8YnI+DQo8YnI+DQrigJ1FdmVyeWJv ZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uJnF1b3Q7 PGJyPg0KRnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEtyYXVz czxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0K ----_com.syntomo.email_804275889143071-- From nobody Sat Feb 13 07:59:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FCA1A028A for ; Sat, 13 Feb 2016 07:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29U1Tw33NNx3 for ; Sat, 13 Feb 2016 07:59:26 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8F01A02BE for ; Sat, 13 Feb 2016 07:59:25 -0800 (PST) Received: from [80.187.110.214] (helo=[10.149.145.182]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aUcZq-0003SO-BK; Sat, 13 Feb 2016 16:57:43 +0100 Date: Sat, 13 Feb 2016 16:59:18 +0100 Message-ID: In-Reply-To: References: From: "torsten@lodderstedt.net" To: Michael.Jones@microsoft.com, John Bradley MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_804268952544320" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 15:59:31 -0000 ----_com.syntomo.email_804268952544320 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U28gYmFzaWNhbGx5LCB0aGUgUkZDIGNvdWxkIGFsc28ganVzdCBlc3RhYmxpc2ggdGhlIG5ldyBy ZWdpc3RyeSBhbmQgb2lkZiBjb3VsZCBmZWVsIGluIHRoZSB2YWx1ZXM/CgooanVzdCB0cnlpbmcg dG8gdW5kZXJzdGFuZCkKCi0tLS0tLS0tIE9yaWdpbmFsbmFjaHJpY2h0IC0tLS0tLS0tCkJldHJl ZmY6IFJFOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVz OiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKVm9uOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+CkFuOiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCxKb2huIEJyYWRs ZXkJIDx2ZTdqdGJAdmU3anRiLmNvbT4KQ2M6IG9hdXRoQGlldGYub3JnCgo+VGhlIGNvbnRleHQg dGhhdCBtb3N0IHBlb3BsZSBvbiB0aGlzIHRocmVhZCBwcm9iYWJseSBkb27igJl0IGhhdmUgaXMg dGhhdCBhbiBJQU5BIHJlZ2lzdHJ5IGNhbiBvbmx5IGJlIGVzdGFibGlzaGVkIGJ5IGFuIFJGQy4g IE5vbi1SRkMgc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgT3BlbklEIHNwZWNpZmljYXRpb25zLCBj YW4gKnJlZ2lzdGVyKiB2YWx1ZXMgaW4gYSByZWdpc3RyeSwgYnV0IHRoZXkgY2Fubm90ICplc3Rh Ymxpc2gqIGEgcmVnaXN0cnkuICBUaGUgT3BlbklEIEZvdW5kYXRpb24gaW5xdWlyZWQgYWJvdXQg dGhpcyB3aXRoIHRoZSBJRVRGIGJlZm9yZSBPcGVuSUQgQ29ubmVjdCB3YXMgZmluYWxpemVkIGFu ZCBsZWFybmVkIHRoYXQgaXRzIHNwZWNpZmljYXRpb25zIGNvdWxkIG5vdCBlc3RhYmxpc2ggSUFO QSByZWdpc3RyaWVzLiAgT3RoZXJ3aXNlLCB0aGV5IHdvdWxkIGhhdmUuCj4KPkluc3RlYWQsIFJG Q3MgbmVlZCB0byBiZSBjcmVhdGVkIHRvIGVzdGFibGlzaCByZWdpc3RyaWVzIOKAkyBldmVuIGZv ciB2YWx1ZXMgZmlyc3QgZGVmaW5lZCBpbiBub24tUkZDIHNwZWNpZmljYXRpb25zLiAgVGhpcyBz cGVjaWZpY2F0aW9uIGlzIG9uZSBleGFtcGxlIG9mIGRvaW5nIHRoaXMuCj4KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlCj4K PkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj5TZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMTMsIDIw MTYgNjozNyBBTQo+VG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+Cj5DYzogb2F1 dGhAaWV0Zi5vcmcKPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhv ZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKPgo+Cj5XZSBj bGVhcmx5IGhhdmUgdGhpcyBwcm9ibGVtIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIEp1c3QgdGFr ZSBhIGxvb2sgYXQgdGhlIGRpc2NvdmVyeSB0aHJlYWQuCj4KPkFjY29yZGluZyB0byB5b3UgYXJn dW1lbnQgSSBzZWUgdHdvIG9wdGlvbnM6Cj4oMSkgYW1yIHN0YXlzIGFuIG9pZGMgY2xhaW0sIGlz IHVzZWQgaW4gb2lkYyBvbmx5IGFuZCB0aGUgb2F1dGggd2cganVzdCBwdWJsaXNoZXMgdGhlIHJl Z2lzdHJ5IGVudHJpZXMuIEluIHRoaXMgY2FzZSwgdGhlIHNwZWMgc2hvdWxkIGNsZWFybHkgZXhw bGFpbiB0aGlzLgo+KDIpIGFtciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoIChhbHRob3VnaCBpdCBo YXMgYmVlbiBpbnZlbnRlZCBpbiBvaWRjKSAtIHRoYW4gZGVmaW5lIGl0IGFuZCBtb3RpdmF0ZSBp dCdzIHVzZSBpbiBvYXV0aCBpbiB0aGlzIHNwZWMuCj4KPlJpZ2h0IG5vdywgSSB0aGluayBpdCBj cmVhdGVzIHRoZSBpbXByZXNzaW9uIG9hdXRoIGlzIGZvciBhdXRoZW50aWNhdGlvbi4KPgo+Cj4t LS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLQo+QmV0cmVmZjogUmU6IFtPQVVUSC1X R10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0 aW9uIEZpbmFsaXplZAo+Vm9uOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0 bzp2ZTdqdGJAdmU3anRiLmNvbT4+Cj5BbjogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pgo+Q2M6IHJvbGFuZC5oZWRiZXJnQHVtdS5zZSxvYXV0 aEBpZXRmLm9yZzxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlLG9hdXRoQGlldGYub3JnPgo+ Cj5UaGlzIGlzIG5vdCBhIGlzc3VlIGJldHdlZW4gb2F1dGggYW5kIE9JREMuCj4KPlRoaXMgaGFz IHRvIGRvIHdpdGggdGhlIHJlZ2lzdHJ5IGZvciBKV1QgYmVpbmcgaW4gT0F1dGguICAgTWFueSBw cm90b2NvbHMgdGhhdCB1c2UgSldUIGFyZSBnb2luZyB0byB3YW50IHRvIHJlZ2lzdGVyIGNsYWlt cy4KPldlIGNhbuKAmXQgYXNrIHRoZW0gdG8gYWxsIG1vdmUgdGhlIHBhcnRzIG9mIHRoZXJlIHNw ZWNzIHRoYXQgdXNlIEpXVCB0byBPQXV0aC4KPgo+UGVyaGFwcyBKV1Qgc2hvdWxkIGhhdmUgYmVl biBwYXJ0IG9mIEpPU0UsIGJ1dCB0aGF0IGlzIHdhdGVyIHVuZGVyIHRoZSBicmlkZ2UuCj4KPlRo ZSBPQXV0aCBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMgcmVnaXN0cnksIGFu ZCB3ZSB3aWxsIG5lZWQgdG8gZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWltcy4KPgo+SSBndWVz cyB0aGF0IHdlIGNhbiB0ZWxsIHBlb3BsZSB0aGF0IHRoZXkgbmVlZCB0byBwdWJsaXNoIHRoZSBz cGVjcyBkZWZpbmluZyB0aGUgY2xhaW1zIHNvbWVwbGFjZSBlbHNlLCBhbmQganVzdCBkbyB0aGUg cmVnaXN0cnkgcGFydC4KPkhvd2V2ZXIgZG9pbmcgdGhhdCB3aWxsIHByb2JhYmx5IG5vdCBpbXBy b3ZlIGludGVyb3BlcmFiaWxpdHkgYW5kIHVuZGVyc3RhbmRpbmcuCj4KPlRoaXMgZG9jdW1lbnQg ZGVmaW5lcyB0aGUgY2xhaW0gZm9yIEpXVCBpbiBnZW5lcmFsLiAgV2Ugc3RpbGwgaGF2ZSBhbG1v c3Qgbm8gZG9jdW1lbnRhdGlvbiBpbiB0aGUgV0cgYWJvdXQgd2hhdCBhIEpXVCBhY2Nlc3MgdG9r ZW4gd291bGQgY29udGFpbiBvdGhlciB0aGFuIHRoZSBQT1Agd29yay4KPgo+Sm9obiBCLgo+T24g RmViIDEzLCAyMDE2LCBhdCA5OjE4IEFNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOgo+Cj5JIGJhc2ljYWxseSBzdXBwb3J0IGFk b3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIEFzc2VydGluZyBhdXRoZW50aWNhdGlvbiBtZXRob2Rz IGluIGFjY2VzcyB0b2tlbnMgKGluIHRoaXMgY2FzZSBpbiBKV1RTIGZvcm1hdCkgaXMgcmVhc29u YWJsZS4gV2UgdXNlIGl0IHRvIHBhc3MgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0 aW9uIHBlcmZvcm1lZCBwcmlvciBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgX3Jlc291 cmNlXyBzZXJ2ZXIuCj5XaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sgYW5kIGZvcnRoIGJldHdl ZW4gb2F1dGggYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5lZCBpbiBvaWRjICh3aGlj aCBzaXRzIG9uIHRvcCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBzcGVjaWZpZXMgdGhlIHJl Z2lzdHJ5PyBNb3Jlb3ZlciwgdGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBnaXZlIGEgcmF0aW9u YWxlIGZvciB1c2luZyBhbXIgaW4gY29udGV4dCBvZiBvYXV0aC4KPkFzIGEgV0cgd2UgbmVlZCB0 byBmaW5kIGEgY2xlYXIgZGVsaW5lYXRpb24gYmV0d2VlbiBib3RoIHByb3RvY29scywgb3RoZXJ3 aXNlIG5vb25lIHdpbGwgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYW5kIHdoZW4g dG8gdXNlIHdoYXQuIFdlIGNyZWF0ZSBjb25mdXNpb24hCj5Gb3IgdGhpcyBwYXJ0aWN1bGFyIGRy YWZ0IHRoaXMgbWVhbnMgdG8gZWl0aGVyIG1vdmUgYW1yIHRvIG9hdXRoIG9yIHRoZSByZWdpc3Ry eSB0byBvaWRjLgo+YmVzdCByZWdhcmRzLAo+VG9yc3Rlbi4KPgo+Cj4tLS0tLS0tLSBVcnNwcsO8 bmdsaWNoZSBOYWNocmljaHQgLS0tLS0tLS0KPlZvbjogUm9sYW5kIEhlZGJlcmcgPHJvbGFuZC5o ZWRiZXJnQHVtdS5zZTxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlPj4KPkdlc2VuZGV0OiBG cmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDA1OjQ1IFBNCj5Bbjogb2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPgo+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gQXV0aGVudGljYXRp b24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZAo+ KzEKPgo+PiAxMiBmZWIgMjAxNiBrbC4gMTY6NTggc2tyZXYgSm9obiBCcmFkbGV5IDx2ZTdqdGJA dmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoKPj4KPj4gKzEgdG8gYWRvcHQg dGhpcyBkcmFmdC4KPj4KPj4+IE9uIEZlYiAxMiwgMjAxNiwgYXQgMzowNyBBTSwgTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+PiB3cm90ZToKPj4+Cj4+PiBEcmFmdCAtMDUgaW5jb3Jwb3JhdGVzIHRoZSBmZWVk YmFjayBkZXNjcmliZWQgYmVsb3cgLSBkZWxldGluZyB0aGUgcmVxdWVzdCBwYXJhbWV0ZXIsIG5v dGluZyB0aGF0IHRoaXMgc3BlYyBpc24ndCBhbiBlbmNvdXJhZ2VtZW50IHRvIHVzZSBPQXV0aCAy LjAgZm9yIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgZW1wbG95aW5nIGFwcHJvcHJpYXRlIGV4dGVu c2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgSUFOQSBy ZWdpc3RyYXRpb24uICBJIGJlbGlldmUgdGhhdCBpdOKAmXMgbm93IHJlYWR5IGZvciB3b3JraW5n IGdyb3VwIGFkb3B0aW9uLgo+Pj4KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlCj4+Pgo+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0KPj4+IEZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnCj4+PiBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgNCwgMjAxNiAxMToyMyBBTQo+Pj4gVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4KPj4+IFN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9k IFJlZmVyZW5jZSBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZAo+Pj4KPj4+IEhp IGFsbCwKPj4+Cj4+PiBPbiBKYW51YXJ5IDE5dGggSSBwb3N0ZWQgYSBjYWxsIGZvciBhZG9wdGlv biBvZiB0aGUgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1ZXMgc3BlY2lmaWNh dGlvbiwgc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy ZW50L21zZzE1NDAyLmh0bWwKPj4+Cj4+PiBXaGF0IHN1cnByaXNlZCB1cyBpcyB0aGF0IHRoaXMg d29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdlIGRlZmluZSBuZXcgY2xhaW1zIGFu ZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMuIE5vdCBhIGJpZyBkZWFsIGJ1dCB0 aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFlva29oYW1hIElFVEYgbWVldGlu ZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhlIGxpc3Qgc2hvd3Mu IFRoZSBmZWVkYmFjayBsZWFkIHRvIG1peGVkIGZlZWxpbmdzIGFuZCBpdCBpcyBhIGJpdCBkaWZm aWN1bHQgZm9yIERlcmVrIGFuZCBteXNlbGYgdG8ganVkZ2UgY29uc2Vuc3VzLgo+Pj4KPj4+IExl dCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9tIHRoZSBjb21tZW50cyBvbiB0aGUgbGlzdC4K Pj4+Cj4+PiBJbiBoaXMgcmV2aWV3IGF0Cj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyMy5odG1sIEphbWVzIE1hbmdlciBhc2tzIGZv ciBzaWduaWZpY2FudCBjaGFuZ2VzLiBBbW9uZyBvdGhlciB0aGluZ3MsIGhlIHdhbnRzIHRvIHJl bW92ZSBvbmUgb2YgdGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYSBkZXRhaWxlZCByZXZpZXcgYW5k IGFjdGlvbmFibGUgaXRlbXMuCj4+Pgo+Pj4gV2lsbGlhbSBEZW5uaXNzIGJlbGlldmVzIHRoZSBk b2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0IGFncmVlcyB3aXRoIHNvbWUgb2YgdGhl IGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlzIHJldmlldzoKPj4+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDI2Lmh0bWwKPj4+ Cj4+PiBKdXN0aW4gaXMgY2VydGFpbmx5IHRoZSByZXZpZXdlciB3aXRoIHRoZSBzdHJvbmdlc3Qg b3Bpbmlvbi4gSGVyZSBpcyBvbmUgb2YgaGlzIHBvc3RzOgo+Pj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NTcuaHRtbAo+Pj4KPj4+IEFt b25nIGFsbCBjb25jZXJucyBKdXN0aW4gZXhwcmVzc2VkIHRoZSBmb2xsb3dpbmcgb25lIGlzIGFj dHVhbGx5IGFjdGlvbmFibGUgSU1ITzogSnVzdGluIGlzIHdvcnJpZWQgdGhhdCByZXBvcnRpbmcg aG93IGEgcGVyc29uIGF1dGhlbnRpY2F0ZWQgdG8gYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBh bmQgZW5jb3VyYWdpbmcgcGVvcGxlIHRvIHVzZSBPQXV0aCBmb3IgYXV0aGVudGljYXRpb24gaXMg YSBmaW5lIGxpbmUuIEhlIGJlbGlldmVzIHRoYXQgdGhpcyBkb2N1bWVudCBsZWFkcyByZWFkZXJz IHRvIGJlbGlldmUgdGhlIGxhdHRlci4KPj4+Cj4+PiBKb2huIGFncmVlcyB3aXRoIEp1c3RpbiBp bgo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMTU0NDguaHRtbCB0aGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgcGVvcGxlIGFyZSBu b3QgbWlzbGVhZCBhYm91dCB0aGUgaW50ZW50aW9uIG9mIHRoZSBkb2N1bWVudC4gSm9obiBhbHNv IHByb3ZpZGVzIGFkZGl0aW9uYWwgY29tbWVudHMgaW4gdGhpcyBwb3N0IHRvIHRoZQo+Pj4gbGlz dDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn MTU0NDEuaHRtbAo+Pj4gTW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGlu ZyB3b3JrLiBGb3IgZXhhbXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVs LAo+Pj4KPj4+IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9uIGJ1dCBoYXMg c29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2VzIG5vdCBwcm9w b3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZToKPj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDYyLmh0bWwKPj4+Cj4+ PiBXaXRoIG15IGNvLWNoYWlyIGhhdCBvbjogSSBqdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQg cmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdpdGhpbiB0aG9zZSBjbGFpbXMpIGlzIHdp dGhpbiB0aGUgc2NvcGUgb2YgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuIFdlIHN0YW5kYXJkaXpl ZCB0aGUgSldUIGluIHRoaXMgZ3JvdXAgYW5kIHdlIGFyZSBhbHNvIGNoYXJ0ZXJlZCB0byBzdGFu ZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3VzIGRy YWZ0cy4gTm90IHN0YW5kYXJkaXppbmcgSldUIGluIHRoZSBJRVRGIHdvdWxkIGhhdmUgbGVhZCB0 byByZWR1Y2VkIGludGVyb3BlcmFiaWxpdHkgYW5kIGxlc3Mgc2VjdXJpdHkuIEkgaGF2ZSBubyBk b3VidHMgdGhhdCB3YXMgYSB3cm9uZyBkZWNpc2lvbi4KPj4+Cj4+PiBJbiBpdHMgY3VycmVudCBm b3JtLCB0aGVyZSBpcyBub3QgZW5vdWdoIHN1cHBvcnQgdG8gaGF2ZSB0aGlzIGRvY3VtZW50IGFz IGEgV0cgaXRlbS4KPj4+Cj4+PiBXZSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGF1dGhvcnMg c2hvdWxkIGFkZHJlc3Mgc29tZSBvZiB0aGUgZWFzaWVyIGNvbW1lbnRzIGFuZCBzdWJtaXQgYSBu ZXcgdmVyc2lvbi4gVGhpcyB3b3VsZCBhbGxvdyB1cyB0byByZWFjaCBvdXQgdG8gdGhvc2Ugd2hv IGhhZCBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0 byByZS1ldmFsdWF0ZSB0aGVpciBkZWNpc2lvbi4gQSBuZXcgZHJhZnQgdmVyc2lvbiBzaG91bGQg YXQgbGVhc3QgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3VlczoKPj4+Cj4+PiAqIENsYXJpZnkg dGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJhZ2VtZW50IGZvciB1c2luZyBPQXV0 aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3Vs ZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSBKdXN0aW4gYW5kIEpvaG4u Cj4+Pgo+Pj4gKiBDaGFuZ2UgdGhlIHJlZ2lzdHJ5IHBvbGljeSwgd2hpY2ggd291bGQgYWRkcmVz cyBvbmUgb2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMsIFdpbGxpYW0sIGFuZCBQaGlsLgo+Pj4K Pj4+IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9uIHNpbmNlIHRoZXkgYXJl IG1vcmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBKb2huIG5vdGVkIHRoYXQg aGUgZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1ldGVycy4gVW5mb3J0dW5h dGVseSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpvaG4gdG8gcHJvdmlkZSBh biBhbHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUgaXMgb25lLiBBbHNvLCB0aGUgcmVtYXJr IHRoYXQgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291bGQgYmUgY291bnRlcmVkIHdpdGgg YW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwuIEphbWVzIHdhbnRlZCB0byByZW1vdmUgdGhlICJhbXJf dmFsdWVzIiBwYXJhbWV0ZXIuCj4+PiBJcyB0aGlzIHdoYXQgb3RoZXJzIHdhbnQgYXMgd2VsbD8K Pj4+Cj4+PiBBZnRlciB0aGVzZSBpdGVtcyBoYXZlIGJlZW4gYWRkcmVzc2VkIHdlIGJlbGlldmUg dGhhdCBtb3JlIGZvbGtzIGluIHRoZSBncm91cCB3aWxsIHN1cHBvcnQgdGhlIGRvY3VtZW50Lgo+ Pj4KPj4+IENpYW8KPj4+IEhhbm5lcyAmIERlcmVrCj4+Pgo+Pj4KPj4+Cj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gT0F1dGggbWFpbGluZyBs aXN0Cj4+PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Cj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPgo+4oCUIFJvbGFuZAo+Cj7igJ1FdmVyeWJv ZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIgo+RnJv bSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEtyYXVzcwo+Cj4KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5PQXV0aCBtYWls aW5nIGxpc3QKPk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj5PQXV0aCBtYWlsaW5nIGxpc3QKPk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgKPgo= ----_com.syntomo.email_804268952544320 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPlNvIGJhc2ljYWxseSwgdGhlIFJGQyBjb3VsZCBhbHNvIGp1c3QgZXN0YWJs aXNoIHRoZSBuZXcgcmVnaXN0cnkgYW5kIG9pZGYgY291bGQgZmVlbCBpbiB0aGUgdmFsdWVzPzwv cD4KPHAgZGlyPSJsdHIiPihqdXN0IHRyeWluZyB0byB1bmRlcnN0YW5kKTwvcD4KPGJyPjxicj4t LS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLTxicj5CZXRyZWZmOiBSRTogW09BVVRI LVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRv cHRpb24gRmluYWxpemVkPGJyPlZvbjogTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tJmd0Ozxicj5BbjogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQsSm9obiBCcmFkbGV5 CSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7PGJyPkNjOiBvYXV0aEBpZXRmLm9yZzxicj48YnI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBjb250ZXh0IHRoYXQgbW9zdCBwZW9wbGUgb24g dGhpcyB0aHJlYWQgcHJvYmFibHkgZG9u4oCZdCBoYXZlIGlzIHRoYXQgYW4gSUFOQSByZWdpc3Ry eSBjYW4gb25seSBiZSBlc3RhYmxpc2hlZCBieSBhbiBSRkMuJm5ic3A7IE5vbi1SRkMgc3BlY2lm aWNhdGlvbnMsIHN1Y2ggYXMgT3BlbklEDQogc3BlY2lmaWNhdGlvbnMsIGNhbiAqPGI+cmVnaXN0 ZXI8L2I+KiB2YWx1ZXMgaW4gYSByZWdpc3RyeSwgYnV0IHRoZXkgY2Fubm90ICo8Yj5lc3RhYmxp c2g8L2I+KiBhIHJlZ2lzdHJ5LiZuYnNwOyBUaGUgT3BlbklEIEZvdW5kYXRpb24gaW5xdWlyZWQg YWJvdXQgdGhpcyB3aXRoIHRoZSBJRVRGIGJlZm9yZSBPcGVuSUQgQ29ubmVjdCB3YXMgZmluYWxp emVkIGFuZCBsZWFybmVkIHRoYXQgaXRzIHNwZWNpZmljYXRpb25zIGNvdWxkIG5vdCBlc3RhYmxp c2gNCiBJQU5BIHJlZ2lzdHJpZXMuJm5ic3A7IE90aGVyd2lzZSwgdGhleSB3b3VsZCBoYXZlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SW5zdGVhZCwgUkZDcyBu ZWVkIHRvIGJlIGNyZWF0ZWQgdG8gZXN0YWJsaXNoIHJlZ2lzdHJpZXMg4oCTIGV2ZW4gZm9yIHZh bHVlcyBmaXJzdCBkZWZpbmVkIGluIG5vbi1SRkMgc3BlY2lmaWNhdGlvbnMuJm5ic3A7IFRoaXMg c3BlY2lmaWNhdGlvbiBpcyBvbmUgZXhhbXBsZSBvZiBkb2luZw0KIHRoaXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxicj4NCjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgRmVicnVhcnkgMTMsIDIwMTYgNjozNyBBTTxicj4NCjxiPlRvOjwvYj4g Sm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9h dXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRp Y2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6 ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwPldlIGNsZWFybHkgaGF2ZSB0aGlzIHByb2JsZW0gYmV0d2VlbiBvYXV0 aCBhbmQgb2lkYy4gSnVzdCB0YWtlIGEgbG9vayBhdCB0aGUgZGlzY292ZXJ5IHRocmVhZC48bzpw PjwvbzpwPjwvcD4NCjxwPkFjY29yZGluZyB0byB5b3UgYXJndW1lbnQgSSBzZWUgdHdvIG9wdGlv bnM6PGJyPg0KKDEpIGFtciBzdGF5cyBhbiBvaWRjIGNsYWltLCBpcyB1c2VkIGluIG9pZGMgb25s eSBhbmQgdGhlIG9hdXRoIHdnIGp1c3QgcHVibGlzaGVzIHRoZSByZWdpc3RyeSBlbnRyaWVzLiBJ biB0aGlzIGNhc2UsIHRoZSBzcGVjIHNob3VsZCBjbGVhcmx5IGV4cGxhaW4gdGhpcy48YnI+DQoo MikgYW1yIGlzIG9mIGFueSB1c2UgaW4gb2F1dGggKGFsdGhvdWdoIGl0IGhhcyBiZWVuIGludmVu dGVkIGluIG9pZGMpIC0gdGhhbiBkZWZpbmUgaXQgYW5kIG1vdGl2YXRlIGl0J3MgdXNlIGluIG9h dXRoIGluIHRoaXMgc3BlYy4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+UmlnaHQgbm93LCBJIHRoaW5r IGl0IGNyZWF0ZXMgdGhlIGltcHJlc3Npb24gb2F1dGggaXMgZm9yIGF1dGhlbnRpY2F0aW9uLiA8 bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0tLS0t LS0gT3JpZ2luYWxuYWNocmljaHQgLS0tLS0tLS08YnI+DQpCZXRyZWZmOiBSZTogW09BVVRILVdH XSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRp b24gRmluYWxpemVkPGJyPg0KVm9uOiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCkFuOiA8YSBo cmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlLG9h dXRoQGlldGYub3JnIj5yb2xhbmQuaGVkYmVyZ0B1bXUuc2Usb2F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGJyPg0KVGhpcyBpcyBub3QgYSBpc3N1ZSBiZXR3ZWVuIG9hdXRoIGFuZCBPSURDLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBoYXMgdG8gZG8g d2l0aCB0aGUgcmVnaXN0cnkgZm9yIEpXVCBiZWluZyBpbiBPQXV0aC4gJm5ic3A7IE1hbnkgcHJv dG9jb2xzIHRoYXQgdXNlIEpXVCBhcmUgZ29pbmcgdG8gd2FudCB0byByZWdpc3RlciBjbGFpbXMu ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2UgY2Fu4oCZdCBhc2sgdGhlbSB0byBhbGwgbW92ZSB0aGUgcGFydHMgb2YgdGhlcmUgc3Bl Y3MgdGhhdCB1c2UgSldUIHRvIE9BdXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIEpXVCBzaG91bGQgaGF2ZSBiZWVuIHBhcnQg b2YgSk9TRSwgYnV0IHRoYXQgaXMgd2F0ZXIgdW5kZXIgdGhlIGJyaWRnZS4gJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPQXV0 aCBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZCBpdOKAmXMgcmVnaXN0cnksIGFuZCB3ZSB3 aWxsIG5lZWQgdG8gZGVhbCB3aXRoIHJlZ2lzdGVyaW5nIGNsYWltcy4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhh dCB3ZSBjYW4gdGVsbCBwZW9wbGUgdGhhdCB0aGV5IG5lZWQgdG8gcHVibGlzaCB0aGUgc3BlY3Mg ZGVmaW5pbmcgdGhlIGNsYWltcyBzb21lcGxhY2UgZWxzZSwgYW5kIGp1c3QgZG8gdGhlIHJlZ2lz dHJ5IHBhcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ib3dldmVyIGRvaW5nIHRoYXQgd2lsbCBwcm9iYWJseSBub3QgaW1wcm92ZSBpbnRlcm9w ZXJhYmlsaXR5IGFuZCB1bmRlcnN0YW5kaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGNsYWlt IGZvciBKV1QgaW4gZ2VuZXJhbC4gJm5ic3A7V2Ugc3RpbGwgaGF2ZSBhbG1vc3Qgbm8gZG9jdW1l bnRhdGlvbiBpbiB0aGUgV0cgYWJvdXQgd2hhdCBhIEpXVCBhY2Nlc3MgdG9rZW4gd291bGQgY29u dGFpbiBvdGhlciB0aGFuIHRoZSBQT1Agd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAxMywgMjAxNiwgYXQgOToxOCBB TSwgPGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij4NCnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGJhc2ljYWxseSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIEFz c2VydGluZyBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGluIGFjY2VzcyB0b2tlbnMgKGluIHRoaXMg Y2FzZSBpbiBKV1RTIGZvcm1hdCkgaXMgcmVhc29uYWJsZS4gV2UgdXNlIGl0IHRvIHBhc3MgaW5m b3JtYXRpb24gYWJvdXQNCiB0aGUgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIHByaW9yIGlzc3Vp bmcgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfIHNlcnZlci4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IHdvcnJpZXMgbWUgaXMgdGhlIGJhY2sg YW5kIGZvcnRoIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0gaXMgZGVmaW5l ZCBpbiBvaWRjICh3aGljaCBzaXRzIG9uIHRvcCBvZiBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBz cGVjaWZpZXMgdGhlIHJlZ2lzdHJ5PyBNb3Jlb3ZlciwgdGhlDQogY3VycmVudCB0ZXh0IGRvZXMg bm90IGdpdmUgYSByYXRpb25hbGUgZm9yIHVzaW5nIGFtciBpbiBjb250ZXh0IG9mIG9hdXRoLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBhIFdHIHdlIG5lZWQgdG8g ZmluZCBhIGNsZWFyIGRlbGluZWF0aW9uIGJldHdlZW4gYm90aCBwcm90b2NvbHMsIG90aGVyd2lz ZSBub29uZSB3aWxsIHJlYWxseSB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGFuZCB3aGVuIHRv IHVzZSB3aGF0LiBXZSBjcmVhdGUgY29uZnVzaW9uIQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkZvciB0aGlzIHBhcnRpY3VsYXIgZHJhZnQgdGhpcyBtZWFucyB0byBl aXRoZXIgbW92ZSBhbXIgdG8gb2F1dGggb3IgdGhlIHJlZ2lzdHJ5IHRvIG9pZGMuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YmVzdCByZWdhcmRzLA0KPGJyPg0KVG9y c3Rlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0IC0tLS0tLS0tPGJyPg0KVm9uOiBSb2xhbmQgSGVkYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvbGFuZC5oZWRiZXJnQHVtdS5zZSI+cm9sYW5kLmhlZGJlcmdAdW11LnNlPC9hPiZndDs8YnI+ DQpHZXNlbmRldDogRnJpZGF5LCBGZWJydWFyeSAxMiwgMjAxNiAwNTo0NSBQTTxicj4NCkFuOiA8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCkJl dHJlZmY6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFs dWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+JiM0MzsxPGJyPg0KPGJyPg0KJmd0OyAxMiBmZWIgMjAxNiBrbC4gMTY6 NTggc2tyZXYgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5j b20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICYjNDM7 MSB0byBhZG9wdCB0aGlzIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgT24gRmViIDEy LCAyMDE2LCBhdCAzOjA3IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBEcmFmdCAtMDUgaW5jb3Jwb3Jh dGVzIHRoZSBmZWVkYmFjayBkZXNjcmliZWQgYmVsb3cgLSBkZWxldGluZyB0aGUgcmVxdWVzdCBw YXJhbWV0ZXIsIG5vdGluZyB0aGF0IHRoaXMgc3BlYyBpc24ndCBhbiBlbmNvdXJhZ2VtZW50IHRv IHVzZSBPQXV0aCAyLjAgZm9yIGF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgZW1wbG95aW5nIGFwcHJv cHJpYXRlIGV4dGVuc2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlv biBmb3IgSUFOQQ0KIHJlZ2lzdHJhdGlvbi4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgaXTigJlzIG5v dyByZWFkeSBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBPQXV0aCBbPGEgaHJlZj0i bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnPC9hPl0gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KJmd0OyZndDsgU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgMTE6MjMgQU08YnI+DQomZ3Q7Jmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7Jmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVu Y2UgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQ8YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBIaSBhbGwsPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gSmFudWFy eSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlIEF1dGhlbnRpY2F0aW9u IE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzIHNwZWNpZmljYXRpb24sIHNlZQ0KPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MDIu aHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMTU0MDIuaHRtbDwvYT48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBXaGF0IHN1cnBy aXNlZCB1cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0dWFsbHkgdmVyeSBzaW1wbGU6IHdl IGRlZmluZSBuZXcgY2xhaW1zIGFuZCBjcmVhdGUgYSByZWdpc3RyeSB3aXRoIG5ldyB2YWx1ZXMu IE5vdCBhIGJpZyBkZWFsIGJ1dCB0aGF0J3Mgbm90IHdoYXQgdGhlIGZlZWRiYWNrIGZyb20gdGhl IFlva29oYW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IgYWRvcHRp b24gb24gdGhlIGxpc3Qgc2hvd3MuDQogVGhlIGZlZWRiYWNrIGxlYWQgdG8gbWl4ZWQgZmVlbGlu Z3MgYW5kIGl0IGlzIGEgYml0IGRpZmZpY3VsdCBmb3IgRGVyZWsgYW5kIG15c2VsZiB0byBqdWRn ZSBjb25zZW5zdXMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgTGV0IG1lIHRlbGwgeW91 IHdoYXQgd2Ugc2VlIGZyb20gdGhlIGNvbW1lbnRzIG9uIHRoZSBsaXN0Ljxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IEluIGhpcyByZXZpZXcgYXQ8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQy My5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cxNTQyMy5odG1sPC9hPiBKYW1lcyBNYW5nZXIgYXNrcyBmb3Igc2lnbmlmaWNhbnQgY2hh bmdlcy4gQW1vbmcgb3RoZXIgdGhpbmdzLCBoZSB3YW50cyB0byByZW1vdmUgb25lIG9mIHRoZSBj bGFpbXMuIEhlIHByb3ZpZGVzDQogYSBkZXRhaWxlZCByZXZpZXcgYW5kIGFjdGlvbmFibGUgaXRl bXMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgV2lsbGlhbSBEZW5uaXNzIGJlbGlldmVz IHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24gYnV0IGFncmVlcyB3aXRoIHNvbWUg b2YgdGhlIGNvbW1lbnRzIGZyb20gSmFtZXMuIEhlcmUgaXMgaGlzIHJldmlldzo8YnI+DQomZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQyNi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQyNi5odG1sPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IEp1c3RpbiBpcyBjZXJ0YWlubHkgdGhlIHJldmlld2VyIHdpdGggdGhlIHN0cm9uZ2Vz dCBvcGluaW9uLiBIZXJlIGlzIG9uZSBvZiBoaXMgcG9zdHM6PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn MTU0NTcuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTU0NTcuaHRtbDwvYT48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBbW9u ZyBhbGwgY29uY2VybnMgSnVzdGluIGV4cHJlc3NlZCB0aGUgZm9sbG93aW5nIG9uZSBpcyBhY3R1 YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQgcmVwb3J0aW5nIGhv dyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRvIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5k IGVuY291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIGF1dGhlbnRpY2F0aW9uIGlzIGEg ZmluZSBsaW5lLiBIZSBiZWxpZXZlcw0KIHRoYXQgdGhpcyBkb2N1bWVudCBsZWFkcyByZWFkZXJz IHRvIGJlbGlldmUgdGhlIGxhdHRlci48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBKb2hu IGFncmVlcyB3aXRoIEp1c3RpbiBpbjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQ4Lmh0bWwiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQ4 Lmh0bWw8L2E+IHRoYXQgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBwZW9wbGUgYXJlIG5vdCBt aXNsZWFkIGFib3V0IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRvY3VtZW50LiBKb2huIGFsc28gcHJv dmlkZXMNCiBhZGRpdGlvbmFsIGNvbW1lbnRzIGluIHRoaXMgcG9zdCB0byB0aGU8YnI+DQomZ3Q7 Jmd0OyBsaXN0OiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTQ0MS5odG1sIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWw8L2E+PGJyPg0KJmd0OyZndDsg TW9zdCBvZiB0aGVtIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgZWRpdGluZyB3b3JrLiBGb3IgZXhh bXBsZSwgbWV0aG9kcyBsaXN0ZWQgYXJlIHJlYWxseSBub3QgdXNlZnVsLDxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IFBoaWwgYWdyZWVzIHdpdGggdGhlIGRvY3VtZW50IGFkb3B0aW9uIGJ1 dCBoYXMgc29tZSByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2VzIG5v dCBwcm9wb3NlIHNwZWNpZmljIHRleHQuIEhpcyByZXZpZXcgaXMgaGVyZTo8YnI+DQomZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTQ2Mi5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTQ2Mi5odG1sPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7IFdpdGggbXkgY28tY2hhaXIgaGF0IG9uOiBJIGp1c3Qgd2FudGVkIHRvIGNsYXJpZnkgdGhh dCByZWdpc3RlcmluZyBjbGFpbXMgKGFuZCB2YWx1ZXMgd2l0aGluIHRob3NlIGNsYWltcykgaXMg d2l0aGluIHRoZSBzY29wZSBvZiB0aGUgT0F1dGggd29ya2luZyBncm91cC4gV2Ugc3RhbmRhcmRp emVkIHRoZSBKV1QgaW4gdGhpcyBncm91cCBhbmQgd2UgYXJlIGFsc28gY2hhcnRlcmVkIHRvIHN0 YW5kYXJkaXplIGNsYWltcywgYXMgd2UgYXJlIGN1cnJlbnRseQ0KIGRvaW5nIHdpdGggdmFyaW91 cyBkcmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBpbiB0aGUgSUVURiB3b3VsZCBoYXZlIGxl YWQgdG8gcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCBsZXNzIHNlY3VyaXR5LiBJIGhhdmUg bm8gZG91YnRzIHRoYXQgd2FzIGEgd3JvbmcgZGVjaXNpb24uPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgSW4gaXRzIGN1cnJlbnQgZm9ybSwgdGhlcmUgaXMgbm90IGVub3VnaCBzdXBwb3J0 IHRvIGhhdmUgdGhpcyBkb2N1bWVudCBhcyBhIFdHIGl0ZW0uPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgV2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBhdXRob3JzIHNob3VsZCBhZGRy ZXNzIHNvbWUgb2YgdGhlIGVhc2llciBjb21tZW50cyBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24u IFRoaXMgd291bGQgYWxsb3cgdXMgdG8gcmVhY2ggb3V0IHRvIHRob3NlIHdobyBoYWQgZXhwcmVz c2VkIGNvbmNlcm5zIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVh dGUgdGhlaXIgZGVjaXNpb24uIEEgbmV3IGRyYWZ0IHZlcnNpb24NCiBzaG91bGQgYXQgbGVhc3Qg YWRkcmVzcyB0aGUgZm9sbG93aW5nIGlzc3Vlczo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyAqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJhZ2VtZW50IGZv ciB1c2luZyBPQXV0aCBhcyBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbC4gSSBiZWxpZXZlIHRo YXQgdGhpcyB3b3VsZCBhZGRyZXNzIHNvbWUgb2YgdGhlIGNvbmNlcm5zIHJhaXNlZCBieSBKdXN0 aW4gYW5kIEpvaG4uPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgKiBDaGFuZ2UgdGhlIHJl Z2lzdHJ5IHBvbGljeSwgd2hpY2ggd291bGQgYWRkcmVzcyBvbmUgb2YgdGhlIGNvbW1lbnRzIGZy b20gSmFtZXMsIFdpbGxpYW0sIGFuZCBQaGlsLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IFZhcmlvdXMgb3RoZXIgaXRlbXMgcmVxdWlyZSBkaXNjdXNzaW9uIHNpbmNlIHRoZXkgYXJlIG1v cmUgZGlmZmljdWx0IHRvIGFkZHJlc3MuIEZvciBleGFtcGxlLCBKb2huIG5vdGVkIHRoYXQgaGUg ZG9lcyBub3QgbGlrZSB0aGUgdXNlIG9mIHJlcXVlc3QgcGFyYW1ldGVycy4gVW5mb3J0dW5hdGVs eSwgbm8gYWx0ZXJuYXRpdmUgaXMgb2ZmZXJlZC4gSSB1cmdlIEpvaG4gdG8gcHJvdmlkZSBhbiBh bHRlcm5hdGl2ZSBwcm9wb3NhbCwgaWYgdGhlcmUNCiBpcyBvbmUuIEFsc28sIHRoZSByZW1hcmsg dGhhdCB0aGUgdmFsdWVzIGFyZSBtZWFuaW5nbGVzcyBjb3VsZCBiZSBjb3VudGVyZWQgd2l0aCBh biBhbHRlcm5hdGl2ZSBwcm9wb3NhbC4gSmFtZXMgd2FudGVkIHRvIHJlbW92ZSB0aGUgJnF1b3Q7 YW1yX3ZhbHVlcyZxdW90OyBwYXJhbWV0ZXIuPGJyPg0KJmd0OyZndDsgSXMgdGhpcyB3aGF0IG90 aGVycyB3YW50IGFzIHdlbGw/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQWZ0ZXIgdGhl c2UgaXRlbXMgaGF2ZSBiZWVuIGFkZHJlc3NlZCB3ZSBiZWxpZXZlIHRoYXQgbW9yZSBmb2xrcyBp biB0aGUgZ3JvdXAgd2lsbCBzdXBwb3J0IHRoZSBkb2N1bWVudC48YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyBDaWFvPGJyPg0KJmd0OyZndDsgSGFubmVzICZhbXA7IERlcmVrPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxicj4NCjxicj4NCuKAlCBSb2xhbmQ8YnI+DQo8YnI+DQrigJ1FdmVyeWJv ZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uJnF1b3Q7 PGJyPg0KRnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEtyYXVz czxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0K ----_com.syntomo.email_804268952544320-- From nobody Sat Feb 13 08:08:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D41A0378 for ; Sat, 13 Feb 2016 08:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJG8xbmjluZi for ; Sat, 13 Feb 2016 08:08:11 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBE51A0373 for ; Sat, 13 Feb 2016 08:08:11 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1DG8Aio008263 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Feb 2016 16:08:10 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1DG891C023675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 13 Feb 2016 16:08:09 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1DG88Da012417; Sat, 13 Feb 2016 16:08:09 GMT Received: from [192.168.1.66] (/23.16.225.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Feb 2016 08:08:07 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-89483210-E40A-4E38-B9A9-18962E830882 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Sat, 13 Feb 2016 08:08:06 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: "torsten@lodderstedt.net" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 16:08:15 -0000 --Apple-Mail-89483210-E40A-4E38-B9A9-18962E830882 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes Phil > On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" wrote: >=20 > So basically, the RFC could also just establish the new registry and oidf c= ould feel in the values? >=20 > (just trying to understand) >=20 >=20 >=20 > -------- Originalnachricht -------- > Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for A= doption Finalized > Von: Mike Jones > An: torsten@lodderstedt.net,John Bradley > Cc: oauth@ietf.org >=20 > The context that most people on this thread probably don=E2=80=99t have is= that an IANA registry can only be established by an RFC. Non-RFC specifica= tions, such as OpenID specifications, can *register* values in a registry, b= ut they cannot *establish* a registry. The OpenID Foundation inquired about= this with the IETF before OpenID Connect was finalized and learned that its= specifications could not establish IANA registries. Otherwise, they would h= ave. >=20 > =20 >=20 > Instead, RFCs need to be created to establish registries =E2=80=93 even fo= r values first defined in non-RFC specifications. This specification is one= example of doing this. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderste= dt.net > Sent: Saturday, February 13, 2016 6:37 AM > To: John Bradley > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for A= doption Finalized >=20 > =20 >=20 > We clearly have this problem between oauth and oidc. Just take a look at t= he discovery thread. >=20 > According to you argument I see two options: > (1) amr stays an oidc claim, is used in oidc only and the oauth wg just pu= blishes the registry entries. In this case, the spec should clearly explain t= his. > (2) amr is of any use in oauth (although it has been invented in oidc) - t= han define it and motivate it's use in oauth in this spec. >=20 > Right now, I think it creates the impression oauth is for authentication. >=20 >=20 >=20 > -------- Originalnachricht -------- > Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for A= doption Finalized > Von: John Bradley > An: torsten@lodderstedt.net > Cc: roland.hedberg@umu.se,oauth@ietf.org >=20 > This is not a issue between oauth and OIDC. >=20 > =20 >=20 > This has to do with the registry for JWT being in OAuth. Many protocols t= hat use JWT are going to want to register claims. =20 >=20 > We can=E2=80=99t ask them to all move the parts of there specs that use JW= T to OAuth. >=20 > =20 >=20 > Perhaps JWT should have been part of JOSE, but that is water under the bri= dge. =20 >=20 > =20 >=20 > The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we will= need to deal with registering claims. =20 >=20 > =20 >=20 > I guess that we can tell people that they need to publish the specs defini= ng the claims someplace else, and just do the registry part. >=20 > However doing that will probably not improve interoperability and understa= nding. >=20 > =20 >=20 > This document defines the claim for JWT in general. We still have almost n= o documentation in the WG about what a JWT access token would contain other t= han the POP work. >=20 > =20 >=20 > John B. >=20 > On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: >=20 > =20 >=20 > I basically support adoption of this document. Asserting authentication me= thods in access tokens (in this case in JWTS format) is reasonable. We use i= t to pass information about the authentication performed prior issuing an ac= cess token to the _resource_ server. >=20 > What worries me is the back and forth between oauth and oidc. The amr clai= m is defined in oidc (which sits on top of oauth) but the oauth wg specifies= the registry? Moreover, the current text does not give a rationale for usin= g amr in context of oauth. >=20 > As a WG we need to find a clear delineation between both protocols, otherw= ise noone will really understand the difference and when to use what. We cre= ate confusion! >=20 > For this particular draft this means to either move amr to oauth or the re= gistry to oidc. >=20 > best regards,=20 > Torsten. >=20 >=20 >=20 > -------- Urspr=C3=BCngliche Nachricht -------- > Von: Roland Hedberg > Gesendet: Friday, February 12, 2016 05:45 PM > An: oauth@ietf.org > Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for A= doption Finalized >=20 > +1 >=20 > > 12 feb 2016 kl. 16:58 skrev John Bradley : > >=20 > > +1 to adopt this draft. > >=20 > >> On Feb 12, 2016, at 3:07 AM, Mike Jones w= rote: > >>=20 > >> Draft -05 incorporates the feedback described below - deleting the requ= est parameter, noting that this spec isn't an encouragement to use OAuth 2.0= for authentication without employing appropriate extensions, and no longer r= equiring a specification for IANA registration. I believe that it=E2=80=99s= now ready for working group adoption. > >>=20 > >> -- Mike > >>=20 > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofe= nig > >> Sent: Thursday, February 4, 2016 11:23 AM > >> To: oauth@ietf.org > >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized > >>=20 > >> Hi all, > >>=20 > >> On January 19th I posted a call for adoption of the Authentication Meth= od Reference Values specification, see http://www.ietf.org/mail-archive/web/= oauth/current/msg15402.html > >>=20 > >> What surprised us is that this work is conceptually very simple: we def= ine new claims and create a registry with new values. Not a big deal but tha= t's not what the feedback from the Yokohama IETF meeting and the subsequent c= all for adoption on the list shows. The feedback lead to mixed feelings and i= t is a bit difficult for Derek and myself to judge consensus. > >>=20 > >> Let me tell you what we see from the comments on the list. > >>=20 > >> In his review at > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James M= anger asks for significant changes. Among other things, he wants to remove o= ne of the claims. He provides a detailed review and actionable items. > >>=20 > >> William Denniss believes the document is ready for adoption but agrees w= ith some of the comments from James. Here is his review: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html > >>=20 > >> Justin is certainly the reviewer with the strongest opinion. Here is on= e of his posts: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html > >>=20 > >> Among all concerns Justin expressed the following one is actually actio= nable IMHO: Justin is worried that reporting how a person authenticated to a= n authorization endpoint and encouraging people to use OAuth for authenticat= ion is a fine line. He believes that this document leads readers to believe t= he latter. > >>=20 > >> John agrees with Justin in > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that w= e need to make sure that people are not mislead about the intention of the d= ocument. John also provides additional comments in this post to the > >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html > >> Most of them require more than just editing work. For example, methods l= isted are really not useful, > >>=20 > >> Phil agrees with the document adoption but has some remarks about the r= egistry although he does not propose specific text. His review is here: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html > >>=20 > >> With my co-chair hat on: I just wanted to clarify that registering clai= ms (and values within those claims) is within the scope of the OAuth working= group. We standardized the JWT in this group and we are also chartered to s= tandardize claims, as we are currently doing with various drafts. Not standa= rdizing JWT in the IETF would have lead to reduced interoperability and less= security. I have no doubts that was a wrong decision. > >>=20 > >> In its current form, there is not enough support to have this document a= s a WG item. > >>=20 > >> We believe that the document authors should address some of the easier c= omments and submit a new version. This would allow us to reach out to those w= ho had expressed concerns about the scope of the document to re-evaluate the= ir decision. A new draft version should at least address the following issue= s: > >>=20 > >> * Clarify that this document is not an encouragement for using OAuth as= an authentication protocol. I believe that this would address some of the c= oncerns raised by Justin and John. > >>=20 > >> * Change the registry policy, which would address one of the comments f= rom James, William, and Phil. > >>=20 > >> Various other items require discussion since they are more difficult to= address. For example, John noted that he does not like the use of request p= arameters. Unfortunately, no alternative is offered. I urge John to provide a= n alternative proposal, if there is one. Also, the remark that the values ar= e meaningless could be countered with an alternative proposal. James wanted t= o remove the "amr_values" parameter. > >> Is this what others want as well? > >>=20 > >> After these items have been addressed we believe that more folks in the= group will support the document. > >>=20 > >> Ciao > >> Hannes & Derek > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > =E2=80=94 Roland >=20 > =E2=80=9DEverybody should be quiet near a little stream and listen." > =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-89483210-E40A-4E38-B9A9-18962E830882 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes

Phil

On Feb 1= 3, 2016, at 07:59, "torsten@lodde= rstedt.net" <torsten@lodde= rstedt.net> wrote:

So basically, the RFC could also just establish the new registry an= d oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authe= ntication Method Reference Values: Call for Adoption Finalized
Von: Mike J= ones <Michael.Jones@micros= oft.com>
An: torsten@lo= dderstedt.net,John Bradley <v= e7jtb@ve7jtb.com>
Cc: oauth@ietf= .org

The context that most people on this th= read probably don=E2=80=99t have is that an IANA registry can only be establ= ished by an RFC.  Non-RFC specifications, such as OpenID specifications, can *register* values in a registry, but they cannot= *establish* a registry.  The OpenID Foundation inquired about t= his with the IETF before OpenID Connect was finalized and learned that its s= pecifications could not establish IANA registries.  Otherwise, they would have.

 

Instead, RFCs need to be created to est= ablish registries =E2=80=93 even for values first defined in non-RFC specifi= cations.  This specification is one example of doing this.

 

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

 =

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodde= rstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7j= tb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just take a look at t= he discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publ= ishes the registry entries. In this case, the spec should clearly explain th= is.
(2) amr is of any use in oauth (although it has been invented in oidc) - tha= n define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.=



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ado= ption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com= >
An: torsten@lodderstedt.net Cc: roland.hedberg@u= mu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAu= th.   Many protocols that use JWT are going to want to register claims.=  

We can=E2=80=99t ask them to all move the parts of th= ere specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that i= s water under the bridge.  

 

The OAuth WG is responsible for JWT and it=E2=80=99s r= egistry, and we will need to deal with registering claims.  =

 

I guess that we can tell people that they need to pub= lish the specs defining the claims someplace else, and just do the registry p= art.

However doing that will probably not improve interope= rability and understanding.

 

This document defines the claim for JWT in general. &= nbsp;We still have almost no documentation in the WG about what a JWT access= token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically support adoption of this document. Asserting authenticat= ion methods in access tokens (in this case in JWTS format) is reasonable. We= use it to pass information about the authentication performed prior issuing an access token to the _resource= _ server.

What worries me is the back and forth between oauth and oidc. The am= r claim is defined in oidc (which sits on top of oauth) but the oauth wg spe= cifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, o= therwise noone will really understand the difference and when to use what. W= e create confusion!

For this particular draft this means to either move amr to oauth or t= he registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedb= erg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ado= ption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the r= equest parameter, noting that this spec isn't an encouragement to use OAuth 2= .0 for authentication without employing appropriate extensions, and no longe= r requiring a specification for IANA registration.  I believe that it=E2=80=99s now ready for working group= adoption.
>>
>>           &n= bsp;            =             &nbs= p;            &n= bsp;         -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth= -bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call fo= r Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication M= ethod Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: we= define new claims and create a registry with new values. Not a big deal but= that's not what the feedback from the Yokohama IETF meeting and the subsequ= ent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and= myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James Manger asks for significant changes. Among other things, he wants t= o remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agr= ees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here i= s one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually a= ctionable IMHO: Justin is worried that reporting how a person authenticated t= o an authorization endpoint and encouraging people to use OAuth for authenti= cation is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we need to make sure that people are not mislead about the intention= of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, meth= ods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about t= he registry although he does not propose specific text. His review is here:<= br> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering c= laims (and values within those claims) is within the scope of the OAuth work= ing group. We standardized the JWT in this group and we are also chartered t= o standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lea= d to reduced interoperability and less security. I have no doubts that was a= wrong decision.
>>
>> In its current form, there is not enough support to have this docum= ent as a WG item.
>>
>> We believe that the document authors should address some of the eas= ier comments and submit a new version. This would allow us to reach out to t= hose who had expressed concerns about the scope of the document to re-evalua= te their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAut= h as an authentication protocol. I believe that this would address some of t= he concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the commen= ts from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficul= t to address. For example, John noted that he does not like the use of reque= st parameters. Unfortunately, no alternative is offered. I urge John to prov= ide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered= with an alternative proposal. James wanted to remove the "amr_values" param= eter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in= the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www= .ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.iet= f.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


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

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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-89483210-E40A-4E38-B9A9-18962E830882-- From nobody Sat Feb 13 11:11:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729011A1BC6 for ; Sat, 13 Feb 2016 11:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWxZFzGBMiid for ; Sat, 13 Feb 2016 11:11:32 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524491A1BBE for ; Sat, 13 Feb 2016 11:11:30 -0800 (PST) X-AuditID: 1209190d-8bbff70000000489-62-56bf7fe05213 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 78.84.01161.0EF7FB65; Sat, 13 Feb 2016 14:11:28 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u1DJBRND027128; Sat, 13 Feb 2016 14:11:28 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1DJBPfl007159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Feb 2016 14:11:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_1F5A5293-AB6B-400C-B2F3-C557826FE444" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Sat, 13 Feb 2016 14:11:25 -0500 Message-Id: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> References: To: Phil Hunt X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hRV1n1Qvz/M4NMRI4uTb1+xWSyY38hu 8erYUxYHZo8lS34yeRzr6Wf1+Pj0FksAcxSXTUpqTmZZapG+XQJXRvuso0wFPb1MFYv272dq YFzwnLGLkZNDQsBEYv+OByxdjFwcQgJtTBKb9h+EcjYySlx+voQdwrnNJNG+5wETSAuzQILE i8/Lwdp5BfQkXt26zApiCwtES1xYtZAZxGYTUJWYvqYFrJ5TwE7i/eE+sHoWoPjFEweANnAA zYmXeHpQBcTkFbCSmHQmCqRCSOA4o8SE0yUgtoiAisS3q9ehDpWV2P37EdMERv5ZSI6YheQI iLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXSC83 s0QvNaV0EyM43CV5dzC+O6h0iFGAg1GJh3eG2L4wIdbEsuLK3EOMkhxMSqK8y34DhfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwzo3YHybEm5JYWZValA+TkuZgURLnffRrZ5iQQHpiSWp2ampB ahFMVoaDQ0mClw0Y10KCRanpqRVpmTklCGkmDk6Q4TxAw7VBaniLCxJzizPTIfKnGBWlxHlj QBICIImM0jy4XlA6Snh72PQVozjQK8K87XVAVTzAVAbX/QpoMBPQ4Irb+0AGlyQipKQaGK/4 CbTuOB/upVEbs3HKRQdT5vhLO/KzLhzeNFFkw9kQWfH2KbvKps//f2nNjYcLZLo9/aal7b/Z KBvDuCw+jydZOH1//ZTwafYHHdsEk7OrXLt/F7Dox36RtVg/nS1RKaz2+MG/81c7KaTc0sxK eME/8VP3ArljCiI1Cvd9q02mpdyxuxZtr8RSnJFoqMVcVJwIAKYZG8QiAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 19:11:37 -0000 --Apple-Mail=_1F5A5293-AB6B-400C-B2F3-C557826FE444 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can we just do that, then? Seems to be the easiest way to address = various needs and concerns.=20 =E2=80=94 Justin > On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) = wrote: >=20 > Yes >=20 > Phil >=20 > On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net = " > wrote: >=20 >> So basically, the RFC could also just establish the new registry and = oidf could feel in the values? >>=20 >> (just trying to understand) >>=20 >>=20 >>=20 >> -------- Originalnachricht -------- >> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >> Von: Mike Jones > >> An: torsten@lodderstedt.net ,John = Bradley > >> Cc: oauth@ietf.org >>=20 >> The context that most people on this thread probably don=E2=80=99t = have is that an IANA registry can only be established by an RFC. = Non-RFC specifications, such as OpenID specifications, can *register* = values in a registry, but they cannot *establish* a registry. The = OpenID Foundation inquired about this with the IETF before OpenID = Connect was finalized and learned that its specifications could not = establish IANA registries. Otherwise, they would have. >>=20 >> =20 >>=20 >> Instead, RFCs need to be created to establish registries =E2=80=93 = even for values first defined in non-RFC specifications. This = specification is one example of doing this. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =C2=A0 <> >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of torsten@lodderstedt.net = >> Sent: Saturday, February 13, 2016 6:37 AM >> To: John Bradley > >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>=20 >> =20 >>=20 >> We clearly have this problem between oauth and oidc. Just take a look = at the discovery thread. >>=20 >> According to you argument I see two options: >> (1) amr stays an oidc claim, is used in oidc only and the oauth wg = just publishes the registry entries. In this case, the spec should = clearly explain this. >> (2) amr is of any use in oauth (although it has been invented in = oidc) - than define it and motivate it's use in oauth in this spec. >>=20 >> Right now, I think it creates the impression oauth is for = authentication. >>=20 >>=20 >>=20 >> -------- Originalnachricht -------- >> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >> Von: John Bradley > >> An: torsten@lodderstedt.net >> Cc: roland.hedberg@umu.se,oauth@ietf.org = >>=20 >> This is not a issue between oauth and OIDC. >>=20 >> =20 >>=20 >> This has to do with the registry for JWT being in OAuth. Many = protocols that use JWT are going to want to register claims. =20 >>=20 >> We can=E2=80=99t ask them to all move the parts of there specs that = use JWT to OAuth. >>=20 >> =20 >>=20 >> Perhaps JWT should have been part of JOSE, but that is water under = the bridge. =20 >>=20 >> =20 >>=20 >> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we = will need to deal with registering claims. =20 >>=20 >> =20 >>=20 >> I guess that we can tell people that they need to publish the specs = defining the claims someplace else, and just do the registry part. >>=20 >> However doing that will probably not improve interoperability and = understanding. >>=20 >> =20 >>=20 >> This document defines the claim for JWT in general. We still have = almost no documentation in the WG about what a JWT access token would = contain other than the POP work. >>=20 >> =20 >>=20 >> John B. >>=20 >> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net = wrote: >>=20 >> =20 >>=20 >> I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server. >>=20 >> What worries me is the back and forth between oauth and oidc. The amr = claim is defined in oidc (which sits on top of oauth) but the oauth wg = specifies the registry? Moreover, the current text does not give a = rationale for using amr in context of oauth. >>=20 >> As a WG we need to find a clear delineation between both protocols, = otherwise noone will really understand the difference and when to use = what. We create confusion! >>=20 >> For this particular draft this means to either move amr to oauth or = the registry to oidc. >>=20 >> best regards,=20 >> Torsten. >>=20 >>=20 >>=20 >> -------- Urspr=C3=BCngliche Nachricht -------- >> Von: Roland Hedberg > >> Gesendet: Friday, February 12, 2016 05:45 PM >> An: oauth@ietf.org >> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>=20 >> +1 >>=20 >> > 12 feb 2016 kl. 16:58 skrev John Bradley >: >> >=20 >> > +1 to adopt this draft. >> >=20 >> >> On Feb 12, 2016, at 3:07 AM, Mike Jones = > = wrote: >> >>=20 >> >> Draft -05 incorporates the feedback described below - deleting the = request parameter, noting that this spec isn't an encouragement to use = OAuth 2.0 for authentication without employing appropriate extensions, = and no longer requiring a specification for IANA registration. I = believe that it=E2=80=99s now ready for working group adoption. >> >>=20 >> >> -- Mike >> >>=20 >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >> >> Sent: Thursday, February 4, 2016 11:23 AM >> >> To: oauth@ietf.org >> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >> >>=20 >> >> Hi all, >> >>=20 >> >> On January 19th I posted a call for adoption of the Authentication = Method Reference Values specification, see = http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html = >> >>=20 >> >> What surprised us is that this work is conceptually very simple: = we define new claims and create a registry with new values. Not a big = deal but that's not what the feedback from the Yokohama IETF meeting and = the subsequent call for adoption on the list shows. The feedback lead to = mixed feelings and it is a bit difficult for Derek and myself to judge = consensus. >> >>=20 >> >> Let me tell you what we see from the comments on the list. >> >>=20 >> >> In his review at >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items. >> >>=20 >> >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html = >> >>=20 >> >> Justin is certainly the reviewer with the strongest opinion. Here = is one of his posts: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html = >> >>=20 >> >> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. >> >>=20 >> >> John agrees with Justin in >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html = that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the >> >> list: = http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html = >> >> Most of them require more than just editing work. For example, = methods listed are really not useful, >> >>=20 >> >> Phil agrees with the document adoption but has some remarks about = the registry although he does not propose specific text. His review is = here: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html = >> >>=20 >> >> With my co-chair hat on: I just wanted to clarify that registering = claims (and values within those claims) is within the scope of the OAuth = working group. We standardized the JWT in this group and we are also = chartered to standardize claims, as we are currently doing with various = drafts. Not standardizing JWT in the IETF would have lead to reduced = interoperability and less security. I have no doubts that was a wrong = decision. >> >>=20 >> >> In its current form, there is not enough support to have this = document as a WG item. >> >>=20 >> >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: >> >>=20 >> >> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John. >> >>=20 >> >> * Change the registry policy, which would address one of the = comments from James, William, and Phil. >> >>=20 >> >> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. >> >> Is this what others want as well? >> >>=20 >> >> After these items have been addressed we believe that more folks = in the group will support the document. >> >>=20 >> >> Ciao >> >> Hannes & Derek >> >>=20 >> >>=20 >> >>=20 >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth = >> >=20 >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> =E2=80=94 Roland >>=20 >> =E2=80=9DEverybody should be quiet near a little stream and listen." >> =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1F5A5293-AB6B-400C-B2F3-C557826FE444 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Can we just do that, then? Seems to be the easiest way to = address various needs and concerns. 

 =E2=80=94 Justin

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

Yes

Phil

On = Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish = the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference = Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread = probably don=E2=80=99t have is that an IANA registry can only be = established by an RFC.  Non-RFC specifications, such as OpenID specifications, can *register* values in a registry, = but they cannot *establish* a registry.  The = OpenID Foundation inquired about this with the IETF before OpenID = Connect was finalized and learned that its specifications could not = establish IANA registries.  Otherwise, they would have.

 

Instead, RFCs need to be created to establish = registries =E2=80=93 even for values first defined in non-RFC = specifications.  This specification is one example of doing this.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
= To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method = Reference Values: Call for Adoption Finalized

 

We clearly have this problem = between oauth and oidc. Just take a look at the discovery thread.

According to you argument I see two = options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just = publishes the registry entries. In this case, the spec should clearly = explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - = than define it and motivate it's use in oauth in this spec.

Right now, I think it creates = the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry = for JWT being in OAuth.   Many protocols that use JWT are going to = want to register claims.  

We can=E2=80=99t ask them to all = move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part = of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for = JWT and it=E2=80=99s registry, and we will need to deal with registering = claims.  

 

I guess that we can tell people = that they need to publish the specs defining the claims someplace else, = and just do the registry part.

However doing that will probably = not improve interoperability and understanding.

 

This document defines the claim = for JWT in general.  We still have almost no documentation in the = WG about what a JWT access token would contain other than the POP = work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically = support adoption of this document. Asserting authentication methods in = access tokens (in this case in JWTS format) is reasonable. We use it to = pass information about the authentication performed prior issuing an access token to the = _resource_ server.

What = worries me is the back and forth between oauth and oidc. The amr claim = is defined in oidc (which sits on top of oauth) but the oauth wg = specifies the registry? Moreover, the current text does not give a rationale for using amr in context of = oauth.

As a WG we = need to find a clear delineation between both protocols, otherwise noone = will really understand the difference and when to use what. We create = confusion!

For this = particular draft this means to either move amr to oauth or the registry = to oidc.

best = regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>: >
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting = the request parameter, noting that this spec isn't an encouragement to = use OAuth 2.0 for authentication without employing appropriate = extensions, and no longer requiring a specification for IANA registration.  I believe that it=E2=80=99s now ready for working = group adoption.
>>
= >>           =             &n= bsp;           &nbs= p;            =            -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the = Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.htm= l
>>
>> What surprised us is that this work is conceptually very = simple: we define new claims and create a registry with new values. Not = a big deal but that's not what the feedback from the Yokohama IETF = meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek = and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.htm= l James Manger asks for significant changes. Among other things, he = wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.htm= l
>>
>> Justin is certainly the reviewer with the strongest opinion. = Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.htm= l
>>
>> Among all concerns Justin expressed the following one is = actually actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.htm= l that we need to make sure that people are not mislead about the = intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, = methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks = about the registry although he does not propose specific text. His = review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.htm= l
>>
>> With my co-chair hat on: I just wanted to clarify that = registering claims (and values within those claims) is within the scope = of the OAuth working group. We standardized the JWT in this group and we = are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have = lead to reduced interoperability and less security. I have no doubts = that was a wrong decision.
>>
>> In its current form, there is not enough support to have this = document as a WG item.
>>
>> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the = comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be = countered with an alternative proposal. James wanted to remove the = "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more = folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


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

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

 

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

= --Apple-Mail=_1F5A5293-AB6B-400C-B2F3-C557826FE444-- From nobody Sat Feb 13 12:19:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1ED21A6FE7 for ; Sat, 13 Feb 2016 12:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avtbR7eqQkrz for ; Sat, 13 Feb 2016 12:19:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1FD11A6FE1 for ; Sat, 13 Feb 2016 12:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vDqzOfamYESjZytlVvv8VJfwyBweJ8AV5HXs2+fcczA=; b=jOYj+h3RSOBbeHZ9NnwjTFwymlEW+ODNU8KC5TyUOvLq+KgVV+oxILbM7l3oy1iBMxlVxuhLYVdbUcYC7SBd3399BfO/plm+JY7pAJ2fvf7v2mJLW0s4mWLH2j3PWRiZc2RHsL8osrrjNgkmDoMdTrDfsdSRo7GNCTmm2jKXHf4= Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 13 Feb 2016 20:19:05 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0409.017; Sat, 13 Feb 2016 20:19:05 +0000 From: Mike Jones To: Justin Richer , Phil Hunt Thread-Topic: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized Thread-Index: AdFlW5fqU0LQGAlJR6KxWxWGgVl2aAAUrDaAAAGd9IAAKPmtAAAEEECAAADCm4AAANkOkAACCeUAAABOrgAABmb6gAACXO8k Date: Sat, 13 Feb 2016 20:19:04 +0000 Message-ID: References: , <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> In-Reply-To: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.207.228.92] x-ms-office365-filtering-correlation-id: 4c1b48cf-1ff8-497f-72cc-08d334b2ebb9 x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:OuidQULe/bQgFhNIZCcdFws6q4MwkAI4IjeWdsyWWeqOnxZegtYz7z8bKwEDEinkzeNQTNCiLiLZSs6TqVXe+OWMqcRxaLfcVNKHOCBQSaDoH92G31Q9HPXao8jkkGIIFdxTaycJJzarxOXYLNlgQw==; 24:gOvi3R//weOgVwbSYU5L0jJ2nBsVkiUdShaNoDto397HL1gilZxTTOP3JotmSBZ6dzcla2dhyAtzdkTENnOeVzGGMEfDSm0tKtTmDwNavIk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB434; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BL2PR03MB434; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51694002)(13464003)(53754006)(24454002)(377454003)(5001960100002)(50986999)(10400500002)(19580395003)(19580405001)(93886004)(5005710100001)(5004730100002)(10090500001)(76176999)(54356999)(10290500002)(3900700001)(19617315012)(2171001)(189998001)(74316001)(3660700001)(87936001)(99286002)(2950100001)(92566002)(40100003)(86362001)(4326007)(561944003)(66066001)(122556002)(86612001)(33656002)(16297215004)(15975445007)(16236675004)(5008740100001)(77096005)(5003600100002)(2900100001)(11100500001)(76576001)(6116002)(102836003)(3846002)(586003)(5001770100001)(1220700001)(1096002)(2906002)(3280700002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB433BDBFABB72EE4CFD14925F5AA0BL2PR03MB433namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2016 20:19:04.9087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB434 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 20:19:32 -0000 --_000_BL2PR03MB433BDBFABB72EE4CFD14925F5AA0BL2PR03MB433namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable It's an acceptable fallback option if the working group decides it doesn't = want to register the values that are already in production use at the time = we establish the registry. But add William points out, Google is already us= ing some of these values. Microsoft is using some of them. The OpenID MODRN= A specs are using some of them. So it seems more efficient to register them= at the same time. That would be my preference. -- Mike ________________________________ From: Justin Richer Sent: =FD2/=FD13/=FD2016 11:11 AM To: Phil Hunt Cc: Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized Can we just do that, then? Seems to be the easiest way to address various n= eeds and concerns. =97 Justin On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) > wrote: Yes Phil On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" > wrote: So basically, the RFC could also just establish the new registry and oidf c= ould feel in the values? (just trying to understand) -------- Originalnachricht -------- Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized Von: Mike Jones > An: torsten@lodderstedt.net,John Bradley > Cc: oauth@ietf.org The context that most people on this thread probably don=92t have is that a= n IANA registry can only be established by an RFC. Non-RFC specifications,= such as OpenID specifications, can *register* values in a registry, but th= ey cannot *establish* a registry. The OpenID Foundation inquired about thi= s with the IETF before OpenID Connect was finalized and learned that its sp= ecifications could not establish IANA registries. Otherwise, they would ha= ve. Instead, RFCs need to be created to establish registries =96 even for value= s first defined in non-RFC specifications. This specification is one examp= le of doing this. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@loddersted= t.net Sent: Saturday, February 13, 2016 6:37 AM To: John Bradley > Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized We clearly have this problem between oauth and oidc. Just take a look at th= e discovery thread. According to you argument I see two options: (1) amr stays an oidc claim, is used in oidc only and the oauth wg just pub= lishes the registry entries. In this case, the spec should clearly explain = this. (2) amr is of any use in oauth (although it has been invented in oidc) - th= an define it and motivate it's use in oauth in this spec. Right now, I think it creates the impression oauth is for authentication. -------- Originalnachricht -------- Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized Von: John Bradley > An: torsten@lodderstedt.net Cc: roland.hedberg@umu.se,oauth@ietf.org This is not a issue between oauth and OIDC. This has to do with the registry for JWT being in OAuth. Many protocols t= hat use JWT are going to want to register claims. We can=92t ask them to all move the parts of there specs that use JWT to OA= uth. Perhaps JWT should have been part of JOSE, but that is water under the brid= ge. The OAuth WG is responsible for JWT and it=92s registry, and we will need t= o deal with registering claims. I guess that we can tell people that they need to publish the specs definin= g the claims someplace else, and just do the registry part. However doing that will probably not improve interoperability and understan= ding. This document defines the claim for JWT in general. We still have almost n= o documentation in the WG about what a JWT access token would contain other= than the POP work. John B. On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: I basically support adoption of this document. Asserting authentication met= hods in access tokens (in this case in JWTS format) is reasonable. We use i= t to pass information about the authentication performed prior issuing an a= ccess token to the _resource_ server. What worries me is the back and forth between oauth and oidc. The amr claim= is defined in oidc (which sits on top of oauth) but the oauth wg specifies= the registry? Moreover, the current text does not give a rationale for usi= ng amr in context of oauth. As a WG we need to find a clear delineation between both protocols, otherwi= se noone will really understand the difference and when to use what. We cre= ate confusion! For this particular draft this means to either move amr to oauth or the reg= istry to oidc. best regards, Torsten. -------- Urspr=FCngliche Nachricht -------- Von: Roland Hedberg > Gesendet: Friday, February 12, 2016 05:45 PM An: oauth@ietf.org Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized +1 > 12 feb 2016 kl. 16:58 skrev John Bradley >: > > +1 to adopt this draft. > >> On Feb 12, 2016, at 3:07 AM, Mike Jones > wrote: >> >> Draft -05 incorporates the feedback described below - deleting the reque= st parameter, noting that this spec isn't an encouragement to use OAuth 2.0= for authentication without employing appropriate extensions, and no longer= requiring a specification for IANA registration. I believe that it=92s no= w ready for working group adoption. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofen= ig >> Sent: Thursday, February 4, 2016 11:23 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Ado= ption Finalized >> >> Hi all, >> >> On January 19th I posted a call for adoption of the Authentication Metho= d Reference Values specification, see http://www.ietf.org/mail-archive/web/= oauth/current/msg15402.html >> >> What surprised us is that this work is conceptually very simple: we defi= ne new claims and create a registry with new values. Not a big deal but tha= t's not what the feedback from the Yokohama IETF meeting and the subsequent= call for adoption on the list shows. The feedback lead to mixed feelings a= nd it is a bit difficult for Derek and myself to judge consensus. >> >> Let me tell you what we see from the comments on the list. >> >> In his review at >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James M= anger asks for significant changes. Among other things, he wants to remove = one of the claims. He provides a detailed review and actionable items. >> >> William Denniss believes the document is ready for adoption but agrees w= ith some of the comments from James. Here is his review: >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >> >> Justin is certainly the reviewer with the strongest opinion. Here is one= of his posts: >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >> >> Among all concerns Justin expressed the following one is actually action= able IMHO: Justin is worried that reporting how a person authenticated to a= n authorization endpoint and encouraging people to use OAuth for authentica= tion is a fine line. He believes that this document leads readers to believ= e the latter. >> >> John agrees with Justin in >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we= need to make sure that people are not mislead about the intention of the d= ocument. John also provides additional comments in this post to the >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >> Most of them require more than just editing work. For example, methods l= isted are really not useful, >> >> Phil agrees with the document adoption but has some remarks about the re= gistry although he does not propose specific text. His review is here: >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >> >> With my co-chair hat on: I just wanted to clarify that registering claim= s (and values within those claims) is within the scope of the OAuth working= group. We standardized the JWT in this group and we are also chartered to = standardize claims, as we are currently doing with various drafts. Not stan= dardizing JWT in the IETF would have lead to reduced interoperability and l= ess security. I have no doubts that was a wrong decision. >> >> In its current form, there is not enough support to have this document a= s a WG item. >> >> We believe that the document authors should address some of the easier c= omments and submit a new version. This would allow us to reach out to those= who had expressed concerns about the scope of the document to re-evaluate = their decision. A new draft version should at least address the following i= ssues: >> >> * Clarify that this document is not an encouragement for using OAuth as = an authentication protocol. I believe that this would address some of the c= oncerns raised by Justin and John. >> >> * Change the registry policy, which would address one of the comments fr= om James, William, and Phil. >> >> Various other items require discussion since they are more difficult to = address. For example, John noted that he does not like the use of request p= arameters. Unfortunately, no alternative is offered. I urge John to provide= an alternative proposal, if there is one. Also, the remark that the values= are meaningless could be countered with an alternative proposal. James wan= ted to remove the "amr_values" parameter. >> Is this what others want as well? >> >> After these items have been addressed we believe that more folks in the = group will support the document. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth =97 Roland =94Everybody should be quiet near a little stream and listen." >From =92Open House for Butterflies=92 by Ruth Krauss _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BL2PR03MB433BDBFABB72EE4CFD14925F5AA0BL2PR03MB433namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
It's an accep= table fallback option if the working group decides it doesn't want to regis= ter the values that are already in production use at the time we establish = the registry. But add William points out, Google is already using some of these values. Microsoft is using some= of them. The OpenID MODRNA specs are using some of them. So it seems more = efficient to register them at the same time.

That would be my preference.

-- Mike
From: Justin Richer
Sent: =FD2/= =FD13/=FD2016 11:11 AM
To: Phil Hunt
Cc: <oauth@ietf.org>
Subject: Re: [= OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finaliz= ed

Can we just do that, then? Seems to be the easiest way to address vari= ous needs and concerns. 

 =97 Justin

On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wr= ote:

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish t= he new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lodderste= dt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most pe= ople on this thread probably don=92t have is that an IANA registry can only= be established by an RFC.  Non-RFC specifications, such as OpenID specifications, can *register* values in = a registry, but they cannot *establish* a registry. = The OpenID Foundation inquired about this with the IETF before OpenID Conn= ect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would have.

 

Instead, RFCs need to be= created to establish registries =96 even for values first defined in non-R= FC specifications.  This specification is one example of doing this.

 

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

 

From: OAuth [mailto:oau= th-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ie= tf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference V= alues: Call for Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just tak= e a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just pub= lishes the registry entries. In this case, the spec should clearly explain = this.
(2) amr is of any use in oauth (although it has been invented in oidc) - th= an define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for aut= hentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized
Von: John Bradley <ve7jt= b@ve7jtb.com>
An: torsten@lodderste= dt.net
Cc: rola= nd.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OA= uth.   Many protocols that use JWT are going to want to register claim= s.  

We can=92t ask them to all move the parts of there s= pecs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that = is water under the bridge.  

 

The OAuth WG is responsible for JWT and it=92s regis= try, and we will need to deal with registering claims.  

 

I guess that we can tell people that they need to pu= blish the specs defining the claims someplace else, and just do the registr= y part.

However doing that will probably not improve interop= erability and understanding.

 

This document defines the claim for JWT in general. =  We still have almost no documentation in the WG about what a JWT acce= ss token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically support adoption of this docu= ment. Asserting authentication methods in access tokens (in this case in JW= TS format) is reasonable. We use it to pass information about the authentic= ation performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth bet= ween oauth and oidc. The amr claim is defined in oidc (which sits on top of= oauth) but the oauth wg specifies the registry? Moreover, the current text= does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineati= on between both protocols, otherwise noone will really understand the diffe= rence and when to use what. We create confusion!

For this particular draft this means to e= ither move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=FCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wro= te:
>>
>> Draft -05 incorporates the feedback described below - deleting the= request parameter, noting that this spec isn't an encouragement to use OAu= th 2.0 for authentication without employing appropriate extensions, and no = longer requiring a specification for IANA registration.  I believe that it=92s now ready for working group adop= tion.
>>
>>           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike
>>
>> -----Original Message-----
>> From: OAuth [= mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication= Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: w= e define new claims and create a registry with new values. Not a big deal b= ut that's not what the feedback from the Yokohama IETF meeting and the subs= equent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek an= d myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James = Manger asks for significant changes. Among other things, he wants to remove= one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but ag= rees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here = is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person authenticate= d to an authorization endpoint and encouraging people to use OAuth for auth= entication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that w= e need to make sure that people are not mislead about the intention of the = document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, met= hods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about = the registry although he does not propose specific text. His review is here= :
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering= claims (and values within those claims) is within the scope of the OAuth w= orking group. We standardized the JWT in this group and we are also charter= ed to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have le= ad to reduced interoperability and less security. I have no doubts that was= a wrong decision.
>>
>> In its current form, there is not enough support to have this docu= ment as a WG item.
>>
>> We believe that the document authors should address some of the ea= sier comments and submit a new version. This would allow us to reach out to= those who had expressed concerns about the scope of the document to re-eva= luate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAu= th as an authentication protocol. I believe that this would address some of= the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comme= nts from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficu= lt to address. For example, John noted that he does not like the use of req= uest parameters. Unfortunately, no alternative is offered. I urge John to p= rovide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countere= d with an alternative proposal. James wanted to remove the "amr_values= " parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks i= n the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> htt= ps://www.ietf.org/mailman/listinfo/oauth

=97 Roland

=94Everybody should be quiet near a little stream and listen."
>From =92Open House for Butterflies=92 by Ruth Krauss


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

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

 

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

--_000_BL2PR03MB433BDBFABB72EE4CFD14925F5AA0BL2PR03MB433namprd_-- From nobody Sat Feb 13 17:13:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5831B3611 for ; Sat, 13 Feb 2016 17:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0eZsKFl6QwP for ; Sat, 13 Feb 2016 17:13:27 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A80B1B3610 for ; Sat, 13 Feb 2016 17:13:26 -0800 (PST) X-AuditID: 12074424-713ff70000000fca-9a-56bfd4b53041 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 04.A0.04042.5B4DFB65; Sat, 13 Feb 2016 20:13:25 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1E1DOoE023863; Sat, 13 Feb 2016 20:13:24 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1E1DMvv004657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Feb 2016 20:13:23 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_759F8CAB-FFEB-4E27-A046-F402E6DE69D3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Sat, 13 Feb 2016 20:13:22 -0500 Message-Id: <4EC076CD-09C1-42E4-869C-903312A24CAB@mit.edu> References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> To: Mike Jones X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0d16ZX+YwdN/fBZ7p31isTj59hWb xYL5jewOzB5Llvxk8mjd8Zfd4+PTWywBzFFcNimpOZllqUX6dglcGb/OGRXsXc5UsfzgTZYG xqt/GbsYOTkkBEwklly4xNTFyMUhJNDGJHHk2h1WCGcjo8TLm3+gnNtMElsW3mfrYuTgYBZI kNi6lxOkm1dAT+LVrcusILawQLTEhVULmUFsNgFVielrWphAbE6g+OSfv5lAWlmA4ssfJoKE mQU8JT5Nn84CMcZKYtq8RmaIVUeZJLbfuQSWEBHQkXh88RsbxKWyErt/P2KawMg/C+GKWUiu mAU2Vlti2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuu l5tZopeaUrqJERzsLio7GJsPKR1iFOBgVOLh3bFyf5gQa2JZcWXuIUZJDiYlUd5lv/eFCfEl 5adUZiQWZ8QXleakFh9ilOBgVhLhfbARqJw3JbGyKrUoHyYlzcGiJM776NfOMCGB9MSS1OzU 1ILUIpisDAeHkgQvy2WgRsGi1PTUirTMnBKENBMHJ8hwHqDhHiA1vMUFibnFmekQ+VOMilLi vGwgCQGQREZpHlwvKBklvD1s+opRHOgVYV5PkCoeYCKD634FNJgJaHDF7X0gg0sSEVJSDYxd e2N2t8+4umrH6xjPf7MuPdU7e0Rhmkrym69OH1PZc1xiNP5Fx+ibKSdut+aou1govvf2wQ0Z X/tOPJ9Xv0XcyDmvttd6h0+sm1vvD31Vu7iOnx6n2W5sbY7gCdNh/nJ9c5D5lZrt0921bMKt ok9/y5x+PKyk8P/lewmKV5Z/6tmau/DQeWMlluKMREMt5qLiRAAVIfSTIQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 01:13:32 -0000 --Apple-Mail=_759F8CAB-FFEB-4E27-A046-F402E6DE69D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99re a standard body working group. We don=E2=80=99t do = =E2=80=9Cefficient=E2=80=9D. ;) =E2=80=94 Justin > On Feb 13, 2016, at 3:19 PM, Mike Jones = wrote: >=20 > It's an acceptable fallback option if the working group decides it = doesn't want to register the values that are already in production use = at the time we establish the registry. But add William points out, = Google is already using some of these values. Microsoft is using some of = them. The OpenID MODRNA specs are using some of them. So it seems more = efficient to register them at the same time. >=20 > That would be my preference. >=20 > -- Mike > From: Justin Richer > Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM > To: Phil Hunt > Cc: > Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >=20 > Can we just do that, then? Seems to be the easiest way to address = various needs and concerns.=20 >=20 > =E2=80=94 Justin >=20 >> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) > wrote: >>=20 >> Yes >>=20 >> Phil >>=20 >> On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net = " > wrote: >>=20 >>> So basically, the RFC could also just establish the new registry and = oidf could feel in the values? >>>=20 >>> (just trying to understand) >>>=20 >>>=20 >>>=20 >>> -------- Originalnachricht -------- >>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>> Von: Mike Jones > >>> An: torsten@lodderstedt.net ,John = Bradley > >>> Cc: oauth@ietf.org >>>=20 >>> The context that most people on this thread probably don=E2=80=99t = have is that an IANA registry can only be established by an RFC. = Non-RFC specifications, such as OpenID specifications, can *register* = values in a registry, but they cannot *establish* a registry. The = OpenID Foundation inquired about this with the IETF before OpenID = Connect was finalized and learned that its specifications could not = establish IANA registries. Otherwise, they would have. >>>=20 >>> =20 >>> Instead, RFCs need to be created to establish registries =E2=80=93 = even for values first defined in non-RFC specifications. This = specification is one example of doing this. >>>=20 >>> =20 >>> -- Mike >>>=20 >>> =C2=A0 <> >>> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of torsten@lodderstedt.net = >>> Sent: Saturday, February 13, 2016 6:37 AM >>> To: John Bradley > >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>>=20 >>> =20 >>> We clearly have this problem between oauth and oidc. Just take a = look at the discovery thread. >>>=20 >>> According to you argument I see two options: >>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg = just publishes the registry entries. In this case, the spec should = clearly explain this. >>> (2) amr is of any use in oauth (although it has been invented in = oidc) - than define it and motivate it's use in oauth in this spec. >>>=20 >>> Right now, I think it creates the impression oauth is for = authentication. >>>=20 >>>=20 >>>=20 >>> -------- Originalnachricht -------- >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>> Von: John Bradley > >>> An: torsten@lodderstedt.net >>> Cc: roland.hedberg@umu.se,oauth@ietf.org = >>>=20 >>> This is not a issue between oauth and OIDC. >>>=20 >>> =20 >>> This has to do with the registry for JWT being in OAuth. Many = protocols that use JWT are going to want to register claims. =20 >>>=20 >>> We can=E2=80=99t ask them to all move the parts of there specs that = use JWT to OAuth. >>>=20 >>> =20 >>> Perhaps JWT should have been part of JOSE, but that is water under = the bridge. =20 >>>=20 >>> =20 >>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and = we will need to deal with registering claims. =20 >>>=20 >>> =20 >>> I guess that we can tell people that they need to publish the specs = defining the claims someplace else, and just do the registry part. >>>=20 >>> However doing that will probably not improve interoperability and = understanding. >>>=20 >>> =20 >>> This document defines the claim for JWT in general. We still have = almost no documentation in the WG about what a JWT access token would = contain other than the POP work. >>>=20 >>> =20 >>> John B. >>>=20 >>> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net = wrote: >>>=20 >>> =20 >>> I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server. >>>=20 >>> What worries me is the back and forth between oauth and oidc. The = amr claim is defined in oidc (which sits on top of oauth) but the oauth = wg specifies the registry? Moreover, the current text does not give a = rationale for using amr in context of oauth. >>>=20 >>> As a WG we need to find a clear delineation between both protocols, = otherwise noone will really understand the difference and when to use = what. We create confusion! >>>=20 >>> For this particular draft this means to either move amr to oauth or = the registry to oidc. >>>=20 >>> best regards,=20 >>> Torsten. >>>=20 >>>=20 >>>=20 >>> -------- Urspr=C3=BCngliche Nachricht -------- >>> Von: Roland Hedberg > >>> Gesendet: Friday, February 12, 2016 05:45 PM >>> An: oauth@ietf.org >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>>=20 >>> +1 >>>=20 >>> > 12 feb 2016 kl. 16:58 skrev John Bradley >: >>> >=20 >>> > +1 to adopt this draft. >>> >=20 >>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones = > = wrote: >>> >>=20 >>> >> Draft -05 incorporates the feedback described below - deleting = the request parameter, noting that this spec isn't an encouragement to = use OAuth 2.0 for authentication without employing appropriate = extensions, and no longer requiring a specification for IANA = registration. I believe that it=E2=80=99s now ready for working group = adoption. >>> >>=20 >>> >> -- Mike >>> >>=20 >>> >> -----Original Message----- >>> >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >>> >> Sent: Thursday, February 4, 2016 11:23 AM >>> >> To: oauth@ietf.org >>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>> >>=20 >>> >> Hi all, >>> >>=20 >>> >> On January 19th I posted a call for adoption of the = Authentication Method Reference Values specification, see = http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html = >>> >>=20 >>> >> What surprised us is that this work is conceptually very simple: = we define new claims and create a registry with new values. Not a big = deal but that's not what the feedback from the Yokohama IETF meeting and = the subsequent call for adoption on the list shows. The feedback lead to = mixed feelings and it is a bit difficult for Derek and myself to judge = consensus. >>> >>=20 >>> >> Let me tell you what we see from the comments on the list. >>> >>=20 >>> >> In his review at >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items. >>> >>=20 >>> >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html = >>> >>=20 >>> >> Justin is certainly the reviewer with the strongest opinion. Here = is one of his posts: >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html = >>> >>=20 >>> >> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. >>> >>=20 >>> >> John agrees with Justin in >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html = that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the >>> >> list: = http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html = >>> >> Most of them require more than just editing work. For example, = methods listed are really not useful, >>> >>=20 >>> >> Phil agrees with the document adoption but has some remarks about = the registry although he does not propose specific text. His review is = here: >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html = >>> >>=20 >>> >> With my co-chair hat on: I just wanted to clarify that = registering claims (and values within those claims) is within the scope = of the OAuth working group. We standardized the JWT in this group and we = are also chartered to standardize claims, as we are currently doing with = various drafts. Not standardizing JWT in the IETF would have lead to = reduced interoperability and less security. I have no doubts that was a = wrong decision. >>> >>=20 >>> >> In its current form, there is not enough support to have this = document as a WG item. >>> >>=20 >>> >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: >>> >>=20 >>> >> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John. >>> >>=20 >>> >> * Change the registry policy, which would address one of the = comments from James, William, and Phil. >>> >>=20 >>> >> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. >>> >> Is this what others want as well? >>> >>=20 >>> >> After these items have been addressed we believe that more folks = in the group will support the document. >>> >>=20 >>> >> Ciao >>> >> Hannes & Derek >>> >>=20 >>> >>=20 >>> >>=20 >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth = >>> >=20 >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> =E2=80=94 Roland >>>=20 >>> =E2=80=9DEverybody should be quiet near a little stream and listen." >>> =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>> =20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_759F8CAB-FFEB-4E27-A046-F402E6DE69D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99re a standard body working group. We don=E2=80=99t = do =E2=80=9Cefficient=E2=80=9D. ;)

 =E2=80=94 Justin

On Feb 13, 2016, at 3:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

It's an acceptable fallback option if the working group = decides it doesn't want to register the values that are already in = production use at the time we establish the registry. But add William = points out, Google is already using some of these values. Microsoft is using = some of them. The OpenID MODRNA specs are using some of them. So it = seems more efficient to register them at the same time.

That would be my preference.

-- Mike
From: Justin = Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil = Hunt
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized

Can we just do that, then? Seems to be the easiest way = to address various needs and concerns. 

 =E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could = also just establish the new registry and oidf could feel in the = values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread probably = don=E2=80=99t have is that an IANA registry can only be established by = an RFC.  Non-RFC specifications, such as OpenID specifications, can *register* values = in a registry, but they cannot *establish* a = registry.  The OpenID Foundation inquired about this with the IETF = before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would = have.

 

Instead, RFCs = need to be created to establish registries =E2=80=93 even for values = first defined in non-RFC specifications.  This specification is one = example of doing this.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
= To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method = Reference Values: Call for Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just = take a look at the discovery thread.

According to you = argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just = publishes the registry entries. In this case, the spec should clearly = explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - = than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is = for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry = for JWT being in OAuth.   Many protocols that use JWT are going to = want to register claims.  

We can=E2=80=99t ask them to all = move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part = of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for = JWT and it=E2=80=99s registry, and we will need to deal with registering = claims.  

 

I guess that we can tell people = that they need to publish the specs defining the claims someplace else, = and just do the registry part.

However doing that will probably = not improve interoperability and understanding.

 

This document defines the claim = for JWT in general.  We still have almost no documentation in the = WG about what a JWT access token would contain other than the POP = work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically support = adoption of this document. Asserting authentication methods in access = tokens (in this case in JWTS format) is reasonable. We use it to pass = information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. = The amr claim is defined in oidc (which sits on top of oauth) but the = oauth wg specifies the registry? Moreover, the current text does not = give a rationale for using amr in context of oauth.

As a WG = we need to find a clear delineation between both protocols, otherwise = noone will really understand the difference and when to use what. We = create confusion!

For this particular draft this = means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for = Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>: >
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting = the request parameter, noting that this spec isn't an encouragement to = use OAuth 2.0 for authentication without employing appropriate = extensions, and no longer requiring a specification for IANA registration.  I believe that it=E2=80=99s now ready for working = group adoption.
>>
= >>           =             &n= bsp;           &nbs= p;            =            -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the = Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>>
>> What surprised us is that this work is conceptually very = simple: we define new claims and create a registry with new values. Not = a big deal but that's not what the feedback from the Yokohama IETF = meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek = and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html = James Manger asks for significant changes. Among other things, he wants = to remove one of the claims. He provides a detailed review and = actionable items.
>>
>> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. = Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>>
>> Among all concerns Justin expressed the following one is = actually actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html = that we need to make sure that people are not mislead about the = intention of the document. John also provides additional comments in = this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, = methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks = about the registry although he does not propose specific text. His = review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that = registering claims (and values within those claims) is within the scope = of the OAuth working group. We standardized the JWT in this group and we = are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have = lead to reduced interoperability and less security. I have no doubts = that was a wrong decision.
>>
>> In its current form, there is not enough support to have this = document as a WG item.
>>
>> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the = comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be = countered with an alternative proposal. James wanted to remove the = "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more = folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


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

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

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


= --Apple-Mail=_759F8CAB-FFEB-4E27-A046-F402E6DE69D3-- From nobody Sat Feb 13 17:40:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82E41B3658 for ; Sat, 13 Feb 2016 17:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 g-8BWeaiGMBK for ; Sat, 13 Feb 2016 17:40:32 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A454B1B3654 for ; Sat, 13 Feb 2016 17:40:32 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id gc3so69734115obb.3 for ; Sat, 13 Feb 2016 17:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kMCfmBkalRmidULlJQzYZNiCqysYyg8WWF6BWiAIJyk=; b=Xh09kbRIRkaPFBAKvR3kgIA2OYnU6mL9+uQ/0f2G1rOwPwWfurEGUeGxJaU+cXGO1w yWj9cgV+Q8ecr4yNaepCicwYuGe2xP/JYQG+mJ3OsFwAhXwuGQCOiR+AuCCguGFxKK8t 9kanKXA13dkk+supIOWWoswv7QXjGlCaTSaL+la43qDR7TuXj+UqVn3JhO850h2Y5QCN hC787yETavvL9MQFMjTHIdC7r7XZxpVmsWvD9dHrb2bQeEMbvj05855qbqr3shCuQY9Q WmD2aTDTCOlsEqXO1YFrC9UwU8upskkcYq1v3lCp9tNld8LjlASEiGh4blEDygMZwkn5 8pVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kMCfmBkalRmidULlJQzYZNiCqysYyg8WWF6BWiAIJyk=; b=dhyrfMw8lT1NP58FWMG/khn7x/nJubBxJppaaaeQs/TdHbRNlpDbXCq9BMvYXaJ9kt uCnRGAAQ7dFzZ5XV/gvZoWukSVu9ygLx7ACiTJfnB68fAXMhN2hRRFdmHA+D4pkosYQq 2m7PNn469GN5eAF1gxr3ZeQKS+eTPnQai27/+E/gdZryYVe0gQvTsIJ8vqZTXmPW0ZTi cGKCANV4SMYksiwqQHVz5ejS6lNpH5BhrxyotQBGixSVNQJXTyVb6y+8oxmMXnw7soEZ p0nhvrPCNiWlYvwdv0fknBE2D4l5IsEgy8//V5Vm5dEUyT6/l1sZRUoaQ5owriAQozrW qgzg== X-Gm-Message-State: AG10YOTabfUGCsiJIVZ+6fOwNu7ILAp8o4oXQra8wxFHjmuNr+SKoLEaPE/WEG9f+Ic6V1tQ4z2wjMfkYXx5fqc6 X-Received: by 10.202.87.208 with SMTP id l199mr6754093oib.97.1455414031850; Sat, 13 Feb 2016 17:40:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Sat, 13 Feb 2016 17:40:12 -0800 (PST) In-Reply-To: References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> From: William Denniss Date: Sat, 13 Feb 2016 17:40:12 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113de9b85edf9b052bb0fce9 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 01:40:37 -0000 --001a113de9b85edf9b052bb0fce9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones wrote: > It's an acceptable fallback option if the working group decides it doesn'= t > want to register the values that are already in production use at the tim= e > we establish the registry. But add William points out, Google is already > using some of these values. Microsoft is using some of them. The OpenID > MODRNA specs are using some of them. So it seems more efficient to regist= er > them at the same time. > > That would be my preference. > +1, it is also my preference to register the current values. I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2= =80=93 they can be all be reviewed at the same time. From: Justin Richer > Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM > To: Phil Hunt > > Cc: > Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > > Can we just do that, then? Seems to be the easiest way to address various > needs and concerns. > > =E2=80=94 Justin > > On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) > wrote: > > Yes > > Phil > > On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" < > torsten@lodderstedt.net> wrote: > > So basically, the RFC could also just establish the new registry and oidf > could feel in the values? > > (just trying to understand) > > > -------- Originalnachricht -------- > Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > Von: Mike Jones > An: torsten@lodderstedt.net,John Bradley > Cc: oauth@ietf.org > > The context that most people on this thread probably don=E2=80=99t have i= s that an > IANA registry can only be established by an RFC. Non-RFC specifications, > such as OpenID specifications, can **register** values in a registry, but > they cannot **establish** a registry. The OpenID Foundation inquired > about this with the IETF before OpenID Connect was finalized and learned > that its specifications could not establish IANA registries. Otherwise, > they would have. > > > > Instead, RFCs need to be created to establish registries =E2=80=93 even f= or values > first defined in non-RFC specifications. This specification is one examp= le > of doing this. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *torsten@lodderstedt.net > *Sent:* Saturday, February 13, 2016 6:37 AM > *To:* John Bradley > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values: Call > for Adoption Finalized > > > > We clearly have this problem between oauth and oidc. Just take a look at > the discovery thread. > > According to you argument I see two options: > (1) amr stays an oidc claim, is used in oidc only and the oauth wg just > publishes the registry entries. In this case, the spec should clearly > explain this. > (2) amr is of any use in oauth (although it has been invented in oidc) - > than define it and motivate it's use in oauth in this spec. > > Right now, I think it creates the impression oauth is for authentication. > > > > -------- Originalnachricht -------- > Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > Von: John Bradley > An: torsten@lodderstedt.net > Cc: roland.hedberg@umu.se,oauth@ietf.org > > This is not a issue between oauth and OIDC. > > > > This has to do with the registry for JWT being in OAuth. Many protocols > that use JWT are going to want to register claims. > > We can=E2=80=99t ask them to all move the parts of there specs that use J= WT to > OAuth. > > > > Perhaps JWT should have been part of JOSE, but that is water under the > bridge. > > > > The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we wil= l need to > deal with registering claims. > > > > I guess that we can tell people that they need to publish the specs > defining the claims someplace else, and just do the registry part. > > However doing that will probably not improve interoperability and > understanding. > > > > This document defines the claim for JWT in general. We still have almost > no documentation in the WG about what a JWT access token would contain > other than the POP work. > > > > John B. > > On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: > > > > I basically support adoption of this document. Asserting authentication > methods in access tokens (in this case in JWTS format) is reasonable. We > use it to pass information about the authentication performed prior issui= ng > an access token to the _resource_ server. > > What worries me is the back and forth between oauth and oidc. The amr > claim is defined in oidc (which sits on top of oauth) but the oauth wg > specifies the registry? Moreover, the current text does not give a > rationale for using amr in context of oauth. > > As a WG we need to find a clear delineation between both protocols, > otherwise noone will really understand the difference and when to use wha= t. > We create confusion! > > For this particular draft this means to either move amr to oauth or the > registry to oidc. > > best regards, > Torsten. > > > > -------- Urspr=C3=BCngliche Nachricht -------- > Von: Roland Hedberg > Gesendet: Friday, February 12, 2016 05:45 PM > An: oauth@ietf.org > Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > > +1 > > > 12 feb 2016 kl. 16:58 skrev John Bradley : > > > > +1 to adopt this draft. > > > >> On Feb 12, 2016, at 3:07 AM, Mike Jones > wrote: > >> > >> Draft -05 incorporates the feedback described below - deleting the > request parameter, noting that this spec isn't an encouragement to use > OAuth 2.0 for authentication without employing appropriate extensions, an= d > no longer requiring a specification for IANA registration. I believe tha= t > it=E2=80=99s now ready for working group adoption. > >> > >> -- Mike > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org ] > On Behalf Of Hannes Tschofenig > >> Sent: Thursday, February 4, 2016 11:23 AM > >> To: oauth@ietf.org > >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > >> > >> Hi all, > >> > >> On January 19th I posted a call for adoption of the Authentication > Method Reference Values specification, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html > >> > >> What surprised us is that this work is conceptually very simple: we > define new claims and create a registry with new values. Not a big deal b= ut > that's not what the feedback from the Yokohama IETF meeting and the > subsequent call for adoption on the list shows. The feedback lead to mixe= d > feelings and it is a bit difficult for Derek and myself to judge consensu= s. > >> > >> Let me tell you what we see from the comments on the list. > >> > >> In his review at > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James > Manger asks for significant changes. Among other things, he wants to remo= ve > one of the claims. He provides a detailed review and actionable items. > >> > >> William Denniss believes the document is ready for adoption but agrees > with some of the comments from James. Here is his review: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html > >> > >> Justin is certainly the reviewer with the strongest opinion. Here is > one of his posts: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html > >> > >> Among all concerns Justin expressed the following one is actually > actionable IMHO: Justin is worried that reporting how a person > authenticated to an authorization endpoint and encouraging people to use > OAuth for authentication is a fine line. He believes that this document > leads readers to believe the latter. > >> > >> John agrees with Justin in > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that > we need to make sure that people are not mislead about the intention of t= he > document. John also provides additional comments in this post to the > >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html > >> Most of them require more than just editing work. For example, methods > listed are really not useful, > >> > >> Phil agrees with the document adoption but has some remarks about the > registry although he does not propose specific text. His review is here: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html > >> > >> With my co-chair hat on: I just wanted to clarify that registering > claims (and values within those claims) is within the scope of the OAuth > working group. We standardized the JWT in this group and we are also > chartered to standardize claims, as we are currently doing with various > drafts. Not standardizing JWT in the IETF would have lead to reduced > interoperability and less security. I have no doubts that was a wrong > decision. > >> > >> In its current form, there is not enough support to have this document > as a WG item. > >> > >> We believe that the document authors should address some of the easier > comments and submit a new version. This would allow us to reach out to > those who had expressed concerns about the scope of the document to > re-evaluate their decision. A new draft version should at least address t= he > following issues: > >> > >> * Clarify that this document is not an encouragement for using OAuth a= s > an authentication protocol. I believe that this would address some of the > concerns raised by Justin and John. > >> > >> * Change the registry policy, which would address one of the comments > from James, William, and Phil. > >> > >> Various other items require discussion since they are more difficult t= o > address. For example, John noted that he does not like the use of request > parameters. Unfortunately, no alternative is offered. I urge John to > provide an alternative proposal, if there is one. Also, the remark that t= he > values are meaningless could be countered with an alternative proposal. > James wanted to remove the "amr_values" parameter. > >> Is this what others want as well? > >> > >> After these items have been addressed we believe that more folks in th= e > group will support the document. > >> > >> Ciao > >> Hannes & Derek > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > =E2=80=94 Roland > > =E2=80=9DEverybody should be quiet near a little stream and listen." > >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113de9b85edf9b052bb0fce9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:
It's an ac= ceptable fallback option if the working group decides it doesn't want t= o register the values that are already in production use at the time we est= ablish the registry. But add William points out, Google is already using some of these values. Microsoft is using some= of them. The OpenID MODRNA specs are using some of them. So it seems more = efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.
<= div>
I don't see any harm in the spec that establishes th= e registry also seeding it with all known values in use at the time of draf= ting, regardless of the group that originally specified them. Makes the ori= ginal spec more useful, and avoids the need to submit each value for consid= eration separately =E2=80=93 they can be all be reviewed at the same time.= =C2=A0


From: Justin Richer
Sent: =E2=80= =8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [O= AUTH-WG] Authentication Method Reference Values: Call for Adoption Finalize= d

Can we just do that, then? Seems to be the easiest way to address vari= ous needs and concerns.=C2=A0

=C2=A0=E2=80=94 Justin

On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> = wrote:

So basically, the RFC could also just establish the new regi= stry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lo= dderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org<= br>

The context that most people on this = thread probably don=E2=80=99t have is that an IANA registry can only be est= ablished by an RFC.=C2=A0 Non-RFC specifications, such as OpenID specifications, can *register* values in a registry,= but they cannot *establish* a registry.=C2=A0 The OpenID Foundation= inquired about this with the IETF before OpenID Connect was finalized and = learned that its specifications could not establish IANA registries.=C2=A0 Otherwise, they would have.

=C2=A0

Instead, RFCs need to be created to e= stablish registries =E2=80=93 even for values first defined in non-RFC spec= ifications.=C2=A0 This specification is one example of doing this.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized

=C2=A0

We clearly have this problem between oauth and oidc. Just take a look at= the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just pub= lishes the registry entries. In this case, the spec should clearly explain = this.
(2) amr is of any use in oauth (although it has been invented in oidc) - th= an define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication= .



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lo= dderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

=C2=A0

This has to do with the registry for JWT being in OA= uth. =C2=A0 Many protocols that use JWT are going to want to register claim= s. =C2=A0

We can=E2=80=99t ask them to all move the parts of t= here specs that use JWT to OAuth.

=C2=A0

Perhaps JWT should have been part of JOSE, but that = is water under the bridge. =C2=A0

=C2=A0

The OAuth WG is responsible for JWT and it=E2=80=99s= registry, and we will need to deal with registering claims. =C2=A0

=C2=A0

I guess that we can tell people that they need to pu= blish the specs defining the claims someplace else, and just do the registr= y part.

However doing that will probably not improve interop= erability and understanding.

=C2=A0

This document defines the claim for JWT in general.= =C2=A0 We still have almost no documentation in the WG about what a JWT acc= ess token would contain other than the POP work.

=C2=A0

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

=C2=A0

I basically support adoption of this document. Asser= ting authentication methods in access tokens (in this case in JWTS format) = is reasonable. We use it to pass information about the authentication perfo= rmed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth = and oidc. The amr claim is defined in oidc (which sits on top of oauth) but= the oauth wg specifies the registry? Moreover, the current text does not g= ive a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between = both protocols, otherwise noone will really understand the difference and w= hen to use what. We create confusion!

For this particular draft this means to either move = amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org<= br> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Ad= option Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the= request parameter, noting that this spec isn't an encouragement to use= OAuth 2.0 for authentication without employing appropriate extensions, and= no longer requiring a specification for IANA registration.=C2=A0 I believe that it=E2=80=99s now ready for working grou= p adoption.
>>
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig >> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf= .org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication= Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: w= e define new claims and create a registry with new values. Not a big deal b= ut that's not what the feedback from the Yokohama IETF meeting and the = subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek an= d myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James = Manger asks for significant changes. Among other things, he wants to remove= one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but ag= rees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here = is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually = actionable IMHO: Justin is worried that reporting how a person authenticate= d to an authorization endpoint and encouraging people to use OAuth for auth= entication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that w= e need to make sure that people are not mislead about the intention of the = document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, met= hods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about = the registry although he does not propose specific text. His review is here= :
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering= claims (and values within those claims) is within the scope of the OAuth w= orking group. We standardized the JWT in this group and we are also charter= ed to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have le= ad to reduced interoperability and less security. I have no doubts that was= a wrong decision.
>>
>> In its current form, there is not enough support to have this docu= ment as a WG item.
>>
>> We believe that the document authors should address some of the ea= sier comments and submit a new version. This would allow us to reach out to= those who had expressed concerns about the scope of the document to re-eva= luate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAu= th as an authentication protocol. I believe that this would address some of= the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comme= nts from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficu= lt to address. For example, John noted that he does not like the use of req= uest parameters. Unfortunately, no alternative is offered. I urge John to p= rovide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countere= d with an alternative proposal. James wanted to remove the "amr_values= " parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks i= n the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen." >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


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

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

=C2=A0

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


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


--001a113de9b85edf9b052bb0fce9-- From nobody Sun Feb 14 01:53:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D191B3BBE for ; Sun, 14 Feb 2016 01:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdv7OaGIUyVQ for ; Sun, 14 Feb 2016 01:53:36 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 4B3E11B3BBF for ; Sun, 14 Feb 2016 01:53:36 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id ap4so7080214lbd.1 for ; Sun, 14 Feb 2016 01:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=ATpdquL6ftVDW8l08nIQb9g8orOeiov5DeuRUfjntxs=; b=nZszOxYJxo/NCyCuYlBeydYFPs7jxlCTAQocQP0Ybgnl4VS7uAAOReLTMUi2Rz1Jza FpdghkQW51bxkZzEj6kfEqXkX1O64PBTrjYIqy9ABcRfDQ0A6/xHHThCXmF6JkJmvAM2 XUtgpnptb46aLz60Ju5im8zaSsUwcY3qNN+4ziCrRaSAZSepiZyrt9WEVk6GZCc/GVVh CArTkMjnRVeR2hK5ekVDOb5Hr80JOScXp8FU4WKiK21UdHWmI6Yle5TvJbFiL3/n59pg yXrpyfCgeaJJ8DX6inimUUfnipk7uZpbL4utJVdQNt6wyRKK5coYfRTf/9pEdbXLTbmz IzPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ATpdquL6ftVDW8l08nIQb9g8orOeiov5DeuRUfjntxs=; b=kqUc+BqasMSLZPOgfBTZUxtcls/CYl6giGw7EJ8IMVIuddwyTiPwBFNEB8LdqH7wek OP5V3EcPoDmFLiU1xb1GDnOja2ISmOp1ENgB8V8H/lIJQUKFy6+pmsh5oSWztTRhiZN7 jD7utQ2VB0f5x21AHM0mK738VohVhBndlG+Lpf19EqSPG6MZ459BT8csESA8vs6mg0Ct 3DSDmYqlqypyOgtEsIVyizRrZl1Z5JOZqm27dprFg9dHE9BaRO1kZMV4lsj8D/aww4H6 W6HUDgT5B3eQSwsyMaP4GU7Y/LV/l52WDbUIqjitcBG+SNWJeY3B0ekaewfnonGwMrZd OI/w== X-Gm-Message-State: AG10YOQKRXA2oeAc20TkAuWfRB8cEtK88ZYXc63REBfKYvAeBAcs2fNBaoSvQrKWikvtkWdbz1X5Rrp+9s38cg== X-Received: by 10.112.91.202 with SMTP id cg10mr4321766lbb.142.1455443614578; Sun, 14 Feb 2016 01:53:34 -0800 (PST) MIME-Version: 1.0 References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> In-Reply-To: From: Thomas Broyer Date: Sun, 14 Feb 2016 09:53:24 +0000 Message-ID: To: William Denniss , Mike Jones Content-Type: multipart/alternative; boundary=001a11349ddca33ea6052bb7df07 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 09:53:38 -0000 --001a11349ddca33ea6052bb7df07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le dim. 14 f=C3=A9vr. 2016 02:40, William Denniss a = =C3=A9crit : > On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > wrote: > >> It's an acceptable fallback option if the working group decides it >> doesn't want to register the values that are already in production use a= t >> the time we establish the registry. But add William points out, Google i= s >> already using some of these values. Microsoft is using some of them. The >> OpenID MODRNA specs are using some of them. So it seems more efficient t= o >> register them at the same time. >> >> That would be my preference. >> > > +1, it is also my preference to register the current values. > +1 --001a11349ddca33ea6052bb7df07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le=C2= =A0dim. 14 f=C3=A9vr. 2016 02:40,=C2=A0William Denniss <wdenniss@google.com> a =C3= =A9crit=C2=A0:
On Sat, Feb 13, 2016 at = 12:19 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:
It's an ac= ceptable fallback option if the working group decides it doesn't want t= o register the values that are already in production use at the time we est= ablish the registry. But add William points out, Google is already using some of these values. Microsoft is using some= of them. The OpenID MODRNA specs are using some of them. So it seems more = efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current = values.

+1
--001a11349ddca33ea6052bb7df07-- From nobody Sun Feb 14 05:31:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152401A8711 for ; Sun, 14 Feb 2016 05:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Adqgj4RvXcCl for ; Sun, 14 Feb 2016 05:31:08 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (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 D64E31A903B for ; Sun, 14 Feb 2016 05:31:06 -0800 (PST) Received: from [79.218.87.147] (helo=[192.168.71.102]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aUxhX-0000Mp-Oe; Sun, 14 Feb 2016 15:31:03 +0100 To: William Denniss , Mike Jones References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> From: Torsten Lodderstedt Message-ID: <56C0816B.8070005@lodderstedt.net> Date: Sun, 14 Feb 2016 14:30:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020305020101080103040904" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 13:31:14 -0000 This is a multi-part message in MIME format. --------------020305020101080103040904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Denniss, out of curiosity: Does Google use amr values? best regards, Torsten. Am 14.02.2016 um 02:40 schrieb William Denniss: > > > On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > > wrote: > > It's an acceptable fallback option if the working group decides it > doesn't want to register the values that are already in production > use at the time we establish the registry. But add William points > out, Google is already using some of these values. Microsoft is > using some of them. The OpenID MODRNA specs are using some of > them. So it seems more efficient to register them at the same time. > > That would be my preference. > > > +1, it is also my preference to register the current values. > > I don't see any harm in the spec that establishes the registry also > seeding it with all known values in use at the time of drafting, > regardless of the group that originally specified them. Makes the > original spec more useful, and avoids the need to submit each value > for consideration separately – they can be all be reviewed at the same > time. > > > From: Justin Richer > Sent: ‎2/‎13/‎2016 11:11 AM > To: Phil Hunt > > Cc: > Subject: Re: [OAUTH-WG] Authentication Method Reference Values: > Call for Adoption Finalized > > Can we just do that, then? Seems to be the easiest way to address > various needs and concerns. > > — Justin > >> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) >> > wrote: >> >> Yes >> >> Phil >> >> On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net >> " > > wrote: >> >>> So basically, the RFC could also just establish the new registry >>> and oidf could feel in the values? >>> >>> (just trying to understand) >>> >>> >>> >>> -------- Originalnachricht -------- >>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: >>> Call for Adoption Finalized >>> Von: Mike Jones >> > >>> An: torsten@lodderstedt.net >>> ,John Bradley >> > >>> Cc: oauth@ietf.org >>> >>> The context that most people on this thread probably don’t have >>> is that an IANA registry can only be established by an RFC. >>> Non-RFC specifications, such as OpenID specifications, can >>> **register** values in a registry, but they cannot **establish** >>> a registry. The OpenID Foundation inquired about this with the >>> IETF before OpenID Connect was finalized and learned that its >>> specifications could not establish IANA registries. Otherwise, >>> they would have. >>> >>> Instead, RFCs need to be created to establish registries – even >>> for values first defined in non-RFC specifications. This >>> specification is one example of doing this. >>> >>> -- Mike >>> >>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of >>> *torsten@lodderstedt.net >>> *Sent:* Saturday, February 13, 2016 6:37 AM >>> *To:* John Bradley > >>> *Cc:* oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference >>> Values: Call for Adoption Finalized >>> >>> We clearly have this problem between oauth and oidc. Just take a >>> look at the discovery thread. >>> >>> According to you argument I see two options: >>> (1) amr stays an oidc claim, is used in oidc only and the oauth >>> wg just publishes the registry entries. In this case, the spec >>> should clearly explain this. >>> (2) amr is of any use in oauth (although it has been invented in >>> oidc) - than define it and motivate it's use in oauth in this spec. >>> >>> Right now, I think it creates the impression oauth is for >>> authentication. >>> >>> >>> >>> -------- Originalnachricht -------- >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: >>> Call for Adoption Finalized >>> Von: John Bradley > >>> An: torsten@lodderstedt.net >>> Cc: roland.hedberg@umu.se,oauth@ietf.org >>> >>> >>> This is not a issue between oauth and OIDC. >>> >>> This has to do with the registry for JWT being in OAuth. Many >>> protocols that use JWT are going to want to register claims. >>> >>> We can’t ask them to all move the parts of there specs that use >>> JWT to OAuth. >>> >>> Perhaps JWT should have been part of JOSE, but that is water >>> under the bridge. >>> >>> The OAuth WG is responsible for JWT and it’s registry, and we >>> will need to deal with registering claims. >>> >>> I guess that we can tell people that they need to publish the >>> specs defining the claims someplace else, and just do the >>> registry part. >>> >>> However doing that will probably not improve interoperability >>> and understanding. >>> >>> This document defines the claim for JWT in general. We still >>> have almost no documentation in the WG about what a JWT access >>> token would contain other than the POP work. >>> >>> John B. >>> >>> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net >>> wrote: >>> >>> I basically support adoption of this document. Asserting >>> authentication methods in access tokens (in this case in >>> JWTS format) is reasonable. We use it to pass information >>> about the authentication performed prior issuing an access >>> token to the _resource_ server. >>> >>> What worries me is the back and forth between oauth and >>> oidc. The amr claim is defined in oidc (which sits on top of >>> oauth) but the oauth wg specifies the registry? Moreover, >>> the current text does not give a rationale for using amr in >>> context of oauth. >>> >>> As a WG we need to find a clear delineation between both >>> protocols, otherwise noone will really understand the >>> difference and when to use what. We create confusion! >>> >>> For this particular draft this means to either move amr to >>> oauth or the registry to oidc. >>> >>> best regards, >>> Torsten. >>> >>> >>> >>> -------- Ursprüngliche Nachricht -------- >>> Von: Roland Hedberg >> > >>> Gesendet: Friday, February 12, 2016 05:45 PM >>> An: oauth@ietf.org >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference >>> Values: Call for Adoption Finalized >>> >>> +1 >>> >>> > 12 feb 2016 kl. 16:58 skrev John Bradley >>> >: >>> > >>> > +1 to adopt this draft. >>> > >>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones >>> >> > wrote: >>> >> >>> >> Draft -05 incorporates the feedback described below - >>> deleting the request parameter, noting that this spec isn't >>> an encouragement to use OAuth 2.0 for authentication without >>> employing appropriate extensions, and no longer requiring a >>> specification for IANA registration. I believe that it’s >>> now ready for working group adoption. >>> >> >>> >> -- Mike >>> >> >>> >> -----Original Message----- >>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of >>> Hannes Tschofenig >>> >> Sent: Thursday, February 4, 2016 11:23 AM >>> >> To: oauth@ietf.org >>> >> Subject: [OAUTH-WG] Authentication Method Reference >>> Values: Call for Adoption Finalized >>> >> >>> >> Hi all, >>> >> >>> >> On January 19th I posted a call for adoption of the >>> Authentication Method Reference Values specification, see >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html >>> >> >>> >> What surprised us is that this work is conceptually very >>> simple: we define new claims and create a registry with new >>> values. Not a big deal but that's not what the feedback from >>> the Yokohama IETF meeting and the subsequent call for >>> adoption on the list shows. The feedback lead to mixed >>> feelings and it is a bit difficult for Derek and myself to >>> judge consensus. >>> >> >>> >> Let me tell you what we see from the comments on the list. >>> >> >>> >> In his review at >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html >>> James Manger asks for significant changes. Among other >>> things, he wants to remove one of the claims. He provides a >>> detailed review and actionable items. >>> >> >>> >> William Denniss believes the document is ready for >>> adoption but agrees with some of the comments from James. >>> Here is his review: >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>> >> >>> >> Justin is certainly the reviewer with the strongest >>> opinion. Here is one of his posts: >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>> >> >>> >> Among all concerns Justin expressed the following one is >>> actually actionable IMHO: Justin is worried that reporting >>> how a person authenticated to an authorization endpoint and >>> encouraging people to use OAuth for authentication is a fine >>> line. He believes that this document leads readers to >>> believe the latter. >>> >> >>> >> John agrees with Justin in >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html >>> that we need to make sure that people are not mislead about >>> the intention of the document. John also provides additional >>> comments in this post to the >>> >> list: >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >>> >> Most of them require more than just editing work. For >>> example, methods listed are really not useful, >>> >> >>> >> Phil agrees with the document adoption but has some >>> remarks about the registry although he does not propose >>> specific text. His review is here: >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>> >> >>> >> With my co-chair hat on: I just wanted to clarify that >>> registering claims (and values within those claims) is >>> within the scope of the OAuth working group. We standardized >>> the JWT in this group and we are also chartered to >>> standardize claims, as we are currently doing with various >>> drafts. Not standardizing JWT in the IETF would have lead to >>> reduced interoperability and less security. I have no doubts >>> that was a wrong decision. >>> >> >>> >> In its current form, there is not enough support to have >>> this document as a WG item. >>> >> >>> >> We believe that the document authors should address some >>> of the easier comments and submit a new version. This would >>> allow us to reach out to those who had expressed concerns >>> about the scope of the document to re-evaluate their >>> decision. A new draft version should at least address the >>> following issues: >>> >> >>> >> * Clarify that this document is not an encouragement for >>> using OAuth as an authentication protocol. I believe that >>> this would address some of the concerns raised by Justin and >>> John. >>> >> >>> >> * Change the registry policy, which would address one of >>> the comments from James, William, and Phil. >>> >> >>> >> Various other items require discussion since they are >>> more difficult to address. For example, John noted that he >>> does not like the use of request parameters. Unfortunately, >>> no alternative is offered. I urge John to provide an >>> alternative proposal, if there is one. Also, the remark that >>> the values are meaningless could be countered with an >>> alternative proposal. James wanted to remove the >>> "amr_values" parameter. >>> >> Is this what others want as well? >>> >> >>> >> After these items have been addressed we believe that >>> more folks in the group will support the document. >>> >> >>> >> Ciao >>> >> Hannes & Derek >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> — Roland >>> >>> â€Everybody should be quiet near a little stream and listen." >>> >From ’Open House for Butterflies’ by Ruth Krauss >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020305020101080103040904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.

Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.

I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately – they can be all be reviewed at the same time. 


From: Justin Richer
Sent: ‎2/‎13/‎2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns. 

 — Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread probably don’t have is that an IANA registry can only be established by an RFC.  Non-RFC specifications, such as OpenID specifications, can *register* values in a registry, but they cannot *establish* a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would have.

 

Instead, RFCs need to be created to establish registries – even for values first defined in non-RFC specifications.  This specification is one example of doing this.

 

                                                          -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can’t ask them to all move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for JWT and it’s registry, and we will need to deal with registering claims.  

 

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 

This document defines the claim for JWT in general.  We still have almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Ursprüngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I believe that it’s now ready for working group adoption.
>>
>>                                                           -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

— Roland

â€Everybody should be quiet near a little stream and listen."
>From ’Open House for Butterflies’ by Ruth Krauss


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

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

 

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


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




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

--------------020305020101080103040904-- From nobody Sun Feb 14 06:23:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390A61ACCFF for ; Sun, 14 Feb 2016 06:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAlNyjy5G3_r for ; Sun, 14 Feb 2016 06:23:38 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (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 0A0BD1ACCFB for ; Sun, 14 Feb 2016 06:23:37 -0800 (PST) Received: from [79.218.87.147] (helo=[192.168.71.137]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aUyWM-0007Ia-FA; Sun, 14 Feb 2016 16:23:34 +0100 Date: Sun, 14 Feb 2016 15:23:25 +0100 Message-ID: In-Reply-To: <56C0816B.8070005@lodderstedt.net> References: <56C0816B.8070005@lodderstedt.net> From: "torsten@lodderstedt.net" To: Michael.Jones@microsoft.com, wdenniss@google.com, wdenniss@google.com, Michael.Jones@microsoft.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_1610206958705281" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 14:23:44 -0000 ----_com.syntomo.email_1610206958705281 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBtZWFudCBXaWxsaWFtIC0gc29ycnkhCgotLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0t LS0tLQpCZXRyZWZmOiBSZTogW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJl bmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24gRmluYWxpemVkClZvbjogVG9yc3RlbiBMb2Rk ZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+CkFuOiBXaWxsaWFtIERlbm5pc3MgPHdk ZW5uaXNzQGdvb2dsZS5jb20+LE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4KQ2M6ICI8b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc+Cgo+SGkgRGVubmlzcywK Pgo+b3V0IG9mIGN1cmlvc2l0eTogRG9lcyBHb29nbGUgdXNlIGFtciB2YWx1ZXM/Cj4KPmJlc3Qg cmVnYXJkcywKPlRvcnN0ZW4uCj4KPkFtIDE0LjAyLjIwMTYgdW0gMDI6NDAgc2NocmllYiBXaWxs aWFtIERlbm5pc3M6Cj4+Cj4+Cj4+IE9uIFNhdCwgRmViIDEzLCAyMDE2IGF0IDEyOjE5IFBNLCBN aWtlIEpvbmVzIAo+PiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIDxtYWlsdG86TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6Cj4+Cj4+ICAgICBJdCdzIGFuIGFjY2VwdGFi bGUgZmFsbGJhY2sgb3B0aW9uIGlmIHRoZSB3b3JraW5nIGdyb3VwIGRlY2lkZXMgaXQKPj4gICAg IGRvZXNuJ3Qgd2FudCB0byByZWdpc3RlciB0aGUgdmFsdWVzIHRoYXQgYXJlIGFscmVhZHkgaW4g cHJvZHVjdGlvbgo+PiAgICAgdXNlIGF0IHRoZSB0aW1lIHdlIGVzdGFibGlzaCB0aGUgcmVnaXN0 cnkuIEJ1dCBhZGQgV2lsbGlhbSBwb2ludHMKPj4gICAgIG91dCwgR29vZ2xlIGlzIGFscmVhZHkg dXNpbmcgc29tZSBvZiB0aGVzZSB2YWx1ZXMuIE1pY3Jvc29mdCBpcwo+PiAgICAgdXNpbmcgc29t ZSBvZiB0aGVtLiBUaGUgT3BlbklEIE1PRFJOQSBzcGVjcyBhcmUgdXNpbmcgc29tZSBvZgo+PiAg ICAgdGhlbS4gU28gaXQgc2VlbXMgbW9yZSBlZmZpY2llbnQgdG8gcmVnaXN0ZXIgdGhlbSBhdCB0 aGUgc2FtZSB0aW1lLgo+Pgo+PiAgICAgVGhhdCB3b3VsZCBiZSBteSBwcmVmZXJlbmNlLgo+Pgo+ Pgo+PiArMSwgaXQgaXMgYWxzbyBteSBwcmVmZXJlbmNlIHRvIHJlZ2lzdGVyIHRoZSBjdXJyZW50 IHZhbHVlcy4KPj4KPj4gSSBkb24ndCBzZWUgYW55IGhhcm0gaW4gdGhlIHNwZWMgdGhhdCBlc3Rh Ymxpc2hlcyB0aGUgcmVnaXN0cnkgYWxzbyAKPj4gc2VlZGluZyBpdCB3aXRoIGFsbCBrbm93biB2 YWx1ZXMgaW4gdXNlIGF0IHRoZSB0aW1lIG9mIGRyYWZ0aW5nLCAKPj4gcmVnYXJkbGVzcyBvZiB0 aGUgZ3JvdXAgdGhhdCBvcmlnaW5hbGx5IHNwZWNpZmllZCB0aGVtLiBNYWtlcyB0aGUgCj4+IG9y aWdpbmFsIHNwZWMgbW9yZSB1c2VmdWwsIGFuZCBhdm9pZHMgdGhlIG5lZWQgdG8gc3VibWl0IGVh Y2ggdmFsdWUgCj4+IGZvciBjb25zaWRlcmF0aW9uIHNlcGFyYXRlbHkg4oCTIHRoZXkgY2FuIGJl IGFsbCBiZSByZXZpZXdlZCBhdCB0aGUgc2FtZSAKPj4gdGltZS4KPj4KPj4KPj4gICAgIEZyb206 IEp1c3RpbiBSaWNoZXIgPG1haWx0bzpqcmljaGVyQG1pdC5lZHU+Cj4+ICAgICBTZW50OiDigI4y L+KAjjEzL+KAjjIwMTYgMTE6MTEgQU0KPj4gICAgIFRvOiBQaGlsIEh1bnQgPG1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbT4KPj4KPj4gICAgIENjOiA8b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+Cj4+ICAgICBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRoZW50aWNh dGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczoKPj4gICAgIENhbGwgZm9yIEFkb3B0aW9uIEZp bmFsaXplZAo+Pgo+PiAgICAgQ2FuIHdlIGp1c3QgZG8gdGhhdCwgdGhlbj8gU2VlbXMgdG8gYmUg dGhlIGVhc2llc3Qgd2F5IHRvIGFkZHJlc3MKPj4gICAgIHZhcmlvdXMgbmVlZHMgYW5kIGNvbmNl cm5zLgo+Pgo+PiAgICAgIOKAlCBKdXN0aW4KPj4KPj4+ICAgICBPbiBGZWIgMTMsIDIwMTYsIGF0 IDExOjA4IEFNLCBQaGlsIEh1bnQgKElETSkKPj4+ICAgICA8cGhpbC5odW50QG9yYWNsZS5jb20g PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOgo+Pj4KPj4+ICAgICBZZXMKPj4+ Cj4+PiAgICAgUGhpbAo+Pj4KPj4+ICAgICBPbiBGZWIgMTMsIDIwMTYsIGF0IDA3OjU5LCAidG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQKPj4+ICAgICA8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PiIgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj4+PiAgICAgPG1haWx0bzp0b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOgo+Pj4KPj4+PiAgICAgU28gYmFzaWNhbGx5LCB0aGUgUkZD IGNvdWxkIGFsc28ganVzdCBlc3RhYmxpc2ggdGhlIG5ldyByZWdpc3RyeQo+Pj4+ICAgICBhbmQg b2lkZiBjb3VsZCBmZWVsIGluIHRoZSB2YWx1ZXM/Cj4+Pj4KPj4+PiAgICAgKGp1c3QgdHJ5aW5n IHRvIHVuZGVyc3RhbmQpCj4+Pj4KPj4+Pgo+Pj4+Cj4+Pj4gICAgIC0tLS0tLS0tIE9yaWdpbmFs bmFjaHJpY2h0IC0tLS0tLS0tCj4+Pj4gICAgIEJldHJlZmY6IFJFOiBbT0FVVEgtV0ddIEF1dGhl bnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzOgo+Pj4+ICAgICBDYWxsIGZvciBBZG9w dGlvbiBGaW5hbGl6ZWQKPj4+PiAgICAgVm9uOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20KPj4+PiAgICAgPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ Pgo+Pj4+ICAgICBBbjogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQKPj4+PiAgICAgPG1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4sSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbQo+ Pj4+ICAgICA8bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4KPj4+PiAgICAgQ2M6IG9hdXRoQGll dGYub3JnIDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Cj4+Pj4KPj4+PiAgICAgVGhlIGNvbnRleHQg dGhhdCBtb3N0IHBlb3BsZSBvbiB0aGlzIHRocmVhZCBwcm9iYWJseSBkb27igJl0IGhhdmUKPj4+ PiAgICAgaXMgdGhhdCBhbiBJQU5BIHJlZ2lzdHJ5IGNhbiBvbmx5IGJlIGVzdGFibGlzaGVkIGJ5 IGFuIFJGQy4gCj4+Pj4gICAgIE5vbi1SRkMgc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgT3BlbklE IHNwZWNpZmljYXRpb25zLCBjYW4KPj4+PiAgICAgKipyZWdpc3RlcioqIHZhbHVlcyBpbiBhIHJl Z2lzdHJ5LCBidXQgdGhleSBjYW5ub3QgKiplc3RhYmxpc2gqKgo+Pj4+ICAgICBhIHJlZ2lzdHJ5 LiAgVGhlIE9wZW5JRCBGb3VuZGF0aW9uIGlucXVpcmVkIGFib3V0IHRoaXMgd2l0aCB0aGUKPj4+ PiAgICAgSUVURiBiZWZvcmUgT3BlbklEIENvbm5lY3Qgd2FzIGZpbmFsaXplZCBhbmQgbGVhcm5l ZCB0aGF0IGl0cwo+Pj4+ICAgICBzcGVjaWZpY2F0aW9ucyBjb3VsZCBub3QgZXN0YWJsaXNoIElB TkEgcmVnaXN0cmllcy4gT3RoZXJ3aXNlLAo+Pj4+ICAgICB0aGV5IHdvdWxkIGhhdmUuCj4+Pj4K Pj4+PiAgICAgSW5zdGVhZCwgUkZDcyBuZWVkIHRvIGJlIGNyZWF0ZWQgdG8gZXN0YWJsaXNoIHJl Z2lzdHJpZXMg4oCTIGV2ZW4KPj4+PiAgICAgZm9yIHZhbHVlcyBmaXJzdCBkZWZpbmVkIGluIG5v bi1SRkMgc3BlY2lmaWNhdGlvbnMuICBUaGlzCj4+Pj4gICAgIHNwZWNpZmljYXRpb24gaXMgb25l IGV4YW1wbGUgb2YgZG9pbmcgdGhpcy4KPj4+Pgo+Pj4+ICAgICAtLSBNaWtlCj4+Pj4KPj4+PiAg ICAgKkZyb206Kk9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFs ZiBPZgo+Pj4+ICAgICAqdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQgPG1haWx0bzp0b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldD4KPj4+PiAgICAgKlNlbnQ6KiBTYXR1cmRheSwgRmVicnVhcnkgMTMsIDIw MTYgNjozNyBBTQo+Pj4+ICAgICAqVG86KiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29t IDxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pgo+Pj4+ICAgICAqQ2M6KiBvYXV0aEBpZXRmLm9y ZyA8bWFpbHRvOm9hdXRoQGlldGYub3JnPgo+Pj4+ICAgICAqU3ViamVjdDoqIFJlOiBbT0FVVEgt V0ddIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UKPj4+PiAgICAgVmFsdWVzOiBDYWxs IGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKPj4+Pgo+Pj4+ICAgICBXZSBjbGVhcmx5IGhhdmUgdGhp cyBwcm9ibGVtIGJldHdlZW4gb2F1dGggYW5kIG9pZGMuIEp1c3QgdGFrZSBhCj4+Pj4gICAgIGxv b2sgYXQgdGhlIGRpc2NvdmVyeSB0aHJlYWQuCj4+Pj4KPj4+PiAgICAgQWNjb3JkaW5nIHRvIHlv dSBhcmd1bWVudCBJIHNlZSB0d28gb3B0aW9uczoKPj4+PiAgICAgKDEpIGFtciBzdGF5cyBhbiBv aWRjIGNsYWltLCBpcyB1c2VkIGluIG9pZGMgb25seSBhbmQgdGhlIG9hdXRoCj4+Pj4gICAgIHdn IGp1c3QgcHVibGlzaGVzIHRoZSByZWdpc3RyeSBlbnRyaWVzLiBJbiB0aGlzIGNhc2UsIHRoZSBz cGVjCj4+Pj4gICAgIHNob3VsZCBjbGVhcmx5IGV4cGxhaW4gdGhpcy4KPj4+PiAgICAgKDIpIGFt ciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoIChhbHRob3VnaCBpdCBoYXMgYmVlbiBpbnZlbnRlZCBp bgo+Pj4+ICAgICBvaWRjKSAtIHRoYW4gZGVmaW5lIGl0IGFuZCBtb3RpdmF0ZSBpdCdzIHVzZSBp biBvYXV0aCBpbiB0aGlzIHNwZWMuCj4+Pj4KPj4+PiAgICAgUmlnaHQgbm93LCBJIHRoaW5rIGl0 IGNyZWF0ZXMgdGhlIGltcHJlc3Npb24gb2F1dGggaXMgZm9yCj4+Pj4gICAgIGF1dGhlbnRpY2F0 aW9uLgo+Pj4+Cj4+Pj4KPj4+Pgo+Pj4+ICAgICAtLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAt LS0tLS0tLQo+Pj4+ICAgICBCZXRyZWZmOiBSZTogW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBN ZXRob2QgUmVmZXJlbmNlIFZhbHVlczoKPj4+PiAgICAgQ2FsbCBmb3IgQWRvcHRpb24gRmluYWxp emVkCj4+Pj4gICAgIFZvbjogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbSA8bWFpbHRv OnZlN2p0YkB2ZTdqdGIuY29tPj4KPj4+PiAgICAgQW46IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 IDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Cj4+Pj4gICAgIENjOiByb2xhbmQuaGVk YmVyZ0B1bXUuc2Usb2F1dGhAaWV0Zi5vcmcKPj4+PiAgICAgPG1haWx0bzpyb2xhbmQuaGVkYmVy Z0B1bXUuc2Usb2F1dGhAaWV0Zi5vcmc+Cj4+Pj4KPj4+PiAgICAgVGhpcyBpcyBub3QgYSBpc3N1 ZSBiZXR3ZWVuIG9hdXRoIGFuZCBPSURDLgo+Pj4+Cj4+Pj4gICAgIFRoaXMgaGFzIHRvIGRvIHdp dGggdGhlIHJlZ2lzdHJ5IGZvciBKV1QgYmVpbmcgaW4gT0F1dGguICAgTWFueQo+Pj4+ICAgICBw cm90b2NvbHMgdGhhdCB1c2UgSldUIGFyZSBnb2luZyB0byB3YW50IHRvIHJlZ2lzdGVyIGNsYWlt cy4KPj4+Pgo+Pj4+ICAgICBXZSBjYW7igJl0IGFzayB0aGVtIHRvIGFsbCBtb3ZlIHRoZSBwYXJ0 cyBvZiB0aGVyZSBzcGVjcyB0aGF0IHVzZQo+Pj4+ICAgICBKV1QgdG8gT0F1dGguCj4+Pj4KPj4+ PiAgICAgUGVyaGFwcyBKV1Qgc2hvdWxkIGhhdmUgYmVlbiBwYXJ0IG9mIEpPU0UsIGJ1dCB0aGF0 IGlzIHdhdGVyCj4+Pj4gICAgIHVuZGVyIHRoZSBicmlkZ2UuCj4+Pj4KPj4+PiAgICAgVGhlIE9B dXRoIFdHIGlzIHJlc3BvbnNpYmxlIGZvciBKV1QgYW5kIGl04oCZcyByZWdpc3RyeSwgYW5kIHdl Cj4+Pj4gICAgIHdpbGwgbmVlZCB0byBkZWFsIHdpdGggcmVnaXN0ZXJpbmcgY2xhaW1zLgo+Pj4+ Cj4+Pj4gICAgIEkgZ3Vlc3MgdGhhdCB3ZSBjYW4gdGVsbCBwZW9wbGUgdGhhdCB0aGV5IG5lZWQg dG8gcHVibGlzaCB0aGUKPj4+PiAgICAgc3BlY3MgZGVmaW5pbmcgdGhlIGNsYWltcyBzb21lcGxh Y2UgZWxzZSwgYW5kIGp1c3QgZG8gdGhlCj4+Pj4gICAgIHJlZ2lzdHJ5IHBhcnQuCj4+Pj4KPj4+ PiAgICAgSG93ZXZlciBkb2luZyB0aGF0IHdpbGwgcHJvYmFibHkgbm90IGltcHJvdmUgaW50ZXJv cGVyYWJpbGl0eQo+Pj4+ICAgICBhbmQgdW5kZXJzdGFuZGluZy4KPj4+Pgo+Pj4+ICAgICBUaGlz IGRvY3VtZW50IGRlZmluZXMgdGhlIGNsYWltIGZvciBKV1QgaW4gZ2VuZXJhbC4gIFdlIHN0aWxs Cj4+Pj4gICAgIGhhdmUgYWxtb3N0IG5vIGRvY3VtZW50YXRpb24gaW4gdGhlIFdHIGFib3V0IHdo YXQgYSBKV1QgYWNjZXNzCj4+Pj4gICAgIHRva2VuIHdvdWxkIGNvbnRhaW4gb3RoZXIgdGhhbiB0 aGUgUE9QIHdvcmsuCj4+Pj4KPj4+PiAgICAgSm9obiBCLgo+Pj4+Cj4+Pj4gICAgICAgICBPbiBG ZWIgMTMsIDIwMTYsIGF0IDk6MTggQU0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj4+Pj4gICAg ICAgICA8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToKPj4+Pgo+Pj4+ICAg ICAgICAgSSBiYXNpY2FsbHkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBBc3Nl cnRpbmcKPj4+PiAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgaW4gYWNjZXNzIHRva2Vu cyAoaW4gdGhpcyBjYXNlIGluCj4+Pj4gICAgICAgICBKV1RTIGZvcm1hdCkgaXMgcmVhc29uYWJs ZS4gV2UgdXNlIGl0IHRvIHBhc3MgaW5mb3JtYXRpb24KPj4+PiAgICAgICAgIGFib3V0IHRoZSBh dXRoZW50aWNhdGlvbiBwZXJmb3JtZWQgcHJpb3IgaXNzdWluZyBhbiBhY2Nlc3MKPj4+PiAgICAg ICAgIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfIHNlcnZlci4KPj4+Pgo+Pj4+ICAgICAgICAgV2hh dCB3b3JyaWVzIG1lIGlzIHRoZSBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVuIG9hdXRoIGFuZAo+Pj4+ ICAgICAgICAgb2lkYy4gVGhlIGFtciBjbGFpbSBpcyBkZWZpbmVkIGluIG9pZGMgKHdoaWNoIHNp dHMgb24gdG9wIG9mCj4+Pj4gICAgICAgICBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3ZyBzcGVjaWZp ZXMgdGhlIHJlZ2lzdHJ5PyBNb3Jlb3ZlciwKPj4+PiAgICAgICAgIHRoZSBjdXJyZW50IHRleHQg ZG9lcyBub3QgZ2l2ZSBhIHJhdGlvbmFsZSBmb3IgdXNpbmcgYW1yIGluCj4+Pj4gICAgICAgICBj b250ZXh0IG9mIG9hdXRoLgo+Pj4+Cj4+Pj4gICAgICAgICBBcyBhIFdHIHdlIG5lZWQgdG8gZmlu ZCBhIGNsZWFyIGRlbGluZWF0aW9uIGJldHdlZW4gYm90aAo+Pj4+ICAgICAgICAgcHJvdG9jb2xz LCBvdGhlcndpc2Ugbm9vbmUgd2lsbCByZWFsbHkgdW5kZXJzdGFuZCB0aGUKPj4+PiAgICAgICAg IGRpZmZlcmVuY2UgYW5kIHdoZW4gdG8gdXNlIHdoYXQuIFdlIGNyZWF0ZSBjb25mdXNpb24hCj4+ Pj4KPj4+PiAgICAgICAgIEZvciB0aGlzIHBhcnRpY3VsYXIgZHJhZnQgdGhpcyBtZWFucyB0byBl aXRoZXIgbW92ZSBhbXIgdG8KPj4+PiAgICAgICAgIG9hdXRoIG9yIHRoZSByZWdpc3RyeSB0byBv aWRjLgo+Pj4+Cj4+Pj4gICAgICAgICBiZXN0IHJlZ2FyZHMsCj4+Pj4gICAgICAgICBUb3JzdGVu Lgo+Pj4+Cj4+Pj4KPj4+Pgo+Pj4+ICAgICAgICAgLS0tLS0tLS0gVXJzcHLDvG5nbGljaGUgTmFj aHJpY2h0IC0tLS0tLS0tCj4+Pj4gICAgICAgICBWb246IFJvbGFuZCBIZWRiZXJnIDxyb2xhbmQu aGVkYmVyZ0B1bXUuc2UKPj4+PiAgICAgICAgIDxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNl Pj4KPj4+PiAgICAgICAgIEdlc2VuZGV0OiBGcmlkYXksIEZlYnJ1YXJ5IDEyLCAyMDE2IDA1OjQ1 IFBNCj4+Pj4gICAgICAgICBBbjogb2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4KPj4+PiAgICAgICAgIEJldHJlZmY6IFJlOiBbT0FVVEgtV0ddIEF1dGhlbnRpY2F0aW9uIE1l dGhvZCBSZWZlcmVuY2UKPj4+PiAgICAgICAgIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24gRmlu YWxpemVkCj4+Pj4KPj4+PiAgICAgICAgICsxCj4+Pj4KPj4+PiAgICAgICAgID4gMTIgZmViIDIw MTYga2wuIDE2OjU4IHNrcmV2IEpvaG4gQnJhZGxleQo+Pj4+ICAgICAgICAgPHZlN2p0YkB2ZTdq dGIuY29tIDxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoKPj4+PiAgICAgICAgID4KPj4+PiAg ICAgICAgID4gKzEgdG8gYWRvcHQgdGhpcyBkcmFmdC4KPj4+PiAgICAgICAgID4KPj4+PiAgICAg ICAgID4+IE9uIEZlYiAxMiwgMjAxNiwgYXQgMzowNyBBTSwgTWlrZSBKb25lcwo+Pj4+ICAgICAg ICAgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbQo+Pj4+ICAgICAgICAgPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToKPj4+PiAgICAgICAgID4+Cj4+Pj4gICAg ICAgICA+PiBEcmFmdCAtMDUgaW5jb3Jwb3JhdGVzIHRoZSBmZWVkYmFjayBkZXNjcmliZWQgYmVs b3cgLQo+Pj4+ICAgICAgICAgZGVsZXRpbmcgdGhlIHJlcXVlc3QgcGFyYW1ldGVyLCBub3Rpbmcg dGhhdCB0aGlzIHNwZWMgaXNuJ3QKPj4+PiAgICAgICAgIGFuIGVuY291cmFnZW1lbnQgdG8gdXNl IE9BdXRoIDIuMCBmb3IgYXV0aGVudGljYXRpb24gd2l0aG91dAo+Pj4+ICAgICAgICAgZW1wbG95 aW5nIGFwcHJvcHJpYXRlIGV4dGVuc2lvbnMsIGFuZCBubyBsb25nZXIgcmVxdWlyaW5nIGEKPj4+ PiAgICAgICAgIHNwZWNpZmljYXRpb24gZm9yIElBTkEgcmVnaXN0cmF0aW9uLiAgSSBiZWxpZXZl IHRoYXQgaXTigJlzCj4+Pj4gICAgICAgICBub3cgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgYWRv cHRpb24uCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgPj4gLS0gTWlrZQo+Pj4+ICAgICAg ICAgPj4KPj4+PiAgICAgICAgID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+Pj4gICAg ICAgICA+PiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZgo+Pj4+ICAgICAgICAgSGFubmVzIFRzY2hvZmVuaWcKPj4+PiAgICAgICAgID4+IFNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSA0LCAyMDE2IDExOjIzIEFNCj4+Pj4gICAgICAgICA+PiBU bzogb2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4KPj4+PiAgICAgICAgID4+ IFN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZQo+Pj4+ ICAgICAgICAgVmFsdWVzOiBDYWxsIGZvciBBZG9wdGlvbiBGaW5hbGl6ZWQKPj4+PiAgICAgICAg ID4+Cj4+Pj4gICAgICAgICA+PiBIaSBhbGwsCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAg Pj4gT24gSmFudWFyeSAxOXRoIEkgcG9zdGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlCj4+ Pj4gICAgICAgICBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBzcGVjaWZp Y2F0aW9uLCBzZWUKPj4+PiAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDAyLmh0bWwKPj4+PiAgICAgICAgID4+Cj4+Pj4gICAg ICAgICA+PiBXaGF0IHN1cnByaXNlZCB1cyBpcyB0aGF0IHRoaXMgd29yayBpcyBjb25jZXB0dWFs bHkgdmVyeQo+Pj4+ICAgICAgICAgc2ltcGxlOiB3ZSBkZWZpbmUgbmV3IGNsYWltcyBhbmQgY3Jl YXRlIGEgcmVnaXN0cnkgd2l0aCBuZXcKPj4+PiAgICAgICAgIHZhbHVlcy4gTm90IGEgYmlnIGRl YWwgYnV0IHRoYXQncyBub3Qgd2hhdCB0aGUgZmVlZGJhY2sgZnJvbQo+Pj4+ICAgICAgICAgdGhl IFlva29oYW1hIElFVEYgbWVldGluZyBhbmQgdGhlIHN1YnNlcXVlbnQgY2FsbCBmb3IKPj4+PiAg ICAgICAgIGFkb3B0aW9uIG9uIHRoZSBsaXN0IHNob3dzLiBUaGUgZmVlZGJhY2sgbGVhZCB0byBt aXhlZAo+Pj4+ICAgICAgICAgZmVlbGluZ3MgYW5kIGl0IGlzIGEgYml0IGRpZmZpY3VsdCBmb3Ig RGVyZWsgYW5kIG15c2VsZiB0bwo+Pj4+ICAgICAgICAganVkZ2UgY29uc2Vuc3VzLgo+Pj4+ICAg ICAgICAgPj4KPj4+PiAgICAgICAgID4+IExldCBtZSB0ZWxsIHlvdSB3aGF0IHdlIHNlZSBmcm9t IHRoZSBjb21tZW50cyBvbiB0aGUgbGlzdC4KPj4+PiAgICAgICAgID4+Cj4+Pj4gICAgICAgICA+ PiBJbiBoaXMgcmV2aWV3IGF0Cj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MjMuaHRtbAo+ Pj4+ICAgICAgICAgSmFtZXMgTWFuZ2VyIGFza3MgZm9yIHNpZ25pZmljYW50IGNoYW5nZXMuIEFt b25nIG90aGVyCj4+Pj4gICAgICAgICB0aGluZ3MsIGhlIHdhbnRzIHRvIHJlbW92ZSBvbmUgb2Yg dGhlIGNsYWltcy4gSGUgcHJvdmlkZXMgYQo+Pj4+ICAgICAgICAgZGV0YWlsZWQgcmV2aWV3IGFu ZCBhY3Rpb25hYmxlIGl0ZW1zLgo+Pj4+ICAgICAgICAgPj4KPj4+PiAgICAgICAgID4+IFdpbGxp YW0gRGVubmlzcyBiZWxpZXZlcyB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yCj4+Pj4gICAgICAg ICBhZG9wdGlvbiBidXQgYWdyZWVzIHdpdGggc29tZSBvZiB0aGUgY29tbWVudHMgZnJvbSBKYW1l cy4KPj4+PiAgICAgICAgIEhlcmUgaXMgaGlzIHJldmlldzoKPj4+PiAgICAgICAgID4+Cj4+Pj4g ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu dC9tc2cxNTQyNi5odG1sCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgPj4gSnVzdGluIGlz IGNlcnRhaW5seSB0aGUgcmV2aWV3ZXIgd2l0aCB0aGUgc3Ryb25nZXN0Cj4+Pj4gICAgICAgICBv cGluaW9uLiBIZXJlIGlzIG9uZSBvZiBoaXMgcG9zdHM6Cj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv bXNnMTU0NTcuaHRtbAo+Pj4+ICAgICAgICAgPj4KPj4+PiAgICAgICAgID4+IEFtb25nIGFsbCBj b25jZXJucyBKdXN0aW4gZXhwcmVzc2VkIHRoZSBmb2xsb3dpbmcgb25lIGlzCj4+Pj4gICAgICAg ICBhY3R1YWxseSBhY3Rpb25hYmxlIElNSE86IEp1c3RpbiBpcyB3b3JyaWVkIHRoYXQgcmVwb3J0 aW5nCj4+Pj4gICAgICAgICBob3cgYSBwZXJzb24gYXV0aGVudGljYXRlZCB0byBhbiBhdXRob3Jp emF0aW9uIGVuZHBvaW50IGFuZAo+Pj4+ICAgICAgICAgZW5jb3VyYWdpbmcgcGVvcGxlIHRvIHVz ZSBPQXV0aCBmb3IgYXV0aGVudGljYXRpb24gaXMgYSBmaW5lCj4+Pj4gICAgICAgICBsaW5lLiBI ZSBiZWxpZXZlcyB0aGF0IHRoaXMgZG9jdW1lbnQgbGVhZHMgcmVhZGVycyB0bwo+Pj4+ICAgICAg ICAgYmVsaWV2ZSB0aGUgbGF0dGVyLgo+Pj4+ICAgICAgICAgPj4KPj4+PiAgICAgICAgID4+IEpv aG4gYWdyZWVzIHdpdGggSnVzdGluIGluCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NDgu aHRtbAo+Pj4+ICAgICAgICAgdGhhdCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHBlb3BsZSBh cmUgbm90IG1pc2xlYWQgYWJvdXQKPj4+PiAgICAgICAgIHRoZSBpbnRlbnRpb24gb2YgdGhlIGRv Y3VtZW50LiBKb2huIGFsc28gcHJvdmlkZXMgYWRkaXRpb25hbAo+Pj4+ICAgICAgICAgY29tbWVu dHMgaW4gdGhpcyBwb3N0IHRvIHRoZQo+Pj4+ICAgICAgICAgPj4gbGlzdDoKPj4+PiAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1 NDQxLmh0bWwKPj4+PiAgICAgICAgID4+IE1vc3Qgb2YgdGhlbSByZXF1aXJlIG1vcmUgdGhhbiBq dXN0IGVkaXRpbmcgd29yay4gRm9yCj4+Pj4gICAgICAgICBleGFtcGxlLCBtZXRob2RzIGxpc3Rl ZCBhcmUgcmVhbGx5IG5vdCB1c2VmdWwsCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgPj4g UGhpbCBhZ3JlZXMgd2l0aCB0aGUgZG9jdW1lbnQgYWRvcHRpb24gYnV0IGhhcyBzb21lCj4+Pj4g ICAgICAgICByZW1hcmtzIGFib3V0IHRoZSByZWdpc3RyeSBhbHRob3VnaCBoZSBkb2VzIG5vdCBw cm9wb3NlCj4+Pj4gICAgICAgICBzcGVjaWZpYyB0ZXh0LiBIaXMgcmV2aWV3IGlzIGhlcmU6Cj4+ Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0NjIuaHRtbAo+Pj4+ICAgICAgICAgPj4KPj4+PiAg ICAgICAgID4+IFdpdGggbXkgY28tY2hhaXIgaGF0IG9uOiBJIGp1c3Qgd2FudGVkIHRvIGNsYXJp ZnkgdGhhdAo+Pj4+ICAgICAgICAgcmVnaXN0ZXJpbmcgY2xhaW1zIChhbmQgdmFsdWVzIHdpdGhp biB0aG9zZSBjbGFpbXMpIGlzCj4+Pj4gICAgICAgICB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBP QXV0aCB3b3JraW5nIGdyb3VwLiBXZSBzdGFuZGFyZGl6ZWQKPj4+PiAgICAgICAgIHRoZSBKV1Qg aW4gdGhpcyBncm91cCBhbmQgd2UgYXJlIGFsc28gY2hhcnRlcmVkIHRvCj4+Pj4gICAgICAgICBz dGFuZGFyZGl6ZSBjbGFpbXMsIGFzIHdlIGFyZSBjdXJyZW50bHkgZG9pbmcgd2l0aCB2YXJpb3Vz Cj4+Pj4gICAgICAgICBkcmFmdHMuIE5vdCBzdGFuZGFyZGl6aW5nIEpXVCBpbiB0aGUgSUVURiB3 b3VsZCBoYXZlIGxlYWQgdG8KPj4+PiAgICAgICAgIHJlZHVjZWQgaW50ZXJvcGVyYWJpbGl0eSBh bmQgbGVzcyBzZWN1cml0eS4gSSBoYXZlIG5vIGRvdWJ0cwo+Pj4+ICAgICAgICAgdGhhdCB3YXMg YSB3cm9uZyBkZWNpc2lvbi4KPj4+PiAgICAgICAgID4+Cj4+Pj4gICAgICAgICA+PiBJbiBpdHMg Y3VycmVudCBmb3JtLCB0aGVyZSBpcyBub3QgZW5vdWdoIHN1cHBvcnQgdG8gaGF2ZQo+Pj4+ICAg ICAgICAgdGhpcyBkb2N1bWVudCBhcyBhIFdHIGl0ZW0uCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAg ICAgICAgPj4gV2UgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBhdXRob3JzIHNob3VsZCBhZGRy ZXNzIHNvbWUKPj4+PiAgICAgICAgIG9mIHRoZSBlYXNpZXIgY29tbWVudHMgYW5kIHN1Ym1pdCBh IG5ldyB2ZXJzaW9uLiBUaGlzIHdvdWxkCj4+Pj4gICAgICAgICBhbGxvdyB1cyB0byByZWFjaCBv dXQgdG8gdGhvc2Ugd2hvIGhhZCBleHByZXNzZWQgY29uY2VybnMKPj4+PiAgICAgICAgIGFib3V0 IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgdG8gcmUtZXZhbHVhdGUgdGhlaXIKPj4+PiAgICAg ICAgIGRlY2lzaW9uLiBBIG5ldyBkcmFmdCB2ZXJzaW9uIHNob3VsZCBhdCBsZWFzdCBhZGRyZXNz IHRoZQo+Pj4+ICAgICAgICAgZm9sbG93aW5nIGlzc3VlczoKPj4+PiAgICAgICAgID4+Cj4+Pj4g ICAgICAgICA+PiAqIENsYXJpZnkgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhbiBlbmNvdXJh Z2VtZW50IGZvcgo+Pj4+ICAgICAgICAgdXNpbmcgT0F1dGggYXMgYW4gYXV0aGVudGljYXRpb24g cHJvdG9jb2wuIEkgYmVsaWV2ZSB0aGF0Cj4+Pj4gICAgICAgICB0aGlzIHdvdWxkIGFkZHJlc3Mg c29tZSBvZiB0aGUgY29uY2VybnMgcmFpc2VkIGJ5IEp1c3RpbiBhbmQKPj4+PiAgICAgICAgIEpv aG4uCj4+Pj4gICAgICAgICA+Pgo+Pj4+ICAgICAgICAgPj4gKiBDaGFuZ2UgdGhlIHJlZ2lzdHJ5 IHBvbGljeSwgd2hpY2ggd291bGQgYWRkcmVzcyBvbmUgb2YKPj4+PiAgICAgICAgIHRoZSBjb21t ZW50cyBmcm9tIEphbWVzLCBXaWxsaWFtLCBhbmQgUGhpbC4KPj4+PiAgICAgICAgID4+Cj4+Pj4g ICAgICAgICA+PiBWYXJpb3VzIG90aGVyIGl0ZW1zIHJlcXVpcmUgZGlzY3Vzc2lvbiBzaW5jZSB0 aGV5IGFyZQo+Pj4+ICAgICAgICAgbW9yZSBkaWZmaWN1bHQgdG8gYWRkcmVzcy4gRm9yIGV4YW1w bGUsIEpvaG4gbm90ZWQgdGhhdCBoZQo+Pj4+ICAgICAgICAgZG9lcyBub3QgbGlrZSB0aGUgdXNl IG9mIHJlcXVlc3QgcGFyYW1ldGVycy4gVW5mb3J0dW5hdGVseSwKPj4+PiAgICAgICAgIG5vIGFs dGVybmF0aXZlIGlzIG9mZmVyZWQuIEkgdXJnZSBKb2huIHRvIHByb3ZpZGUgYW4KPj4+PiAgICAg ICAgIGFsdGVybmF0aXZlIHByb3Bvc2FsLCBpZiB0aGVyZSBpcyBvbmUuIEFsc28sIHRoZSByZW1h cmsgdGhhdAo+Pj4+ICAgICAgICAgdGhlIHZhbHVlcyBhcmUgbWVhbmluZ2xlc3MgY291bGQgYmUg Y291bnRlcmVkIHdpdGggYW4KPj4+PiAgICAgICAgIGFsdGVybmF0aXZlIHByb3Bvc2FsLiBKYW1l cyB3YW50ZWQgdG8gcmVtb3ZlIHRoZQo+Pj4+ICAgICAgICAgImFtcl92YWx1ZXMiIHBhcmFtZXRl ci4KPj4+PiAgICAgICAgID4+IElzIHRoaXMgd2hhdCBvdGhlcnMgd2FudCBhcyB3ZWxsPwo+Pj4+ ICAgICAgICAgPj4KPj4+PiAgICAgICAgID4+IEFmdGVyIHRoZXNlIGl0ZW1zIGhhdmUgYmVlbiBh ZGRyZXNzZWQgd2UgYmVsaWV2ZSB0aGF0Cj4+Pj4gICAgICAgICBtb3JlIGZvbGtzIGluIHRoZSBn cm91cCB3aWxsIHN1cHBvcnQgdGhlIGRvY3VtZW50Lgo+Pj4+ICAgICAgICAgPj4KPj4+PiAgICAg ICAgID4+IENpYW8KPj4+PiAgICAgICAgID4+IEhhbm5lcyAmIERlcmVrCj4+Pj4gICAgICAgICA+ Pgo+Pj4+ICAgICAgICAgPj4KPj4+PiAgICAgICAgID4+Cj4+Pj4gICAgICAgICA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+ICAgICAgICAgPj4g T0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4gICAgICAgICA+PiBPQXV0aEBpZXRmLm9yZyA8bWFpbHRv Ok9BdXRoQGlldGYub3JnPgo+Pj4+ICAgICAgICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+ICAgICAgICAgPgo+Pj4+ICAgICAgICAgPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+ICAgICAgICAgPiBP QXV0aCBtYWlsaW5nIGxpc3QKPj4+PiAgICAgICAgID4gT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4KPj4+PiAgICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aAo+Pj4+Cj4+Pj4gICAgICAgICDigJQgUm9sYW5kCj4+Pj4KPj4+PiAg ICAgICAgIOKAnUV2ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBzdHJlYW0g YW5kIGxpc3Rlbi4iCj4+Pj4gICAgICAgICA+RnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJm bGllc+KAmSBieSBSdXRoIEtyYXVzcwo+Pj4+Cj4+Pj4KPj4+PiAgICAgICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4gICAgICAgICBPQXV0aCBt YWlsaW5nIGxpc3QKPj4+PiAgICAgICAgIE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+Cj4+Pj4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoCj4+Pj4KPj4+PiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCj4+Pj4gICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+PiAgICAg ICAgIE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+Pj4gICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4KPj4+PiAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+PiAgICAg T0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4gICAgIE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+Cj4+Pj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgKPj4+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+Pj4gICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4gICAgIE9BdXRoQGlldGYub3JnIDxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aAo+Pgo+Pgo+PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPj4gICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+PiAgICAgT0F1 dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPj4gICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4KPj4KPj4KPj4KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gT0F1dGggbWFpbGluZyBsaXN0 Cj4+IE9BdXRoQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgKPgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+T0F1dGggbWFpbGluZyBsaXN0Cj5PQXV0aEBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo= ----_com.syntomo.email_1610206958705281 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkkgbWVhbnQgV2lsbGlhbSAtIHNvcnJ5ITwvcD4KPGJyPjxicj4tLS0tLS0t LSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLTxicj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBB dXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3IgQWRvcHRpb24g RmluYWxpemVkPGJyPlZvbjogVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQmZ3Q7PGJyPkFuOiBXaWxsaWFtIERlbm5pc3MgJmx0O3dkZW5uaXNzQGdvb2dsZS5j b20mZ3Q7LE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+ Q2M6ICZxdW90OyZsdDtvYXV0aEBpZXRmLm9yZyZndDsmcXVvdDsgJmx0O29hdXRoQGlldGYub3Jn Jmd0Ozxicj48YnI+DQogICAgSGkgRGVubmlzcyw8YnI+DQogICAgPGJyPg0KICAgIG91dCBvZiBj dXJpb3NpdHk6IERvZXMgR29vZ2xlIHVzZSBhbXIgdmFsdWVzPyA8YnI+DQogICAgPGJyPg0KICAg IGJlc3QgcmVnYXJkcyw8YnI+DQogICAgVG9yc3Rlbi48YnI+DQogICAgPGJyPg0KICAgIDxkaXYg Y2xhc3M9Im1vei1jaXRlLXByZWZpeCI+QW0gMTQuMDIuMjAxNiB1bSAwMjo0MCBzY2hyaWViIFdp bGxpYW0NCiAgICAgIERlbm5pc3M6PGJyPg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlDQpj aXRlPSJtaWQ6Q0FBUDQyaEE9SmE1ZWFpV0tRUHp4djJZMzhiaFZ5SnQ2K0tQUlNmRmtOPVZDc0N4 VF9BQG1haWwuZ21haWwuY29tIg0KICAgICAgdHlwZT0iY2l0ZSI+DQogICAgICA8ZGl2IGRpcj0i bHRyIj48YnI+DQogICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAg ICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFNhdCwgRmViIDEzLCAyMDE2IGF0IDEyOjE5 IFBNLA0KICAgICAgICAgICAgTWlrZSBKb25lcyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIg0KICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgIHdyb3Rl Ojxicj4NCiAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgICAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQogICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAg IDxkaXYNCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjtmb250LXNpemU6MTFwdCI+SXQncw0KICAgICAgICAgICAgICAgICAgICBhbiBhY2Nl cHRhYmxlIGZhbGxiYWNrIG9wdGlvbiBpZiB0aGUgd29ya2luZyBncm91cA0KICAgICAgICAgICAg ICAgICAgICBkZWNpZGVzIGl0IGRvZXNuJ3Qgd2FudCB0byByZWdpc3RlciB0aGUgdmFsdWVzIHRo YXQNCiAgICAgICAgICAgICAgICAgICAgYXJlIGFscmVhZHkgaW4gcHJvZHVjdGlvbiB1c2UgYXQg dGhlIHRpbWUgd2UNCiAgICAgICAgICAgICAgICAgICAgZXN0YWJsaXNoIHRoZSByZWdpc3RyeS4g QnV0IGFkZCBXaWxsaWFtIHBvaW50cyBvdXQsDQogICAgICAgICAgICAgICAgICAgIEdvb2dsZSBp cyBhbHJlYWR5IHVzaW5nIHNvbWUgb2YgdGhlc2UgdmFsdWVzLg0KICAgICAgICAgICAgICAgICAg ICBNaWNyb3NvZnQgaXMgdXNpbmcgc29tZSBvZiB0aGVtLiBUaGUgT3BlbklEIE1PRFJOQQ0KICAg ICAgICAgICAgICAgICAgICBzcGVjcyBhcmUgdXNpbmcgc29tZSBvZiB0aGVtLiBTbyBpdCBzZWVt cyBtb3JlDQogICAgICAgICAgICAgICAgICAgIGVmZmljaWVudCB0byByZWdpc3RlciB0aGVtIGF0 IHRoZSBzYW1lIHRpbWUuPGJyPg0KICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg ICAgICAgICAgIFRoYXQgd291bGQgYmUgbXkgcHJlZmVyZW5jZS48YnI+DQogICAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPGRpdj4rMSwgaXQgaXMgYWxzbyBteSBwcmVmZXJl bmNlIHRvIHJlZ2lzdGVyIHRoZSBjdXJyZW50DQogICAgICAgICAgICAgIHZhbHVlcy48L2Rpdj4N CiAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8 ZGl2PkkgZG9uJ3Qgc2VlIGFueSBoYXJtIGluIHRoZSBzcGVjIHRoYXQgZXN0YWJsaXNoZXMgdGhl DQogICAgICAgICAgICAgIHJlZ2lzdHJ5IGFsc28gc2VlZGluZyBpdCB3aXRoIGFsbCBrbm93biB2 YWx1ZXMgaW4gdXNlIGF0DQogICAgICAgICAgICAgIHRoZSB0aW1lIG9mIGRyYWZ0aW5nLCByZWdh cmRsZXNzIG9mIHRoZSBncm91cCB0aGF0DQogICAgICAgICAgICAgIG9yaWdpbmFsbHkgc3BlY2lm aWVkIHRoZW0uIE1ha2VzIHRoZSBvcmlnaW5hbCBzcGVjIG1vcmUNCiAgICAgICAgICAgICAgdXNl ZnVsLCBhbmQgYXZvaWRzIHRoZSBuZWVkIHRvIHN1Ym1pdCBlYWNoIHZhbHVlIGZvcg0KICAgICAg ICAgICAgICBjb25zaWRlcmF0aW9uIHNlcGFyYXRlbHkg4oCTIHRoZXkgY2FuIGJlIGFsbCBiZSBy ZXZpZXdlZCBhdA0KICAgICAgICAgICAgICB0aGUgc2FtZSB0aW1lLsKgPC9kaXY+DQogICAgICAg ICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgICAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICA8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQogICAgICAgICAgICAgICAgPGRpdiBkaXI9 Imx0ciI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdDtmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KICAg ICAgICAgICAgICAgICAgPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQiPjxhDQogICAgICAg ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAg ICAgIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5KdXN0aW4N CiAgICAgICAgICAgICAgICAgICAgICBSaWNoZXI8L2E+PC9zcGFuPjxicj4NCiAgICAgICAgICAg ICAgICAgIDxzcGFuDQogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQ7Zm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCiAg ICAgICAgICAgICAgICAgIDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0Ij7igI4yL+KAjjEz L+KAjjIwMTYNCiAgICAgICAgICAgICAgICAgICAgMTE6MTEgQU08L3NwYW4+PGJyPg0KICAgICAg ICAgICAgICAgICAgPHNwYW4NCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdDtmb250LXdlaWdodDpib2xkIj5UbzoN CiAgICAgICAgICAgICAgICAgIDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0Ij48YQ0KICAg ICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAg ICAgICAgICBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5QaGlsDQogICAgICAgICAgICAgICAgICAgICAgSHVudDwvYT48L3NwYW4+DQogICAgICAgICAg ICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJoNSI+PGJyPg0K ICAgICAgICAgICAgICAgICAgICAgIDxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0O2ZvbnQtd2Vp Z2h0OmJvbGQiPkNjOg0KICAgICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48c3Bhbg0KICAgICAg ICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtm b250LXNpemU6MTFwdCI+PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZF IiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+ PC9hPjwvc3Bhbj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPHNwYW4NCiAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1z aXplOjExcHQ7Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoNCiAgICAgICAgICAgICAgICAgICAg ICA8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQiPlJlOg0KICAgICAgICAgICAgICAg ICAgICAgICAgW09BVVRILVdHXSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlDQogICAg ICAgICAgICAgICAgICAgICAgICBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0aW9uIEZpbmFsaXplZDwv c3Bhbj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJo NSI+DQogICAgICAgICAgICAgICAgICAgIDxkaXY+Q2FuIHdlIGp1c3QgZG8gdGhhdCwgdGhlbj8g U2VlbXMgdG8gYmUgdGhlDQogICAgICAgICAgICAgICAgICAgICAgZWFzaWVzdCB3YXkgdG8gYWRk cmVzcyB2YXJpb3VzIG5lZWRzIGFuZA0KICAgICAgICAgICAgICAgICAgICAgIGNvbmNlcm5zLsKg DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoOKAlCBKdXN0aW48L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+T24gRmViIDEzLCAyMDE2LCBhdCAxMTow OCBBTSwgUGhpbCBIdW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoSURNKSAmbHQ7 PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8L2Rpdj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJhdXRvIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5ZZXM8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBo aWw8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gRmViIDEzLCAyMDE2LCBhdCAwNzo1OSwg IjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9 InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIg aHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldDwvYT48L2E+Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDs8YSBt b3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ8L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgZGlyPSJsdHIi PlNvIGJhc2ljYWxseSwgdGhlIFJGQw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb3VsZCBhbHNvIGp1c3QgZXN0YWJsaXNoIHRoZSBuZXcNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcmVnaXN0cnkgYW5kIG9pZGYgY291bGQgZmVlbCBpbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdmFsdWVzPzwvcD4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGRpcj0ibHRyIj4oanVzdCB0cnlpbmcg dG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5kZXJzdGFuZCk8L3A+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLTxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJldHJlZmY6IFJFOiBbT0FVVEgtV0ddDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVm ZXJlbmNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZXM6IENhbGwg Zm9yIEFkb3B0aW9uIEZpbmFsaXplZDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFZvbjogTWlrZSBKb25lcyAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+ PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPjwvYT4m Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW46IDxhIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ig0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ8L2E+LEpvaG4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJyYWRsZXkg Jmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRl ZCIgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT48 L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENjOiA8YSBt b3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2 MCI+VGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb250ZXh0 IHRoYXQgbW9zdCBwZW9wbGUgb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoaXMgdGhyZWFkIHByb2JhYmx5IGRvbuKAmXQNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGhhdmUgaXMgdGhhdCBhbiBJQU5BIHJlZ2lzdHJ5DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYW4gb25seSBiZSBlc3RhYmxp c2hlZCBieSBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUkZD LsKgIE5vbi1SRkMgc3BlY2lmaWNhdGlvbnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdWNoIGFzIE9wZW5JRCBzcGVjaWZpY2F0aW9ucywNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhbiAqPGI+cmVnaXN0ZXI8L2I+KiB2YWx1 ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIGEgcmVnaXN0 cnksIGJ1dCB0aGV5IGNhbm5vdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKjxiPmVzdGFibGlzaDwvYj4qIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHJlZ2lzdHJ5LsKgIFRoZSBPcGVuSUQNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZvdW5kYXRpb24gaW5xdWlyZWQgYWJvdXQgdGhpcw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCB0aGUgSUVURiBiZWZv cmUgT3BlbklEDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb25u ZWN0IHdhcyBmaW5hbGl6ZWQgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBsZWFybmVkIHRoYXQgaXRzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzcGVjaWZpY2F0aW9ucyBjb3VsZCBub3QNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGVzdGFibGlzaCBJQU5BIHJlZ2lzdHJpZXMuwqANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE90aGVyd2lzZSwgdGhleSB3b3Vs ZCBoYXZlLjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+wqA8 L3NwYW4+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkluc3RlYWQsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSRkNzIG5lZWQgdG8gYmUg Y3JlYXRlZCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXN0 YWJsaXNoIHJlZ2lzdHJpZXMg4oCTIGV2ZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGZvciB2YWx1ZXMgZmlyc3QgZGVmaW5lZCBpbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9uLVJGQyBzcGVjaWZpY2F0aW9ucy7CoCBUaGlz DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpY2F0aW9u IGlzIG9uZSBleGFtcGxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBvZiBkb2luZyB0aGlzLjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+wqA8L3NwYW4+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZTwvc3Bhbj48 L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3ot ZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBuYW1lPSIxOTUzMDI3NjA4X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4NCnN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj7CoDwvc3Bhbj48L2E+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8c3Bhbj48L3NwYW4+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuDQpzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgT0F1dGggWzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj48YSBj bGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9hPl0NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxiPk9uIEJlaGFsZiBPZiA8L2I+PGEN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo cmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj48YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQi PnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPjwvYT48YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gU2F0dXJkYXksDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAxMywgMjAxNiA2OjM3IEFN PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGI+VG86PC9i PiBKb2huIEJyYWRsZXkgJmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+ PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT48L2E+Jmd0Ozxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxiPkNjOjwvYj4gPGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHRhcmdldD0iX2JsYW5rIj48YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEF1dGhlbnRpY2F0aW9uIE1ldGhvZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmVmZXJlbmNlIFZhbHVlczogQ2FsbCBmb3INCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFkb3B0aW9uIEZpbmFsaXplZDwvc3Bhbj48L3A+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPsKg PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD5XZSBjbGVhcmx5 IGhhdmUgdGhpcyBwcm9ibGVtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYmV0d2VlbiBvYXV0aCBhbmQgb2lkYy4gSnVzdA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRha2UgYSBsb29rIGF0IHRoZSBkaXNjb3ZlcnkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aHJlYWQuPC9wPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8cD5BY2NvcmRpbmcgdG8geW91IGFyZ3VtZW50IEkgc2Vl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHdvIG9wdGlvbnM6PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgxKSBhbXIgc3RheXMg YW4gb2lkYyBjbGFpbSwgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB1c2VkIGluIG9pZGMgb25seSBhbmQgdGhlIG9hdXRoDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgd2cganVzdCBwdWJsaXNoZXMgdGhlIHJlZ2lzdHJ5DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW50cmllcy4gSW4gdGhpcyBjYXNlLCB0 aGUgc3BlYw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBj bGVhcmx5IGV4cGxhaW4gdGhpcy48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKDIpIGFtciBpcyBvZiBhbnkgdXNlIGluIG9hdXRoDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKGFsdGhvdWdoIGl0IGhhcyBiZWVuIGludmVudGVkDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gb2lkYykgLSB0aGFuIGRl ZmluZSBpdCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3Rp dmF0ZSBpdCdzIHVzZSBpbiBvYXV0aCBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRoaXMgc3BlYy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD5SaWdodCBu b3csIEkgdGhpbmsgaXQgY3JlYXRlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBpbXByZXNzaW9uIG9hdXRoIGlzIGZvcg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0tLS0tLS0gT3JpZ2luYWxuYWNocmljaHQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLS0tLTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBCZXRyZWZmOiBSZTogW09BVVRILVdHXQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZXM6IENhbGwgZm9yIEFkb3B0 aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmluYWxpemVkPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZvbjogSm9obiBCcmFk bGV5ICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiPjxhIGNsYXNzPSJtb3otdHh0 LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRi QHZlN2p0Yi5jb208L2E+PC9hPiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQW46IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdl dD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2M6IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpy b2xhbmQuaGVkYmVyZ0B1bXUuc2Usb2F1dGhAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+cm9sYW5kLmhlZGJlcmdAdW11 LnNlLG9hdXRoQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhpcyBpcyBub3QgYSBpc3N1ZSBiZXR3ZWVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgb2F1dGggYW5kIE9JREMuPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPsKgPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIGhhcyB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZG8gd2l0aCB0aGUgcmVnaXN0cnkgZm9yIEpXVA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgYmVpbmcgaW4gT0F1dGguIMKgIE1hbnkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29scyB0aGF0IHVzZSBK V1QgYXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnb2luZyB0 byB3YW50IHRvIHJlZ2lzdGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjbGFpbXMuIMKgPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSBjYW7igJl0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh c2sgdGhlbSB0byBhbGwgbW92ZSB0aGUgcGFydHMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG9mIHRoZXJlIHNwZWNzIHRoYXQgdXNlIEpXVCB0bw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGguPC9wPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj7CoDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBKV1QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNob3VsZCBoYXZlIGJlZW4gcGFydCBvZiBKT1NFLA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnV0IHRoYXQgaXMgd2F0ZXIgdW5kZXIgdGhl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBicmlkZ2UuIMKgPC9w Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj7CoDwvcD4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9BdXRoDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBXRyBpcyByZXNwb25zaWJsZSBmb3IgSldUIGFuZA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXTigJlzIHJlZ2lzdHJ5 LCBhbmQgd2Ugd2lsbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bmVlZCB0byBkZWFsIHdpdGggcmVnaXN0ZXJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNsYWltcy4gwqA8L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPsKgPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGd1ZXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0 IHdlIGNhbiB0ZWxsIHBlb3BsZSB0aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB0aGV5IG5lZWQgdG8gcHVibGlzaCB0aGUgc3BlY3MNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmluaW5nIHRoZSBjbGFpbXMgc29tZXBsYWNl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbHNlLCBhbmQganVz dCBkbyB0aGUgcmVnaXN0cnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBhcnQuPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dl dmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2luZyB0aGF0 IHdpbGwgcHJvYmFibHkgbm90DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBpbXByb3ZlIGludGVyb3BlcmFiaWxpdHkgYW5kDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB1bmRlcnN0YW5kaW5nLjwvcD4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGRvY3VtZW50IGRlZmluZXMgdGhlIGNsYWltIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSldUIGluIGdlbmVyYWwuwqAgV2Ugc3RpbGwgaGF2ZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxtb3N0IG5vIGRvY3VtZW50YXRp b24gaW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXRyBh Ym91dCB3aGF0IGEgSldUIGFjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdG9rZW4gd291bGQgY29udGFpbiBvdGhlciB0aGFuDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgUE9QIHdvcmsuPC9wPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj7CoDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+Sm9obiBCLjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGJsb2NrcXVvdGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYiAxMywg MjAxNiwgYXQgOToxOA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQU0sIDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldDwvYT48L2E+IHdyb3RlOjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPsKgPC9wPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJhc2ljYWxseSBzdXBw b3J0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZG9w dGlvbiBvZiB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkb2N1bWVudC4gQXNzZXJ0aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBtZXRob2RzDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbiBhY2Nlc3MgdG9rZW5zIChpbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBjYXNlIGlu IEpXVFMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv cm1hdCkgaXMgcmVhc29uYWJsZS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFdlIHVzZSBpdCB0byBwYXNzDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHBlcmZv cm1lZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJp b3IgaXNzdWluZyBhbiBhY2Nlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRva2VuIHRvIHRoZSBfcmVzb3VyY2VfDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXJ2ZXIuIDwvcD4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3JyaWVz IG1lIGlzIHRoZSBiYWNrDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhbmQgZm9ydGggYmV0d2VlbiBvYXV0aA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYW5kIG9pZGMuIFRoZSBhbXIgY2xhaW0NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGRlZmluZWQgaW4gb2lk Yw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHdoaWNo IHNpdHMgb24gdG9wIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBvYXV0aCkgYnV0IHRoZSBvYXV0aCB3Zw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWVzIHRoZSByZWdpc3RyeT8NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vcmVvdmVyLCB0aGUgY3Vy cmVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4 dCBkb2VzIG5vdCBnaXZlIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJhdGlvbmFsZSBmb3IgdXNpbmcgYW1yDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBpbiBjb250ZXh0IG9mIG9hdXRoLjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj5BcyBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBXRyB3ZSBuZWVkIHRvIGZpbmQgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY2xlYXIgZGVsaW5lYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGJldHdlZW4gYm90aCBwcm90b2NvbHMsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdGhlcndpc2Ugbm9vbmUg d2lsbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVh bGx5IHVuZGVyc3RhbmQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkaWZmZXJlbmNlIGFuZCB3aGVuIHRvDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB1c2Ugd2hhdC4gV2UgY3JlYXRlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25mdXNpb24hDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9wPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkZv cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBw YXJ0aWN1bGFyIGRyYWZ0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0aGlzIG1lYW5zIHRvIGVpdGhlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgbW92ZSBhbXIgdG8gb2F1dGggb3IgdGhlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWdpc3RyeSB0byBvaWRjLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj5iZXN0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICByZWdhcmRzLCA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBUb3JzdGVuLjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLSBV cnNwcsO8bmdsaWNoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTmFjaHJpY2h0IC0tLS0tLS0tPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVm9uOiBSb2xhbmQgSGVkYmVyZyAmbHQ7PGENCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIg0KaHJlZj0ibWFpbHRvOnJvbGFuZC5oZWRiZXJnQHVtdS5zZSIgdGFyZ2V0PSJfYmxh bmsiPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpyb2xh bmQuaGVkYmVyZ0B1bXUuc2UiPnJvbGFuZC5oZWRiZXJnQHVtdS5zZTwvYT48L2E+Jmd0Ozxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdlc2VuZGV0 OiBGcmlkYXksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGZWJydWFyeSAxMiwgMjAxNiAwNTo0NQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUE08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBbjogPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48 L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QmV0cmVmZjogUmU6IFtPQVVUSC1XR10NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIE1ldGhvZA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlIFZhbHVlczogQ2FsbA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9yIEFkb3B0aW9u IEZpbmFsaXplZDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4rMTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsgMTIgZmViIDIwMTYga2wuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNjo1OCBza3JldiBKb2huIEJyYWRs ZXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDs8 YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3ot ZG8tbm90LXNlbmQ9InRydWUiDQpocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdl dD0iX2JsYW5rIj48YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls dG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPjwvYT4mZ3Q7Ojxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAr MSB0byBhZG9wdCB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBkcmFmdC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZndDsmZ3Q7IE9uIEZlYiAxMiwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTYsIGF0IDM6MDcgQU0sIE1pa2UNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvbmVzICZsdDs8YQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90 LXNlbmQ9InRydWUiDQpocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0i bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPC9hPjwvYT4mZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyBEcmFmdCAtMDUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluY29ycG9yYXRlcyB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZlZWRiYWNrIGRlc2NyaWJl ZCBiZWxvdw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LSBkZWxldGluZyB0aGUgcmVxdWVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGFyYW1ldGVyLCBub3RpbmcgdGhhdA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBzcGVjIGlzbid0IGFuDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbmNvdXJhZ2VtZW50IHRv IHVzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYXV0aGVudGljYXRpb24gd2l0aG91dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZW1wbG95aW5nIGFwcHJvcHJpYXRlDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHRlbnNpb25zLCBhbmQgbm8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxvbmdlciByZXF1aXJp bmcgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Bl Y2lmaWNhdGlvbiBmb3IgSUFOQQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcmVnaXN0cmF0aW9uLsKgIEkgYmVsaWV2ZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBpdOKAmXMgbm93IHJlYWR5IGZvcg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd29ya2luZyBn cm91cCBhZG9wdGlvbi48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgLS0tLS1PcmlnaW5hbA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZS0tLS0t PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0 OyZndDsgRnJvbTogT0F1dGggWzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Im1haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPjwvYT5dDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBPbiBCZWhhbGYgT2YgSGFubmVzDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUc2Nob2ZlbmlnPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgU2VudDog VGh1cnNkYXksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGZWJydWFyeSA0LCAyMDE2IDExOjIzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBTTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7IFRvOiA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48YSBjbGFzcz0ibW96LXR4dC1s aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu b3JnPC9hPjwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7Jmd0OyBTdWJqZWN0Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW09BVVRILVdHXQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gTWV0aG9kDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UgVmFsdWVzOiBDYWxs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgQWRv cHRpb24gRmluYWxpemVkPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmd0OyZndDsgSGkgYWxsLDxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IE9uIEphbnVhcnkg MTl0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSBw b3N0ZWQgYSBjYWxsIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYWRvcHRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBNZXRob2QNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZSBWYWx1ZXMNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljYXRpb24sIHNl ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGENCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMTU0MDIuaHRtbCINCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiPg0KPGEgY2xhc3M9Im1vei10 eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MDIuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0MDIuaHRtbDwvYT48L2E+PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn dDsgV2hhdCBzdXJwcmlzZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVzIGlzIHRoYXQgdGhpcyB3b3JrIGlzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25jZXB0dWFsbHkgdmVyeQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2ltcGxlOiB3ZSBkZWZpbmUgbmV3 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGFpbXMg YW5kIGNyZWF0ZSBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZWdpc3RyeSB3aXRoIG5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdmFsdWVzLiBOb3QgYSBiaWcgZGVhbA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnV0IHRoYXQncyBub3Qgd2hhdCB0aGUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZlZWRiYWNrIGZy b20gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZ b2tvaGFtYSBJRVRGIG1lZXRpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFuZCB0aGUgc3Vic2VxdWVudCBjYWxsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgYWRvcHRpb24gb24gdGhlIGxpc3QNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNob3dzLiBUaGUg ZmVlZGJhY2sgbGVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdG8gbWl4ZWQgZmVlbGluZ3MgYW5kIGl0DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpcyBhIGJpdCBkaWZmaWN1bHQgZm9yDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZXJlayBhbmQgbXlzZWxmIHRv DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBqdWRnZSBj b25zZW5zdXMuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsgTGV0IG1lIHRlbGwgeW91DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGF0IHdlIHNlZSBmcm9tIHRoZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tbWVudHMgb24gdGhl IGxpc3QuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsgSW4gaGlzIHJldmlldw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYXQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cx NTQyMy5odG1sIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0YXJnZXQ9Il9ibGFuayI+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9t c2cxNTQyMy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTQyMy5odG1sPC9hPjwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEphbWVzIE1hbmdlciBhc2tzIGZvcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2lnbmlmaWNhbnQgY2hhbmdlcy4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFtb25nIG90 aGVyIHRoaW5ncywgaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHdhbnRzIHRvIHJlbW92ZSBvbmUgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHRoZSBjbGFpbXMuIEhlIHByb3ZpZGVzDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIGRldGFpbGVkIHJldmlldyBh bmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlv bmFibGUgaXRlbXMuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsgV2lsbGlhbSBEZW5uaXNzDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWxpZXZlcyB0aGUgZG9jdW1lbnQgaXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYWR5IGZv ciBhZG9wdGlvbiBidXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFncmVlcyB3aXRoIHNvbWUgb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb21tZW50cyBmcm9tIEphbWVzLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGVyZSBpcyBoaXMgcmV2aWV3Ojxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm Z3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDI2Lmh0bWwiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj4NCjxhIGNs YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDI2Lmh0bWwiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDI2Lmh0bWw8L2E+PC9h Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsmZ3Q7IEp1c3RpbiBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY2VydGFpbmx5IHRoZSByZXZpZXdlcg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCB0aGUgc3Ryb25nZXN0DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGluaW9uLiBIZXJlIGlz IG9uZSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aGlzIHBvc3RzOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDU3Lmh0bWwiDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2Js YW5rIj4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDU3Lmh0bWwiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDU3 Lmh0bWw8L2E+PC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7IEFtb25nIGFsbA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uY2VybnMgSnVzdGluDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHByZXNzZWQgdGhlIGZvbGxvd2lu Zw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb25lIGlz IGFjdHVhbGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBhY3Rpb25hYmxlIElNSE86IEp1c3Rpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaXMgd29ycmllZCB0aGF0DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICByZXBvcnRpbmcgaG93IGEgcGVyc29uDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGVkIHRv IGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRo b3JpemF0aW9uIGVuZHBvaW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhbmQgZW5jb3VyYWdpbmcgcGVvcGxlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0byB1c2UgT0F1dGggZm9yDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBpcyBhIGZp bmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpbmUu IEhlIGJlbGlldmVzIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRoaXMgZG9jdW1lbnQgbGVhZHMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlYWRlcnMgdG8gYmVsaWV2ZSB0aGUNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxhdHRlci48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyA8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyBK b2huIGFncmVlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgd2l0aCBKdXN0aW4gaW48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmZ3Q7Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5odG1s Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJn ZXQ9Il9ibGFuayI+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ0OC5o dG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9t c2cxNTQ0OC5odG1sPC9hPjwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoYXQgd2UgbmVlZCB0byBtYWtlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzdXJlIHRoYXQgcGVvcGxlIGFyZSBub3QNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pc2xlYWQgYWJvdXQg dGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRl bnRpb24gb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkb2N1bWVudC4gSm9obiBhbHNvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwcm92aWRlcyBhZGRpdGlvbmFsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21tZW50cyBpbiB0aGlzIHBvc3QgdG8NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZTxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IGxp c3Q6IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWwiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj4NCjxhIGNs YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWwiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDQxLmh0bWw8L2E+PC9h Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsmZ3Q7IE1vc3Qgb2YgdGhlbQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcmVxdWlyZSBtb3JlIHRoYW4ganVzdA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZWRpdGluZyB3b3JrLiBGb3INCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1wbGUsIG1ldGhvZHMgbGlz dGVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcmUg cmVhbGx5IG5vdCB1c2VmdWwsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgUGhpbCBhZ3JlZXMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggdGhlIGRvY3VtZW50DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZG9wdGlvbiBidXQg aGFzIHNvbWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHJlbWFya3MgYWJvdXQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICByZWdpc3RyeSBhbHRob3VnaCBoZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZG9lcyBub3QgcHJvcG9zZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWMgdGV4dC4gSGlzDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXZpZXcgaXMgaGVy ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm Z3Q7Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ2Mi5odG1sIg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+DQo8 YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ2Mi5odG1sIj5odHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTQ2Mi5odG1sPC9h PjwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7Jmd0OyBXaXRoIG15DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjby1jaGFpciBoYXQgb246IEkganVzdA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2FudGVkIHRvIGNsYXJpZnkgdGhhdA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnaXN0ZXJp bmcgY2xhaW1zIChhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZhbHVlcyB3aXRoaW4gdGhvc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNsYWltcykgaXMgd2l0aGluIHRoZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2NvcGUgb2YgdGhlIE9BdXRoDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3JraW5nIGdyb3Vw LiBXZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Rh bmRhcmRpemVkIHRoZSBKV1QgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoaXMgZ3JvdXAgYW5kIHdlIGFyZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxzbyBjaGFydGVyZWQgdG8NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0YW5kYXJkaXplIGNsYWltcywg YXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdlIGFy ZSBjdXJyZW50bHkgZG9pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdpdGggdmFyaW91cyBkcmFmdHMuIE5vdA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhbmRhcmRpemluZyBKV1QgaW4gdGhlDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRVRGIHdvdWxkIGhh dmUgbGVhZCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcmVkdWNlZCBpbnRlcm9wZXJhYmlsaXR5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhbmQgbGVzcyBzZWN1cml0eS4gSQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSBubyBkb3VidHMgdGhhdCB3YXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgd3Jvbmcg ZGVjaXNpb24uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsgSW4gaXRzIGN1cnJlbnQNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvcm0sIHRoZXJlIGlzIG5vdA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5vdWdoIHN1cHBvcnQgdG8g aGF2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhp cyBkb2N1bWVudCBhcyBhIFdHDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpdGVtLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IFdlIGJlbGlldmUgdGhhdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGRvY3VtZW50IGF1dGhvcnMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBh ZGRyZXNzIHNvbWUgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBlYXNpZXIgY29tbWVudHMgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzdWJtaXQgYSBuZXcgdmVyc2lvbi4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgd291bGQgYWxsb3cgdXMg dG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYWNo IG91dCB0byB0aG9zZSB3aG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGhhZCBleHByZXNzZWQgY29uY2VybnMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFib3V0IHRoZSBzY29wZSBvZiB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvY3VtZW50IHRvIHJlLWV2 YWx1YXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGVpciBkZWNpc2lvbi4gQSBuZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGRyYWZ0IHZlcnNpb24gc2hvdWxkIGF0DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZWFzdCBhZGRyZXNzIHRoZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9sbG93aW5nIGlzc3Vlczo8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyAqIENsYXJpZnkgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudCBpcyBub3QgYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVuY291cmFnZW1lbnQgZm9yIHVzaW5n DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCBh cyBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXV0 aGVudGljYXRpb24gcHJvdG9jb2wuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJIGJlbGlldmUgdGhhdCB0aGlzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB3b3VsZCBhZGRyZXNzIHNvbWUgb2YNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBjb25jZXJucyByYWlz ZWQgYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1 c3RpbiBhbmQgSm9obi48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyAqIENoYW5nZSB0aGUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2lzdHJ5IHBvbGljeSwgd2hpY2gNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIGFkZHJl c3Mgb25lIG9mIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29tbWVudHMgZnJvbSBKYW1lcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFdpbGxpYW0sIGFuZCBQaGlsLjxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IFZhcmlvdXMg b3RoZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0 ZW1zIHJlcXVpcmUgZGlzY3Vzc2lvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc2luY2UgdGhleSBhcmUgbW9yZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZGlmZmljdWx0IHRvIGFkZHJlc3MuDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgSm9o biBub3RlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dGhhdCBoZSBkb2VzIG5vdCBsaWtlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0aGUgdXNlIG9mIHJlcXVlc3QNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlcnMuDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbmZvcnR1bmF0ZWx5LCBubw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWx0ZXJuYXRpdmUgaXMgb2Zm ZXJlZC4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEkg dXJnZSBKb2huIHRvIHByb3ZpZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWYgdGhlcmUgaXMgb25lLiBBbHNvLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHJlbWFyayB0 aGF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dmFsdWVzIGFyZSBtZWFuaW5nbGVzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY291bGQgYmUgY291bnRlcmVkIHdpdGgNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmFtZXMgd2Fu dGVkIHRvIHJlbW92ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhlICJhbXJfdmFsdWVzIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGFyYW1ldGVyLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IElzIHRoaXMgd2hhdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3RoZXJzIHdhbnQgYXMgd2VsbD88 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyBBZnRlciB0aGVzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaXRlbXMgaGF2ZSBiZWVuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhZGRyZXNzZWQgd2UgYmVsaWV2ZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBtb3JlIGZvbGtzIGluIHRo ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3JvdXAg d2lsbCBzdXBwb3J0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZG9jdW1lbnQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgQ2lhbzxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IEhhbm5lcyAmYW1wOw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVyZWs8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyA8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyBPQXV0aCBtYWlsaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBsaXN0PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48 L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjxhIGNsYXNzPSJtb3otdHh0 LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IE9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyA8YQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8t bm90LXNlbmQ9InRydWUiDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4 dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg4oCUIFJvbGFuZDxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKAnUV2ZXJ5Ym9k eSBzaG91bGQgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHF1aWV0IG5lYXIgYSBsaXR0bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN0cmVhbSBhbmQgbGlzdGVuLiI8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7RnJvbSDigJlPcGVuIEhvdXNlIGZv cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQnV0dGVy ZmxpZXPigJkgYnkgUnV0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgS3JhdXNzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlh dGVkIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvYT48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8t bm90LXNlbmQ9InRydWUiDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4 dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+PC9wPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGENCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9hPjwvcD4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4+PGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuPjxhIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4N CiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAg ICAgIE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCiAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAg ICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi DQogICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQogICAgICAgICAg ICAgIDxicj4NCiAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICA8YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9kaXY+DQogICAgICA8YnI+DQog ICAgICA8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0Pg0K ICAgICAgPGJyPg0KICAgICAgPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3ot dHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhA aWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3Rl Pg0KICAgIDxicj4NCiAg ----_com.syntomo.email_1610206958705281-- From nobody Sun Feb 14 10:29:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82CC1B2BC8 for ; Sun, 14 Feb 2016 10:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvH74u94p53d for ; Sun, 14 Feb 2016 10:29:34 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35ED1B2BCC for ; Sun, 14 Feb 2016 10:29:30 -0800 (PST) X-AuditID: 12074424-727ff70000000fca-73-56c0c789973a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 27.5A.04042.987C0C65; Sun, 14 Feb 2016 13:29:29 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1EITSYI027381 for ; Sun, 14 Feb 2016 13:29:29 -0500 Received: from [192.168.128.48] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1EITQIn010728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 14 Feb 2016 13:29:28 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5FBA28B8-77AB-4909-B915-27E0C43101CD@mit.edu> Date: Sun, 14 Feb 2016 13:29:26 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixG6nott5/ECYwbu9AhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqy29SwF66QqWlfcYGlgbBXtYuTkkBAwkbjVt4y5i5GLQ0ig jUniybyPjBDOMUaJ5j+tUM4HJol5K9axgLSwCahKzF95iwnEZhZQl/gz7xIzhK0tsWzhazBb WEBWouPNBDCbV8BK4tnpz2D1LEC9116dBpsjAtS75vxPJogaPYlXty6zQpwkK7H79yOmCYy8 s5CsmIVkxSwkLQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIEh5OLyg7G 5kNKhxgFOBiVeHh3rNwfJsSaWFZcmXuIUZKDSUmU12z7gTAhvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIrx3NgDleFMSK6tSi/JhUtIcLErivI9+7QwTEkhPLEnNTk0tSC2CycpwcChJ8MYdA2oU LEpNT61Iy8wpQUgzcXCCDOcBGt4PUsNbXJCYW5yZDpE/xagoJc5bBpIQAElklObB9YLiPeHt YdNXjOJArwjzLgSp4gGmCrjuV0CDmYAGV9zeBzK4JBEhJdXAKPr8qLsrR/sprUj3HWq3wyLX 52V8dcv8JrJ906b7retcf6ifjJma0scl0MX2bcnFZ7pfdusm+1TEG4UtF3DhuryyIrZkpZ+o seQbqb3xEQp8wRXl/fIxJY8j9lyum3xlljWXSVNv89NmhvPme1aobX+vUtwd8Szs70Mzq66j v7TiT1szvHFQYinOSDTUYi4qTgQA1k93atICAAA= Archived-At: Subject: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 18:29:35 -0000 In PoP Key Distribution, I=E2=80=99m trying to figure out the full set = of expectations that the client and AS will need to handle across = different systems. =46rom what I gather, we=E2=80=99ve got at least = these: Client provides public key: - Client stores keypair - Server stores public key - Server returns public key - Client makes sure the public key matches the request (?) Client provides shared key: - Client stores shared key - Server stores shared key - Server returns shared key - Client makes sure the shared key matches (?) Server provides public key: - Server generates keypair - Server stores public key (and promises to not store the = private key?) - Server returns the keypair - Client stores the keypair Server provides shared key: - Server generates shared key - Server stores shared key - Server returns shared key - Client stores shared key First, I think it would be helpful to have this all laid out in the = document. Second, a few of these are confusingly non-parallel. If the = client sends the key, the server returns the public key. If the client = doesn=E2=80=99t send the key, the server returns the keypair (public and = private together). It makes sense why the responses are different, but = it=E2=80=99s strange to me that we=E2=80=99re asking client developers = to expect different things in the same field.=20 And then we have error conditions. What happens if the client provides a = key but the server rejects that key and creates its own to send to the = client? Does the client need to accept this key instead of its own? What = if the client sends a shared key and the server returns a keypair? = Should the server accept the same key from the client for multiple token = requests? I think all of these conditions (and likely a lot more) will = need to be covered in the document before it can be really useful for = implementors. The document has a few other editorial and technical problems, like = describing the access_token field as a JWT with an encoded key. That=E2=80= =99s one of the options for the access token, but hardly the only. = It=E2=80=99s fine if it=E2=80=99s used in one of the examples, but we = shouldn=E2=80=99t confuse people that they need to use encrypted key = wrapping for PoP to work. Additionally, the use of the =E2=80=9Caudience=E2=80=9D parameter is = tied up with key management. The use is really pretty separate, since = depending on my setup I can manage the keys just fine without an = audience parameter, or require an audience parameter with no key = management. It=E2=80=99s really the same problem that we have with = Bearer tokens today: how does the RS get the info it needs about the = token? Audience parameters help with that but aren=E2=80=99t required = for functionality. To me this actually begs a larger question of how = scopes get overloaded in OAuth 2. I proposed a while back that we look = at three categories of scope-like things sent in parallel: time-based = things (token lifetime, do I get a refresh token, etc), target based = things (audience, resource), and access based things (the kind of stuff = that we thought scope was for in the first place, = read/write/delete/etc.). This is all for targeting the token and not = tied to PoP itself. =E2=80=94 Justin= From nobody Sun Feb 14 17:32:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD02F1A87E7 for ; Sun, 14 Feb 2016 17:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLww6w7-F9Ae for ; Sun, 14 Feb 2016 17:32:10 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720261A8776 for ; Sun, 14 Feb 2016 17:32:10 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s5so50863928qkd.0 for ; Sun, 14 Feb 2016 17:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4RFiFnW5Hk4/qsQwemcfLrLgYgAs7QxdEMZEV2JbrJY=; b=tSxICT6aZMd9rGaqW4YtZ+ztKbMSq6uh7LFkPp1xfPiSBhBN6yta2kN+fSzrsIkR2N F+wOFXLLz39RuU3zNJeXQt22nzHrKbzK5ISfp6PutUdkm99Iqt96t5AMZvfDA5IzsQI9 5AKtsxY3vciHRHwfCQW1JJpcDqHWZcU1R/lHA4BJhAl4mXnQcIVKrbdSvzFJuC+6K1MB zHdEhn9S28mkbOApPtX7jLWqoBIeNyQ3fWGy9ELi24eAdSXOSky8zV8xiQqgMh30E9JS kYWE5X68apKYPjVSETfkFPM/Vd9OiTriMVoZHlKLfKm7qlT4Z0oA1T2xJbIoYEFlCZxS JnVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4RFiFnW5Hk4/qsQwemcfLrLgYgAs7QxdEMZEV2JbrJY=; b=X+07Lu5TwtwqG8Kzt4c53mvs/06+0Qpkb4ngu1qDFrSZacetGrGiU1GIAlU0lOerPc udXfUr4oA3i9RG1z/EDUl2MarZO7HV1b/nfh+I9Bl7u84kUe/XlJnF1OCCm18JT+tkIZ TGhaKRag8HnDJMyDhUVQtV/N7Lu6EVjFD+7RhYdGhLLnhUDC4lRrs4FEnF86HluQq6/J Rlb+FPzvvOAgOvSYD1fBLpORfb0Il7EIOyxN9fiTeGzVKVtah8orXsY2RWStp/gHoLVU 7GTQy0cZ4I+p7puj8EgIymZQMe66WMoszKwYFOHXRtBAKt6TRmfJ3qQ5BBjjq49qKGyg RJYQ== X-Gm-Message-State: AG10YOSyskfvhAJDOARKp46RUj0fcUkfqD2bgW7CnRWOyXHP724cfg+SQuMd/YGyDzExwA== X-Received: by 10.55.73.68 with SMTP id w65mr17073216qka.68.1455499929507; Sun, 14 Feb 2016 17:32:09 -0800 (PST) Received: from [192.168.1.68] ([191.115.127.196]) by smtp.gmail.com with ESMTPSA id 200sm10143017qhm.47.2016.02.14.17.32.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Feb 2016 17:32:08 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2D24771F-A9B8-4B03-9A46-5373477C9556"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <5FBA28B8-77AB-4909-B915-27E0C43101CD@mit.edu> Date: Sun, 14 Feb 2016 22:32:04 -0300 Message-Id: <799CBA84-74FB-456E-BD5C-2D5A71973890@ve7jtb.com> References: <5FBA28B8-77AB-4909-B915-27E0C43101CD@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 01:32:13 -0000 --Apple-Mail=_2D24771F-A9B8-4B03-9A46-5373477C9556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline > On Feb 14, 2016, at 3:29 PM, Justin Richer wrote: >=20 > In PoP Key Distribution, I=E2=80=99m trying to figure out the full set = of expectations that the client and AS will need to handle across = different systems. =46rom what I gather, we=E2=80=99ve got at least = these: >=20 >=20 > Client provides public key: > - Client stores keypair > - Server stores public key > - Server returns public key > - Client makes sure the public key matches the request (?) >=20 Yes, sort of the public key is not returned to the client. It is = embedded in the cnf element of the AT if it is a JWT . See sec 5.2 > Client provides shared key: > - Client stores shared key > - Server stores shared key > - Server returns shared key > - Client makes sure the shared key matches (?) >=20 We did not so this one based on the assertion by some that the random = number generation on the mobile device is not good so it is better to = have it generated by the server. We have talked about having the client provide some entropy, but don=E2=80= =99t know if the complexity is worth it. > Server provides public key: > - Server generates keypair > - Server stores public key (and promises to not store the = private key?) > - Server returns the keypair > - Client stores the keypair >=20 Yes > Server provides shared key: > - Server generates shared key > - Server stores shared key > - Server returns shared key > - Client stores shared key >=20 Yes >=20 > First, I think it would be helpful to have this all laid out in the = document. Second, a few of these are confusingly non-parallel. If the = client sends the key, the server returns the public key. If the client = doesn=E2=80=99t send the key, the server returns the keypair (public and = private together). It makes sense why the responses are different, but = it=E2=80=99s strange to me that we=E2=80=99re asking client developers = to expect different things in the same field.=20 We are missing an example of the asymmetric response where the AS = provides the key. The value of the key parameter is always a JWK, You don=E2=80=99t get = it back in the response if you send it in the request. I will note looking at Sec 5.1 the text about using a thumbprint is = wrong. That was broken in the JWK thumbprint spec because the parameter = to say it is a thumbprint was removed from the spec (I argued for = keeping it for this use case but some people wanted the thumbprint to = just be a way to calculate a keyid. ) We need to remove the text or add = a cnf parameter to show it is a JWK thumb print. So it should always be a JWK in the key field in a response if it is = present. If that is unclear it needs fixing. >=20 > And then we have error conditions. What happens if the client provides = a key but the server rejects that key and creates its own to send to the = client? Does the client need to accept this key instead of its own? What = if the client sends a shared key and the server returns a keypair? = Should the server accept the same key from the client for multiple token = requests? I think all of these conditions (and likely a lot more) will = need to be covered in the document before it can be really useful for = implementors. Good point I would argue that the server should return an error if the = client sends a key that it is not supposed to, and not return a key. = That should be clarified. >=20 > The document has a few other editorial and technical problems, like = describing the access_token field as a JWT with an encoded key. That=E2=80= =99s one of the options for the access token, but hardly the only. = It=E2=80=99s fine if it=E2=80=99s used in one of the examples, but we = shouldn=E2=80=99t confuse people that they need to use encrypted key = wrapping for PoP to work. Agreed >=20 > Additionally, the use of the =E2=80=9Caudience=E2=80=9D parameter is = tied up with key management. The use is really pretty separate, since = depending on my setup I can manage the keys just fine without an = audience parameter, or require an audience parameter with no key = management. It=E2=80=99s really the same problem that we have with = Bearer tokens today: how does the RS get the info it needs about the = token? Audience parameters help with that but aren=E2=80=99t required = for functionality. To me this actually begs a larger question of how = scopes get overloaded in OAuth 2. I proposed a while back that we look = at three categories of scope-like things sent in parallel: time-based = things (token lifetime, do I get a refresh token, etc), target based = things (audience, resource), and access based things (the kind of stuff = that we thought scope was for in the first place, = read/write/delete/etc.). This is all for targeting the token and not = tied to PoP itself. >=20 The relationship between audience and pop is that for symmetric keys you = need to know what key to use to encrypt to the RS and that requires = knowing the RS. That was why we put Audience in this spec , as we didn=E2=80=99t have it = any place else even though it is in use in the wild in some cases.=20 We probably should move it to it=E2=80=99s own spec along with any = other useful parameters. We do sort of have a tension between the client knowing where the = resource is and asking for a token type based on the pop presentment and = alg based on alg support, and a view that it is the RS that is going to = tell the client where it is going to use the token based on scopes = (Nat=E2=80=99s link relationship takes the later view more or less)=20 We are pushing a lot of complexity into the client to have knowledge of = all the endpoints and configure itself/ask for the correct thing. One alternative might be to have the client register the presentment = mechanisms, algs and public keys it supports as part of client = registration and have the server just provide all the correct info based = on the resource. That is different from this spec but might be worth = considering if this is too complicated for client developers. John B. > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2D24771F-A9B8-4B03-9A46-5373477C9556 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTUwMTMyMDVaMCMGCSqGSIb3DQEJBDEWBBRI01OC3Zaq9u9s4x3av2BB SlabBjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCMAp6lWbowW5hxCz2oBf5mICbwu+uqCTb5uaZWN3N51GJJDYuByTBU np5KP1Bn42qG4cdrNdh1o5HtY5eGhKty6p3fbIrvy9iI6fR+Sxnf2QjDqUxRbAeTus1NWeRq/nqk HFoz4vfGE//lFcyAkFisGdO7Pw5ICC9EpgZFAYLl5nlvKIzk7zB/OyjT0V4Bnc278hM7vQEwgFqt 5CfWU49Rkhf1qVCmDilVXzc6vG1e/Drp28POIap5JtHRSfZiLV3x6AhSl9XbXk4Jazm8M7/4fNdx dYIka4PE0kRKkDW9r4WKldIvLhLgG5C7ZXk2UgkCfkN4ZoLiHBW7k2c3r/FYAAAAAAAA --Apple-Mail=_2D24771F-A9B8-4B03-9A46-5373477C9556-- From nobody Mon Feb 15 14:36:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842F11A014C for ; Mon, 15 Feb 2016 14:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 gs6vhoLQj3Gh for ; Mon, 15 Feb 2016 14:36:28 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7794F1A00D8 for ; Mon, 15 Feb 2016 14:36:28 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id wb13so232724727obb.1 for ; Mon, 15 Feb 2016 14:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ozSdEB1O4whCc4qyNCMany7hvh6bKb04HtilOIdTP7A=; b=Nx6k9K2rej7rgwaedINdLYjNXOtcmkoIPkON4Fsp3/mzRtohSwPfTyH/MmuopdbD7W 6I1VjzjZwt+Vmjo6XRjlz2mHBvWqpG+FrXh1VfoqAvWL/5iBL2reVCx4s9KaA+Pnzk3p 99rA4sFgNDtoo0ULMforgkqoUQEsymYjY/P0u+kpL/l7Plyy8OHdIA00sTG/+ectGahP kCFBw1ee5MwTM+jcbCZRPUwVKhB074FI2cF2jrU7PRXYJl/VQBRE60Y3LqYXVz6lniTj JA7F/4s27fuenAo3pJLVvnzCpmLryak+kRWyFoPG6ylUgCAzg+YcW/kPFpURklfud3Y/ SJlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ozSdEB1O4whCc4qyNCMany7hvh6bKb04HtilOIdTP7A=; b=cioA+RcR3kJVFIzIiLWPd6oAXV40AKrsLAMh18PZSNg6LlwnrRdD7wychoXYX4rJhA KN6eLlXYXnzVgtb9/UKF2axhKtTM3mG7W9OiClLiKhvEZ2XUwHa9KWvb6JwTXCcHRyN5 ByJrApWsc664lBriOTew5H3tyvCpQoddJoLuZes6CnGRq7tyQKiHC/ZtNyH/rMCXeAFq hQcfbbp3AFj/tzKjsZXBytU3mUujQ6RAEZAcTNjtg5K0mMr6SR/8BfFF6hVyJdx7ZfNM aQ2tn99d9ixY//g+V0suliAS6kM/OgK77aWBR8Q/Cem0FBADUoWWhNZhkjkH85jDZ37S YJpg== X-Gm-Message-State: AG10YOTQh/zZ3xa7spQx4lqr7tm4jeJkrtZMsysowXBPaFM8f/f3ZpkY9ib8Mzq6gVbY/h84VLYAC6FqsYwFVIHi X-Received: by 10.60.35.201 with SMTP id k9mr14703194oej.3.1455575787560; Mon, 15 Feb 2016 14:36:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Mon, 15 Feb 2016 14:36:07 -0800 (PST) In-Reply-To: <56C0816B.8070005@lodderstedt.net> References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> From: William Denniss Date: Mon, 15 Feb 2016 14:36:07 -0800 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=089e011613bcc32660052bd6a542 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:36:33 -0000 --089e011613bcc32660052bd6a542 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID Connect), e.g.: https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdeve= lopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D407408= 718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt=3D= force&access_type=3Doffline&max_age=3D1 The reason we do this is to be explicit about how we are processing the "max_age" reauth request, specifically that we don't always prompt the user to reauthenticate directly (but do perform in-session risk analysis). I can see us potentially using the more generic amr values like "user", and "mfa" but we will probably avoid very specific ones like "sms" or "otp" to avoid brittle relationships with RPs. That said, I don't object to those being in the registry, perhaps there is value in some tightly coupled enterprise configurations. On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Denniss, > > out of curiosity: Does Google use amr values? > > best regards, > Torsten. > > > Am 14.02.2016 um 02:40 schrieb William Denniss: > > > > On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > wrote: > >> It's an acceptable fallback option if the working group decides it >> doesn't want to register the values that are already in production use a= t >> the time we establish the registry. But add William points out, Google i= s >> already using some of these values. Microsoft is using some of them. The >> OpenID MODRNA specs are using some of them. So it seems more efficient t= o >> register them at the same time. >> >> That would be my preference. >> > > +1, it is also my preference to register the current values. > > I don't see any harm in the spec that establishes the registry also > seeding it with all known values in use at the time of drafting, regardle= ss > of the group that originally specified them. Makes the original spec more > useful, and avoids the need to submit each value for consideration > separately =E2=80=93 they can be all be reviewed at the same time. > > > From: Justin Richer >> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >> To: Phil Hunt >> >> Cc: >> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >> Adoption Finalized >> >> Can we just do that, then? Seems to be the easiest way to address variou= s >> needs and concerns. >> >> =E2=80=94 Justin >> >> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) >> wrote: >> >> Yes >> >> Phil >> >> On Feb 13, 2016, at 07:59, " >> torsten@lodderstedt.net" wrote: >> >> So basically, the RFC could also just establish the new registry and oid= f >> could feel in the values? >> >> (just trying to understand) >> >> >> -------- Originalnachricht -------- >> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for >> Adoption Finalized >> Von: Mike Jones < >> Michael.Jones@microsoft.com> >> An: torsten@lodderstedt.net,John Bradley < >> ve7jtb@ve7jtb.com> >> Cc: oauth@ietf.org >> >> The context that most people on this thread probably don=E2=80=99t have = is that >> an IANA registry can only be established by an RFC. Non-RFC >> specifications, such as OpenID specifications, can **register** values >> in a registry, but they cannot **establish** a registry. The OpenID >> Foundation inquired about this with the IETF before OpenID Connect was >> finalized and learned that its specifications could not establish IANA >> registries. Otherwise, they would have. >> >> >> >> Instead, RFCs need to be created to establish registries =E2=80=93 even = for >> values first defined in non-RFC specifications. This specification is o= ne >> example of doing this. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth [ mailto:oauth-bounces@ietf.org >> ] *On Behalf Of * >> torsten@lodderstedt.net >> *Sent:* Saturday, February 13, 2016 6:37 AM >> *To:* John Bradley < ve7jtb@ve7jtb.com> >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values: Call >> for Adoption Finalized >> >> >> >> We clearly have this problem between oauth and oidc. Just take a look at >> the discovery thread. >> >> According to you argument I see two options: >> (1) amr stays an oidc claim, is used in oidc only and the oauth wg just >> publishes the registry entries. In this case, the spec should clearly >> explain this. >> (2) amr is of any use in oauth (although it has been invented in oidc) - >> than define it and motivate it's use in oauth in this spec. >> >> Right now, I think it creates the impression oauth is for authentication= . >> >> >> >> -------- Originalnachricht -------- >> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >> Adoption Finalized >> Von: John Bradley < ve7jtb@ve7jtb.com> >> An: torsten@lodderstedt.net >> Cc: roland.hedberg@umu.se,oauth@ietf.org >> >> This is not a issue between oauth and OIDC. >> >> >> >> This has to do with the registry for JWT being in OAuth. Many protocol= s >> that use JWT are going to want to register claims. >> >> We can=E2=80=99t ask them to all move the parts of there specs that use = JWT to >> OAuth. >> >> >> >> Perhaps JWT should have been part of JOSE, but that is water under the >> bridge. >> >> >> >> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we wi= ll need >> to deal with registering claims. >> >> >> >> I guess that we can tell people that they need to publish the specs >> defining the claims someplace else, and just do the registry part. >> >> However doing that will probably not improve interoperability and >> understanding. >> >> >> >> This document defines the claim for JWT in general. We still have almos= t >> no documentation in the WG about what a JWT access token would contain >> other than the POP work. >> >> >> >> John B. >> >> On Feb 13, 2016, at 9:18 AM, >> torsten@lodderstedt.net wrote: >> >> >> >> I basically support adoption of this document. Asserting authentication >> methods in access tokens (in this case in JWTS format) is reasonable. We >> use it to pass information about the authentication performed prior issu= ing >> an access token to the _resource_ server. >> >> What worries me is the back and forth between oauth and oidc. The amr >> claim is defined in oidc (which sits on top of oauth) but the oauth wg >> specifies the registry? Moreover, the current text does not give a >> rationale for using amr in context of oauth. >> >> As a WG we need to find a clear delineation between both protocols, >> otherwise noone will really understand the difference and when to use wh= at. >> We create confusion! >> >> For this particular draft this means to either move amr to oauth or the >> registry to oidc. >> >> best regards, >> Torsten. >> >> >> >> -------- Urspr=C3=BCngliche Nachricht -------- >> Von: Roland Hedberg < roland.hedberg@umu.se> >> Gesendet: Friday, February 12, 2016 05:45 PM >> An: oauth@ietf.org >> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >> Adoption Finalized >> >> +1 >> >> > 12 feb 2016 kl. 16:58 skrev John Bradley < >> ve7jtb@ve7jtb.com>: >> > >> > +1 to adopt this draft. >> > >> >> On Feb 12, 2016, at 3:07 AM, Mike Jones < >> Michael.Jones@microsoft.com> wrote: >> >> >> >> Draft -05 incorporates the feedback described below - deleting the >> request parameter, noting that this spec isn't an encouragement to use >> OAuth 2.0 for authentication without employing appropriate extensions, a= nd >> no longer requiring a specification for IANA registration. I believe th= at >> it=E2=80=99s now ready for working group adoption. >> >> >> >> -- Mike >> >> >> >> -----Original Message----- >> >> From: OAuth [ mailto:oauth-bounces@ietf.org >> ] On Behalf Of Hannes Tschofenig >> >> Sent: Thursday, February 4, 2016 11:23 AM >> >> To: oauth@ietf.org >> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for >> Adoption Finalized >> >> >> >> Hi all, >> >> >> >> On January 19th I posted a call for adoption of the Authentication >> Method Reference Values specification, see >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html >> >> >> >> What surprised us is that this work is conceptually very simple: we >> define new claims and create a registry with new values. Not a big deal = but >> that's not what the feedback from the Yokohama IETF meeting and the >> subsequent call for adoption on the list shows. The feedback lead to mix= ed >> feelings and it is a bit difficult for Derek and myself to judge consens= us. >> >> >> >> Let me tell you what we see from the comments on the list. >> >> >> >> In his review at >> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James >> Manger asks for significant changes. Among other things, he wants to rem= ove >> one of the claims. He provides a detailed review and actionable items. >> >> >> >> William Denniss believes the document is ready for adoption but agree= s >> with some of the comments from James. Here is his review: >> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >> >> >> >> Justin is certainly the reviewer with the strongest opinion. Here is >> one of his posts: >> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >> >> >> >> Among all concerns Justin expressed the following one is actually >> actionable IMHO: Justin is worried that reporting how a person >> authenticated to an authorization endpoint and encouraging people to use >> OAuth for authentication is a fine line. He believes that this document >> leads readers to believe the latter. >> >> >> >> John agrees with Justin in >> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we >> need to make sure that people are not mislead about the intention of the >> document. John also provides additional comments in this post to the >> >> list: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >> >> Most of them require more than just editing work. For example, method= s >> listed are really not useful, >> >> >> >> Phil agrees with the document adoption but has some remarks about the >> registry although he does not propose specific text. His review is here: >> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >> >> >> >> With my co-chair hat on: I just wanted to clarify that registering >> claims (and values within those claims) is within the scope of the OAuth >> working group. We standardized the JWT in this group and we are also >> chartered to standardize claims, as we are currently doing with various >> drafts. Not standardizing JWT in the IETF would have lead to reduced >> interoperability and less security. I have no doubts that was a wrong >> decision. >> >> >> >> In its current form, there is not enough support to have this documen= t >> as a WG item. >> >> >> >> We believe that the document authors should address some of the easie= r >> comments and submit a new version. This would allow us to reach out to >> those who had expressed concerns about the scope of the document to >> re-evaluate their decision. A new draft version should at least address = the >> following issues: >> >> >> >> * Clarify that this document is not an encouragement for using OAuth >> as an authentication protocol. I believe that this would address some of >> the concerns raised by Justin and John. >> >> >> >> * Change the registry policy, which would address one of the comments >> from James, William, and Phil. >> >> >> >> Various other items require discussion since they are more difficult >> to address. For example, John noted that he does not like the use of >> request parameters. Unfortunately, no alternative is offered. I urge Joh= n >> to provide an alternative proposal, if there is one. Also, the remark th= at >> the values are meaningless could be countered with an alternative propos= al. >> James wanted to remove the "amr_values" parameter. >> >> Is this what others want as well? >> >> >> >> After these items have been addressed we believe that more folks in >> the group will support the document. >> >> >> >> Ciao >> >> Hannes & Derek >> >> >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/oauth >> >> =E2=80=94 Roland >> >> =E2=80=9DEverybody should be quiet near a little stream and listen." >> >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --089e011613bcc32660052bd6a542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We return 'amr' claims in ID Tokens if "= max_age" is requested (per OpenID Connect), e.g.:

= https://accounts.google.com/o/oauth2/auth?redirect_uri= =3Dhttps%3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_type= =3Dcode&client_id=3D407408718192.apps.googleusercontent.com&scope= =3Dopenid+profile&approval_prompt=3Dforce&access_type=3Doffline&= ;max_age=3D1

The reason we do this is to be expl= icit about how we are processing the "max_age" reauth request, sp= ecifically that we don't always prompt the user to reauthenticate direc= tly (but do perform in-session risk analysis).

I c= an see us potentially using the more generic amr values like "user&quo= t;, and "mfa" but we will probably avoid very specific ones like = "sms" or "otp" to avoid brittle relationships with RPs.= That said, I don't object to those being in the registry, perhaps ther= e is value in some tightly coupled enterprise configurations.

On Sun, Fe= b 14, 2016 at 5:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.

I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be reviewe= d at the same time.=C2=A0


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>=
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns.=C2=A0

=C2=A0=E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net&quo= t; <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>=
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread probably don=E2=80=99= t have is that an IANA registry can only be established by an RFC.=C2=A0 Non-RFC specifications= , such as OpenID specifications, can *register* values in a registry, but they cannot *establish* a registry.=C2=A0 The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.=C2=A0 Otherwise, they would have.

=C2=A0

Instead, RFCs need to be created to establish registries =E2=80=93 ev= en for values first defined in non-RFC specifications.=C2=A0 Thi= s specification is one example of doing this.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

=C2=A0

We clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf= .org

This is not a issue between oauth and OIDC.

=C2=A0

This has to do with the registry for JWT being in OAuth. =C2=A0 Many protocols that use JWT are going to want to register claims. =C2=A0

We can=E2=80= =99t ask them to all move the parts of there specs that use JWT to OAuth.

=C2=A0

Perhaps JWT should have been part of JOSE, but that is water under the bridge. =C2=A0

=C2=A0

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we wil= l need to deal with registering claims. =C2=A0

=C2=A0

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

=C2=A0

This document defines the claim for JWT in general.=C2=A0 We still ha= ve almost no documentation in the WG about what a JWT access token would contain other than the POP work.

=C2=A0

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lo= dderstedt.net wrote:

=C2=A0

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se> Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.=C2=A0 I belie= ve that it=E2=80=99s now ready= for working group adoption.
>>
>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/= msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/= msg15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> ___________________________= ____________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf= .org/mailman/listinfo/oauth
>
> ___________________________= ____________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org= /mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should b= e quiet near a little stream and listen." >From =E2=80=99Open Hous= e for Butterflies=E2=80=99 by Rut= h Krauss


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

______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

=C2=A0

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


_______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oau= th




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


--089e011613bcc32660052bd6a542-- From nobody Mon Feb 15 15:18:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA621A6EED for ; Mon, 15 Feb 2016 15:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=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 4zV1QAqc2fw5 for ; Mon, 15 Feb 2016 15:18:31 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 3591D1A88F9 for ; Mon, 15 Feb 2016 15:18:31 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id 5so65943145igt.0 for ; Mon, 15 Feb 2016 15:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CEppsLplk28hf/bXseAOUDpt6UafWjpjFFkfyhfdvZM=; b=RfyW9L5eqbi6tr6uNMV/6Jlx54yZakd2nZjXc1t5uSTJQuI3OqGjHuqNZdvB/gKUUB XrdcUuQm16/AILuuT0KyGRJQs2PUECInQLJ9VqBo5pNDQc9tMtkWB5lzBPHZeaYL7CSD HAHlMrow8wVi/dFZtqNCuNJX6QjO2PJb237+qMNsOYGpaI7AJ/ydDbQ8mnRHRjDq1cqZ TAZZSIwgMTfXKJpSZrc2C0I/z/qW3RHIuVx1r8vm96Z//G7jwJ+lyeTKJCIBUTUBlXPB KzzxhAnOwCuTZ3MAOuDSkqu1yjHHvGZwZPchHGxDLCnoBY2nP/m9fE0RRsk6/cg/EB2r RVjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CEppsLplk28hf/bXseAOUDpt6UafWjpjFFkfyhfdvZM=; b=bnVuYNB36bGfqFCXgeexXuY2dOV4qXUHVC8797nzhwJPY7/RBp0LoONsVuqx+qkqVR VfwrWEtDJ5R3nssUj9NPMF7jXfkkkj86CxCRk2D5+b/QInoaxaXSoFAeePFIQzQpzUAp 7PADhwLZ2sO2GKgD9Idypl3LC4jPg3SOwt9BuvxflLGGnCFP8Mzz/KJ9A5tZHieHONYT 81PWErsMqvGR6h/XE/jCZFJvaKr5tcCNWevRKBBv+GRLVs/FtmAOB/09s7g1jdONUPqn 0CMjqCc/ORwqRBd7SbHCVRW/BfqNsXbnCzt2T7jlzms0PBAhNc1i70iJ/G5QTpWfjdQ1 m89A== X-Gm-Message-State: AG10YOQWPIj5JqkSzQhp0eKO6MiPpiLm2AgOzQ/oGWjb/1XLxZJcTwg1b3wd2sZvTgP4Sn1k+hvRX3jnnEcO3Fcc MIME-Version: 1.0 X-Received: by 10.50.29.51 with SMTP id g19mr13713771igh.41.1455578310409; Mon, 15 Feb 2016 15:18:30 -0800 (PST) Received: by 10.36.62.69 with HTTP; Mon, 15 Feb 2016 15:18:30 -0800 (PST) In-Reply-To: References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> Date: Mon, 15 Feb 2016 16:18:30 -0700 Message-ID: From: Eduardo Gueiros To: Adam Lewis Content-Type: multipart/alternative; boundary=e89a8f8399b7229c94052bd73cb7 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:18:33 -0000 --e89a8f8399b7229c94052bd73cb7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Being in the mobile space myself and constantly meeting with native app developers I've heard my share of horror stories on how OAuth was implemented, myself being guilty of being "creative" around OAuth. This draft is be of great value to those of us who are around these developers, we'll be helping bringing awareness about the correct practices suggested in the document. On Fri, Feb 5, 2016 at 8:10 AM, Adam Lewis wrote: > +1 that it should be Informational. > > Also, I never got to respond to the original request, but I am heavily in > favor of this draft. I talk with a lot of native app developers who are > clueless about how to implement OAuth. The core RFC is very web app > oriented. I look forward to having a more profiled RFC to point them to = :-) > > adam > > On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer wrote: > >> I=E2=80=99d like to note that when Tony brought up it being Experimental= on the >> list, several of us (myself included) pointed out that Informational is = the >> correct designation for this specification. >> >> =E2=80=94 Justin >> >> > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> > >> > Hi all, >> > >> > On January 19th I posted a call for adoption of the OAuth 2.0 for Nati= ve >> > Apps specification, see >> > http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html >> > >> > There was very positive feedback during the Yokohama IETF meeting to >> > work on this document in the OAuth working group. More than 10 persons >> > responded positively to the call on the mailing list as well. >> > >> > Several persons provided additional input for content changes during t= he >> > call and here are the relevant links: >> > http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html >> > http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html >> > http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html >> > >> > Tony also noted that this document should become an Experimental RFC >> > rather than a Standards Track RFC. The chairs will consult with the >> > Security Area directors on this issue. >> > >> > To conclude, based on the call will >> > become the starting point for work in OAuth. Please submit the documen= t >> > as draft-ietf-oauth-native-apps-00.txt. >> > >> > Ciao >> > Hannes & Derek >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 --=20 *Eduardo Gueiros* *Director, Mobile B.U.* | Jive Communications, Inc. jive.com | *egueiros@jive.com * --e89a8f8399b7229c94052bd73cb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 Being in the mobile space myself and constantly meeting= with native app developers I've heard my share of horror stories on ho= w OAuth was implemented, myself being guilty of being "creative" = around OAuth.=C2=A0

This draft is be of great value to t= hose of us who are around these developers, we'll be helping bringing a= wareness about the correct practices suggested in the document.=C2=A0
=

On Fri, Feb= 5, 2016 at 8:10 AM, Adam Lewis <adam.lewis@motorolasolutio= ns.com> wrote:
+1 that it should be Informational.

Also, I never g= ot to respond to the original request, but I am heavily in favor of this dr= aft. I talk with a lot of native app developers who are clueless about how = to implement OAuth.=C2=A0 The core RFC is very web app oriented.=C2=A0 I lo= ok forward to having a more profiled RFC to point them to :-)

adam

On Thu, Feb 4, 2016 at 7:13 PM, Justin= Richer <jricher@mit.edu> wrote:
I=E2=80=99d like to note that when Tony brought up it being Experiment= al on the list, several of us (myself included) pointed out that Informatio= nal is the correct designation for this specification.

=C2=A0=E2=80=94 Justin

> On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:
>
> Hi all,
>
> On January 19th I posted a call for adoption of the OAuth 2.0 for Nati= ve
> Apps specification, see
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15400.html
>
> There was very positive feedback during the Yokohama IETF meeting to > work on this document in the OAuth working group. More than 10 persons=
> responded positively to the call on the mailing list as well.
>
> Several persons provided additional input for content changes during t= he
> call and here are the relevant links:
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15434.html
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15435.html
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15438.html
>
> Tony also noted that this document should become an Experimental RFC > rather than a Standards Track RFC. The chairs will consult with the > Security Area directors on this issue.
>
> To conclude, based on the call <draft-wdenniss-oauth-native-apps>= ; will
> become the starting point for work in OAuth. Please submit the documen= t
> as draft-ietf-oauth-native-apps-00.txt.
>
> Ciao
> Hannes & Derek
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


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



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




--
--=C2=A0
<= div dir=3D"ltr">Eduardo Gueiros<= /b>
Director, Mobile = B.U.=C2=A0| =C2=A0Jive Communications, Inc.
jive.com=C2=A0= =C2=A0| =C2=A0egueiros@jive.com
--e89a8f8399b7229c94052bd73cb7-- From nobody Mon Feb 15 15:22:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A381A8A11 for ; Mon, 15 Feb 2016 15:22:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZHr51EszAcm for ; Mon, 15 Feb 2016 15:22:31 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 63DEE1A87E2 for ; Mon, 15 Feb 2016 15:22:31 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id q63so93947163pfb.0 for ; Mon, 15 Feb 2016 15:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bE3X450A7u01q06ePOWt/6iEVPLF/i3KTGub3Xi4mfw=; b=OVsvpr8467Ax9VMpF42O7e3KqqdqiniKaA1TvGjBK2F2FK2HIHRPUwUgeNAJAN81LS xbTtaXeG163HDaddli8eKpFJEnyfgpV9UzEX/P2dD1fra33eS75vTTFrGkkadZ3/VNPN k/cQaBmRJgK/6AEwVH5fOw+Rh6ip6LLCAel7NYk7fE7LILp8BU/P+3gUTSbyHx3zGmJb /V/4u3ZpmYMG5tAKaim7p2DcrvHxo5kMBooIRACd0ECUGNl43GQaNyCvlZuZaiRzLEpk bB8tW3RkG196O0nohtVmiTvjpep8yMIA3i8ly68qNMgMSU60pt8VMC++/bxBG0osPtf7 CdIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bE3X450A7u01q06ePOWt/6iEVPLF/i3KTGub3Xi4mfw=; b=AmpYh0CFQNExk5zkzplEWqy63EDR0i8YpLTRFmfV2p41g30hd5F7TfOj8evW+/9MIk S/PAflzgOCw5zluOwoCueA6tpxzfVwSoKAkhJBu+prqPrROgeMOCgjjqqyJ/gmYwmsYP BlYupoQFQJpAA300xDwUMRURHQnjL2cXz/lPuzcpEAnGoLOtiAlrNPwRLkZb6QQ2fCbV A4pi3vVwxtMMR+WXqLKfJhuUHWdjFHeJMmdabBknNEypVexzQ0txwooKNK6+OlOCUK4X aA+mSU/AwFyU3sYvosw/mMOhFx1XWRV9bp0LazuETDHzEH+w4SOT1l6XCz4rI47/XETc fbCA== X-Gm-Message-State: AG10YOTdg9u7z+G5Z1aMGRxO1hy53CJjZvR+X0r5prCW//bDwQjWRd4dUJqRvPhCo4GHSlJ1 X-Received: by 10.98.66.75 with SMTP id p72mr27321031pfa.50.1455578550927; Mon, 15 Feb 2016 15:22:30 -0800 (PST) Received: from [10.10.3.22] (wsip-174-67-124-2.ph.ph.cox.net. [174.67.124.2]) by smtp.gmail.com with ESMTPSA id p21sm40864408pfj.67.2016.02.15.15.22.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 15:22:29 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-AE91CD48-2353-4DB4-93A9-DE0E830CF58E Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Mon, 15 Feb 2016 16:22:28 -0700 Content-Transfer-Encoding: 7bit Message-Id: <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> To: William Denniss Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:22:37 -0000 --Apple-Mail-AE91CD48-2353-4DB4-93A9-DE0E830CF58E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Polite comment, Google in general is pretty "open" about session management i= n general - long idle timeout and no apparent absolute timeout. For a bank o= r other organization that produces high risk software, this is not standard p= ractice. Re-authentication is a critical security boundary, not prompting th= e user for re-authentication credentials is unacceptable in those environmen= ts. I may be jumping in out of context, but fair? -- Jim Manico @Manicode +1 (808) 652-3805 > On Feb 15, 2016, at 3:36 PM, William Denniss wrote: >=20 > We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID C= onnect), e.g.: >=20 > https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdev= elopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D407408= 718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt=3Df= orce&access_type=3Doffline&max_age=3D1 >=20 > The reason we do this is to be explicit about how we are processing the "m= ax_age" reauth request, specifically that we don't always prompt the user to= reauthenticate directly (but do perform in-session risk analysis). >=20 > I can see us potentially using the more generic amr values like "user", an= d "mfa" but we will probably avoid very specific ones like "sms" or "otp" to= avoid brittle relationships with RPs. That said, I don't object to those be= ing in the registry, perhaps there is value in some tightly coupled enterpri= se configurations. >=20 >=20 >> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt wrote: >> Hi Denniss, >>=20 >> out of curiosity: Does Google use amr values?=20 >>=20 >> best regards, >> Torsten. >>=20 >>=20 >>> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>=20 >>>=20 >>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones wrote: >>>> It's an acceptable fallback option if the working group decides it does= n't want to register the values that are already in production use at the ti= me we establish the registry. But add William points out, Google is already u= sing some of these values. Microsoft is using some of them. The OpenID MODRN= A specs are using some of them. So it seems more efficient to register them a= t the same time. >>>>=20 >>>> That would be my preference. >>>=20 >>> +1, it is also my preference to register the current values. >>>=20 >>> I don't see any harm in the spec that establishes the registry also seed= ing it with all known values in use at the time of drafting, regardless of t= he group that originally specified them. Makes the original spec more useful= , and avoids the need to submit each value for consideration separately =E2=80= =93 they can be all be reviewed at the same time.=20 >>>=20 >>>=20 >>>> From: Justin Richer >>>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>>> To: Phil Hunt >>>>=20 >>>> Cc: >>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call fo= r Adoption Finalized >>>>=20 >>>> Can we just do that, then? Seems to be the easiest way to address vario= us needs and concerns.=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) w= rote: >>>>>=20 >>>>> Yes >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" wrote: >>>>>=20 >>>>>> So basically, the RFC could also just establish the new registry and o= idf could feel in the values? >>>>>>=20 >>>>>> (just trying to understand) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -------- Originalnachricht -------- >>>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>> Von: Mike Jones >>>>>> An: torsten@lodderstedt.net,John Bradley >>>>>> Cc: oauth@ietf.org >>>>>>=20 >>>>>> The context that most people on this thread probably don=E2=80=99t ha= ve is that an IANA registry can only be established by an RFC. Non-RFC spec= ifications, such as OpenID specifications, can *register* values in a regist= ry, but they cannot *establish* a registry. The OpenID Foundation inquired a= bout this with the IETF before OpenID Connect was finalized and learned that= its specifications could not establish IANA registries. Otherwise, they wo= uld have. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Instead, RFCs need to be created to establish registries =E2=80=93 ev= en for values first defined in non-RFC specifications. This specification i= s one example of doing this. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodd= erstedt.net >>>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>>> To: John Bradley >>>>>> Cc: oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> We clearly have this problem between oauth and oidc. Just take a look= at the discovery thread. >>>>>>=20 >>>>>> According to you argument I see two options: >>>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg ju= st publishes the registry entries. In this case, the spec should clearly exp= lain this. >>>>>> (2) amr is of any use in oauth (although it has been invented in oidc= ) - than define it and motivate it's use in oauth in this spec. >>>>>>=20 >>>>>> Right now, I think it creates the impression oauth is for authenticat= ion. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -------- Originalnachricht -------- >>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>> Von: John Bradley >>>>>> An: torsten@lodderstedt.net >>>>>> Cc: roland.hedberg@umu.se,oauth@ietf.org >>>>>>=20 >>>>>> This is not a issue between oauth and OIDC. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> This has to do with the registry for JWT being in OAuth. Many proto= cols that use JWT are going to want to register claims. =20 >>>>>>=20 >>>>>> We can=E2=80=99t ask them to all move the parts of there specs that u= se JWT to OAuth. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Perhaps JWT should have been part of JOSE, but that is water under th= e bridge. =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we= will need to deal with registering claims. =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I guess that we can tell people that they need to publish the specs d= efining the claims someplace else, and just do the registry part. >>>>>>=20 >>>>>> However doing that will probably not improve interoperability and und= erstanding. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> This document defines the claim for JWT in general. We still have al= most no documentation in the WG about what a JWT access token would contain o= ther than the POP work. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I basically support adoption of this document. Asserting authenticati= on methods in access tokens (in this case in JWTS format) is reasonable. We u= se it to pass information about the authentication performed prior issuing a= n access token to the _resource_ server. >>>>>>=20 >>>>>> What worries me is the back and forth between oauth and oidc. The amr= claim is defined in oidc (which sits on top of oauth) but the oauth wg spec= ifies the registry? Moreover, the current text does not give a rationale for= using amr in context of oauth. >>>>>>=20 >>>>>> As a WG we need to find a clear delineation between both protocols, o= therwise noone will really understand the difference and when to use what. W= e create confusion! >>>>>>=20 >>>>>> For this particular draft this means to either move amr to oauth or t= he registry to oidc. >>>>>>=20 >>>>>> best regards,=20 >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -------- Urspr=C3=BCngliche Nachricht -------- >>>>>> Von: Roland Hedberg >>>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>>> An: oauth@ietf.org >>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley : >>>>>> >=20 >>>>>> > +1 to adopt this draft. >>>>>> >=20 >>>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones wrote: >>>>>> >>=20 >>>>>> >> Draft -05 incorporates the feedback described below - deleting the= request parameter, noting that this spec isn't an encouragement to use OAut= h 2.0 for authentication without employing appropriate extensions, and no lo= nger requiring a specification for IANA registration. I believe that it=E2=80= =99s now ready for working group adoption. >>>>>> >>=20 >>>>>> >> -- Mike >>>>>> >>=20 >>>>>> >> -----Original Message----- >>>>>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig >>>>>> >> Sent: Thursday, February 4, 2016 11:23 AM >>>>>> >> To: oauth@ietf.org >>>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>> >>=20 >>>>>> >> Hi all, >>>>>> >>=20 >>>>>> >> On January 19th I posted a call for adoption of the Authentication= Method Reference Values specification, see http://www.ietf.org/mail-archive= /web/oauth/current/msg15402.html >>>>>> >>=20 >>>>>> >> What surprised us is that this work is conceptually very simple: w= e define new claims and create a registry with new values. Not a big deal bu= t that's not what the feedback from the Yokohama IETF meeting and the subseq= uent call for adoption on the list shows. The feedback lead to mixed feeling= s and it is a bit difficult for Derek and myself to judge consensus. >>>>>> >>=20 >>>>>> >> Let me tell you what we see from the = comments on the list. >>>>>> >>=20 >>>>>> >> In his review at >>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html J= ames Manger asks for significant changes. Among other things, he wants to re= move one of the claims. He provides a detailed review and actionable items. >>>>>> >>=20 >>>>>> >> William Denniss believes the document is ready for adoption but ag= rees with some of the comments from James. Here is his review: >>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>>>>> >>=20 >>>>>> >> Justin is certainly the reviewer with the strongest opinion. Here i= s one of his posts: >>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>>>>> >>=20 >>>>>> >> Among all concerns Justin expressed the following one is actually a= ctionable IMHO: Justin is worried that reporting how a person authenticated t= o an authorization endpoint and encouraging people to use OAuth for authenti= cation is a fine line. He believes that this document leads readers to belie= ve the latter. >>>>>> >>=20 >>>>>> >> John agrees with Justin in >>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html t= hat we need to make sure that people are not mislead about the intention of t= he document. John also provides additional comments in this post to the >>>>>> >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.= html >>>>>> >> Most of them require more than just editing work. For example, met= hods listed are really not useful, >>>>>> >>=20 >>>>>> >> Phil agrees with the document adoption but has some remarks about t= he registry although he does not propose specific text. His review is here: >>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>>>>> >>=20 >>>>>> >> With my co-chair hat on: I just wanted to clarify that registering= claims (and values within those claims) is within the scope of the OAuth wo= rking group. We standardized the JWT in this group and we are also chartered= to standardize claims, as we are currently doing with various drafts. Not s= tandardizing JWT in the IETF would have lead to reduced interoperability and= less security. I have no doubts that was a wrong decision. >>>>>> >>=20 >>>>>> >> In its current form, there is not enough support to have this docu= ment as a WG item. >>>>>> >>=20 >>>>>> >> We believe that the document authors should address some of the ea= sier comments and submit a new version. This would allow us to reach out to t= hose who had expressed concerns about the scope of the document to re-evalua= te their decision. A new draft version should at least address the following= issues: >>>>>> >>=20 >>>>>> >> * Clarify that this document is not an = encouragement for using OAuth as an authentication prot= ocol. I believe that this would address some of the concerns raised by Justi= n and John. >>>>>> >>=20 >>>>>> >> * Change the registry policy, which would address one of the comme= nts from James, William, and Phil. >>>>>> >>=20 >>>>>> >> Various other items require discussion since they are more difficu= lt to address. For example, John noted that he does not like the use of requ= est parameters. Unfortunately, no alternative is offered. I urge John to pro= vide an alternative proposal, if there is one. Also, the remark that the val= ues are meaningless could be countered with an alternative proposal. James w= anted to remove the "amr_values" parameter. >>>>>> >> Is this what others want as well? >>>>>> >>=20 >>>>>> >> After these items have been addressed we believe that more folks i= n the group will support the document. >>>>>> >>=20 >>>>>> >> Ciao >>>>>> >> Hannes & Derek >>>>>> >>=20 >>>>>> >>=20 >>>>>> >>=20 >>>>>> >> _______________________________________________ >>>>>> >> OAuth mailing list >>>>>> >> OAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >=20 >>>>>> > _______________________________________________ >>>>>> > OAuth mailing list >>>>>> > OAuth@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> =E2=80=94 Roland >>>>>>=20 >>>>>> =E2=80=9DEverybody should be quiet near a little stream and listen." >>>>>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-AE91CD48-2353-4DB4-93A9-DE0E830CF58E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Polite comment, Google in general is p= retty "open" about session management in general - long idle timeout and no a= pparent absolute timeout. For a bank or other organization that produces hig= h risk software, this is not standard practice. Re-authentication is a criti= cal security boundary, not prompting the user for re-authentication credenti= als is unacceptable in those environments.

I may be jumping in out of conte= xt, but fair?

--
Jim Manico
@Manicode
<= div>+1 (808) 652-3805

On Feb 15, 2016, at 3:36 PM, Willi= am Denniss <wdenniss@google.com> wrote:


https://accounts.google.= com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdevelopers.google.com%2Foauth= playground&response_type=3Dcode&client_id=3D407408718192.apps.google= usercontent.com&scope=3Dopenid+profile&approval_prompt=3Dforce&a= ccess_type=3Doffline&max_age=3D1

The reason w= e do this is to be explicit about how we are processing the "max_age" reauth= request, specifically that we don't always prompt the user to reauthenticat= e directly (but do perform in-session risk analysis).

I can see us potentially using the more generic amr values like "user", a= nd "mfa" but we will probably avoid very specific ones like "sms" or "otp" t= o avoid brittle relationships with RPs. That said, I don't object to those b= eing in the registry, perhaps there is value in some tightly coupled enterpr= ise configurations.


On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.

I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be reviewed= at the same time. 


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns. 

 =E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com> An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

T= he context that most people on this thread probably don=E2=80=99t= have is that an IANA registry can only be established by an RFC.  Non-RFC specifications,= such as OpenID specifications, can *register* values in a registry, but they cannot *establish* a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would have.=

&= nbsp;

I= nstead, RFCs need to be created to establish registries =E2=80=93 eve= n for values first defined in non-RFC specifications.  This= specification is one example of doing this.

&= nbsp;

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.o= rg

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can=E2=80=99= t ask them to all move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we will= need to deal with registering claims.  

 

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 

This document defines the claim for JWT in general.  We still hav= e almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lod= derstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I believ= e that it=E2=80=99s now ready f= or working group adoption.
>>
>>   &n= bsp;            =             &nbs= p;            &n= bsp;            =      -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org]= On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/ms= g15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/ms= g15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> ____________________________= ___________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.or= g/mailman/listinfo/oauth
>
> ____________________________= ___________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be= quiet near a little stream and listen."
>=46rom =E2=80=99Open Hou= se for Butterflies=E2=80=99 by Ruth= Krauss


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

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

 

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


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




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


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-AE91CD48-2353-4DB4-93A9-DE0E830CF58E-- From nobody Mon Feb 15 15:50:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EEF1AC423 for ; Mon, 15 Feb 2016 15:50:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMbr0ExbjzIE for ; Mon, 15 Feb 2016 15:50:43 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 791871B2A24 for ; Mon, 15 Feb 2016 15:50:43 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id y89so121879750qge.2 for ; Mon, 15 Feb 2016 15:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IlKJnlh5VE1L0CPyYCb3fK5SrEJnnQ468BooldoT58c=; b=ibgrjfYhlcAuRq1EMdlg3at7aP77+qjExt43IL8K+ImdaNRMYUssHI07jX0qCxHBc0 10oGbkGoeX7PIV0Ax7iIo5AQAiIuYIzjZkS6zp76lmgJGaflZ7JkNyyGWoBUnJFqQj7B wxLFtXURmjXD9+kjS5UfELILki987MfJNCZYaWJSpwpi8wPmWd47s03iGLqZJzyFjEVO ykcMOegNcj23+O/fpd18nUupWq8Qqu4j61njGdDPmYbs9IgBpgf1B+r+w8Q6UGf2JQtC EXVhM/LFTVpDy7hxaV5U43MgdqT5jZ0lpZcvDbR6P24bg8NdiZMxaiFroLpJBwibrmRN e+Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IlKJnlh5VE1L0CPyYCb3fK5SrEJnnQ468BooldoT58c=; b=Rl0uCVattJVsxiYNv/3+rGOzxzu/zdj1LnpbRRkrv90tOOYFzSf2XbB3FJGOgKw+S9 WCQ3f0Ktf8yO8a0AXC9kcCwFsUP2Fmmq/3U6SK0ZktlvQ/6pODi9PFzf3z7oQU/JVstP 06hpT+OyTlIUp1a7hMHnDoFmpusSiheze7aDnSAGAAqQ4kzE3LeLFX4x7mz2WfYhpPv0 VaDd0SJHVJJm+ICzUAZts2xfQBviimHg9XaSzav5EkM1sAGtzZfkV8QqOC+SE5YO6aks dn7XxoTUQFd2oIQtFvhj+GYie1bBdYiQjciZtNygUZOOEpF+sBY+23dI6z0Wmyoa5JW1 PPrg== X-Gm-Message-State: AG10YOQ9IhnSFyCTYpGI+uLXBRpEM1tDIJSOo5uAVSKLkTX6Fwnqh+VwhARWVAFZ04JBAA== X-Received: by 10.140.216.212 with SMTP id m203mr25192035qhb.37.1455580242508; Mon, 15 Feb 2016 15:50:42 -0800 (PST) Received: from [192.168.8.100] ([181.202.151.161]) by smtp.gmail.com with ESMTPSA id e34sm12044614qga.4.2016.02.15.15.50.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Feb 2016 15:50:41 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> Date: Mon, 15 Feb 2016 20:50:38 -0300 Message-Id: References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> To: Jim Manico X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:50:50 -0000 --Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39 Content-Type: multipart/alternative; boundary="Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0" --Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The question is what counts as re-authentication. =20 It may be that the environment is changing. Re-prompting for a password = in many cased just tells you the user has a form filler. It may be better to use risk based factors such as prompting for a pin, = or using a local passive biometric, eg has the phone got screen lock and = is it in proximity to the persons smart watch etc. =20 What google seems to be doing is using the amr to say how they did the = last authentication and leave it up to the client to decide if it is = good enough. Simple always ask for a password may no longer provide the security that = most people think it is giving. Looking at what enterprise customers are asking for, they are becoming = more concerned with checking the MDM posture of the device at = authentication. This is a larger conversation about authentication context and methods. The establishment of the amr registry will provide a place to document a = part of this, however authentication context (there is already a = registry) and amr values themselves are probably out of scope for this = WG. John B. > On Feb 15, 2016, at 8:22 PM, Jim Manico wrote: >=20 > Polite comment, Google in general is pretty "open" about session = management in general - long idle timeout and no apparent absolute = timeout. For a bank or other organization that produces high risk = software, this is not standard practice. Re-authentication is a critical = security boundary, not prompting the user for re-authentication = credentials is unacceptable in those environments. >=20 > I may be jumping in out of context, but fair? >=20 > -- > Jim Manico > @Manicode > +1 (808) 652-3805 >=20 > On Feb 15, 2016, at 3:36 PM, William Denniss > wrote: >=20 >> We return 'amr' claims in ID Tokens if "max_age" is requested (per = OpenID Connect), e.g.: >>=20 >> = https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdev= elopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D4074= 08718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt= =3Dforce&access_type=3Doffline&max_age=3D1 = >>=20 >> The reason we do this is to be explicit about how we are processing = the "max_age" reauth request, specifically that we don't always prompt = the user to reauthenticate directly (but do perform in-session risk = analysis). >>=20 >> I can see us potentially using the more generic amr values like = "user", and "mfa" but we will probably avoid very specific ones like = "sms" or "otp" to avoid brittle relationships with RPs. That said, I = don't object to those being in the registry, perhaps there is value in = some tightly coupled enterprise configurations. >>=20 >>=20 >> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt = > wrote: >> Hi Denniss, >>=20 >> out of curiosity: Does Google use amr values?=20 >>=20 >> best regards, >> Torsten. >>=20 >>=20 >> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>=20 >>>=20 >>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones = > = wrote: >>> It's an acceptable fallback option if the working group decides it = doesn't want to register the values that are already in production use = at the time we establish the registry. But add William points out, = Google is already using some of these values. Microsoft is using some of = them. The OpenID MODRNA specs are using some of them. So it seems more = efficient to register them at the same time. >>>=20 >>> That would be my preference. >>>=20 >>> +1, it is also my preference to register the current values. >>>=20 >>> I don't see any harm in the spec that establishes the registry also = seeding it with all known values in use at the time of drafting, = regardless of the group that originally specified them. Makes the = original spec more useful, and avoids the need to submit each value for = consideration separately =E2=80=93 they can be all be reviewed at the = same time.=20 >>>=20 >>>=20 >>> From: Justin Richer >>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>> To: Phil Hunt >>>=20 >>> Cc: >>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call = for Adoption Finalized >>>=20 >>> Can we just do that, then? Seems to be the easiest way to address = various needs and concerns.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) > wrote: >>>>=20 >>>> Yes >>>>=20 >>>> Phil >>>>=20 >>>> On Feb 13, 2016, at 07:59, " = torsten@lodderstedt.net = " > wrote: >>>>=20 >>>>> So basically, the RFC could also just establish the new registry = and oidf could feel in the values? >>>>>=20 >>>>> (just trying to understand) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------- Originalnachricht -------- >>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>> Von: Mike Jones < = Michael.Jones@microsoft.com = > >>>>> An: torsten@lodderstedt.net ,John = Bradley < ve7jtb@ve7jtb.com = > >>>>> Cc: oauth@ietf.org >>>>>=20 >>>>> The context that most people on this thread probably don=E2=80=99t = have is that an IANA registry can only be established by an RFC. = Non-RFC specifications, such as OpenID specifications, can *register* = values in a registry, but they cannot *establish* a registry. The = OpenID Foundation inquired about this with the IETF before OpenID = Connect was finalized and learned that its specifications could not = establish IANA registries. Otherwise, they would have. >>>>>=20 >>>>> =20 >>>>> Instead, RFCs need to be created to establish registries =E2=80=93 = even for values first defined in non-RFC specifications. This = specification is one example of doing this. >>>>>=20 >>>>> =20 >>>>> -- Mike >>>>>=20 >>>>> =C2=A0 <> >>>>> From: OAuth [ = mailto:oauth-bounces@ietf.org = ] On Behalf Of = torsten@lodderstedt.net = >>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>> To: John Bradley < ve7jtb@ve7jtb.com = > >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>>=20 >>>>> =20 >>>>> We clearly have this problem between oauth and oidc. Just take a = look at the discovery thread. >>>>>=20 >>>>> According to you argument I see two options: >>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg = just publishes the registry entries. In this case, the spec should = clearly explain this. >>>>> (2) amr is of any use in oauth (although it has been invented in = oidc) - than define it and motivate it's use in oauth in this spec. >>>>>=20 >>>>> Right now, I think it creates the impression oauth is for = authentication. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------- Originalnachricht -------- >>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>> Von: John Bradley < ve7jtb@ve7jtb.com = > >>>>> An: torsten@lodderstedt.net >>>>> Cc: roland.hedberg@umu.se,oauth@ietf.org = >>>>>=20 >>>>> This is not a issue between oauth and OIDC. >>>>>=20 >>>>> =20 >>>>> This has to do with the registry for JWT being in OAuth. Many = protocols that use JWT are going to want to register claims. =20 >>>>>=20 >>>>> We can=E2=80=99t ask them to all move the parts of there specs = that use JWT to OAuth. >>>>>=20 >>>>> =20 >>>>> Perhaps JWT should have been part of JOSE, but that is water under = the bridge. =20 >>>>>=20 >>>>> =20 >>>>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and = we will need to deal with registering claims. =20 >>>>>=20 >>>>> =20 >>>>> I guess that we can tell people that they need to publish the = specs defining the claims someplace else, and just do the registry part. >>>>>=20 >>>>> However doing that will probably not improve interoperability and = understanding. >>>>>=20 >>>>> =20 >>>>> This document defines the claim for JWT in general. We still have = almost no documentation in the WG about what a JWT access token would = contain other than the POP work. >>>>>=20 >>>>> =20 >>>>> John B. >>>>>=20 >>>>> On Feb 13, 2016, at 9:18 AM, = torsten@lodderstedt.net = wrote: >>>>>=20 >>>>> =20 >>>>> I basically support adoption of this document. Asserting = authentication methods in access tokens (in this case in JWTS format) is = reasonable. We use it to pass information about the authentication = performed prior issuing an access token to the _resource_ server. >>>>>=20 >>>>> What worries me is the back and forth between oauth and oidc. The = amr claim is defined in oidc (which sits on top of oauth) but the oauth = wg specifies the registry? Moreover, the current text does not give a = rationale for using amr in context of oauth. >>>>>=20 >>>>> As a WG we need to find a clear delineation between both = protocols, otherwise noone will really understand the difference and = when to use what. We create confusion! >>>>>=20 >>>>> For this particular draft this means to either move amr to oauth = or the registry to oidc. >>>>>=20 >>>>> best regards,=20 >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -------- Urspr=C3=BCngliche Nachricht -------- >>>>> Von: Roland Hedberg < = roland.hedberg@umu.se = > >>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>> An: oauth@ietf.org >>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>>=20 >>>>> +1 >>>>>=20 >>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley < = ve7jtb@ve7jtb.com >: >>>>> >=20 >>>>> > +1 to adopt this draft. >>>>> >=20 >>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones < = Michael.Jones@microsoft.com = > wrote: >>>>> >>=20 >>>>> >> Draft -05 incorporates the feedback described below - deleting = the request parameter, noting that this spec isn't an encouragement to = use OAuth 2.0 for authentication without employing appropriate = extensions, and no longer requiring a specification for IANA = registration. I believe that it=E2=80=99s now ready for working group = adoption. >>>>> >>=20 >>>>> >> -- = Mike >>>>> >>=20 >>>>> >> -----Original Message----- >>>>> >> From: OAuth [ = mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >>>>> >> Sent: Thursday, February 4, 2016 11:23 AM >>>>> >> To: oauth@ietf.org = >>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: = Call for Adoption Finalized >>>>> >>=20 >>>>> >> Hi all, >>>>> >>=20 >>>>> >> On January 19th I posted a call for adoption of the = Authentication Method Reference Values specification, see = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15402.html = >>>>> >>=20 >>>>> >> What surprised us is that this work is conceptually very = simple: we define new claims and create a registry with new values. Not = a big deal but that's not what the feedback from the Yokohama IETF = meeting and the subsequent call for adoption on the list shows. The = feedback lead to mixed feelings and it is a bit difficult for Derek and = myself to judge consensus. >>>>> >>=20 >>>>> >> Let me tell you what we see from the comments on the list. >>>>> >>=20 >>>>> >> In his review at >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15423.html = James = Manger asks for significant changes. Among other things, he wants to = remove one of the claims. He provides a detailed review and actionable = items. >>>>> >>=20 >>>>> >> William Denniss believes the document is ready for adoption but = agrees with some of the comments from James. Here is his review: >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15426.html = >>>>> >>=20 >>>>> >> Justin is certainly the reviewer with the strongest opinion. = Here is one of his posts: >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15457.html = >>>>> >>=20 >>>>> >> Among all concerns Justin expressed the following one is = actually actionable IMHO: Justin is worried that reporting how a person = authenticated to an authorization endpoint and encouraging people to use = OAuth for authentication is a fine line. He believes that this document = leads readers to believe the latter. >>>>> >>=20 >>>>> >> John agrees with Justin in >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15448.html = that = we need to make sure that people are not mislead about the intention of = the document. John also provides additional comments in this post to the >>>>> >> list: = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15441.html = >>>>> >> Most of them require more than just editing work. For example, = methods listed are really not useful, >>>>> >>=20 >>>>> >> Phil agrees with the document adoption but has some remarks = about the registry although he does not propose specific text. His = review is here: >>>>> >> = http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15462.html = >>>>> >>=20 >>>>> >> With my co-chair hat on: I just wanted to clarify that = registering claims (and values within those claims) is within the scope = of the OAuth working group. We standardized the JWT in this group and we = are also chartered to standardize claims, as we are currently doing with = various drafts. Not standardizing JWT in the IETF would have lead to = reduced interoperability and less security. I have no doubts that was a = wrong decision. >>>>> >>=20 >>>>> >> In its current form, there is not enough support to have this = document as a WG item. >>>>> >>=20 >>>>> >> We believe that the document authors should address some of the = easier comments and submit a new version. This would allow us to reach = out to those who had expressed concerns about the scope of the document = to re-evaluate their decision. A new draft version should at least = address the following issues: >>>>> >>=20 >>>>> >> * Clarify that this document is not an encouragement for using = OAuth as an authentication protocol. I believe that this would address = some of the concerns raised by Justin and John. >>>>> >>=20 >>>>> >> * Change the registry policy, which would address one of the = comments from James, William, and Phil. >>>>> >>=20 >>>>> >> Various other items require discussion since they are more = difficult to address. For example, John noted that he does not like the = use of request parameters. Unfortunately, no alternative is offered. I = urge John to provide an alternative proposal, if there is one. Also, the = remark that the values are meaningless could be countered with an = alternative proposal. James wanted to remove the "amr_values" parameter. >>>>> >> Is this what others want as well? >>>>> >>=20 >>>>> >> After these items have been addressed we believe that more = folks in the group will support the document. >>>>> >>=20 >>>>> >> Ciao >>>>> >> Hannes & Derek >>>>> >>=20 >>>>> >>=20 >>>>> >>=20 >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> = https://www.ietf.org/mailman/= listinfo/oauth >>>>> >=20 >>>>> > _______________________________________________ >>>>> > OAuth mailing list >>>>> > OAuth@ietf.org >>>>> > = https://www.ietf.org/mailman/= listinfo/oauth >>>>>=20 >>>>> =E2=80=94 Roland >>>>>=20 >>>>> =E2=80=9DEverybody should be quiet near a little stream and = listen." >>>>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth = Krauss >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://www.ietf.org/mailman/= listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://www.ietf.org/mailman/= listinfo/oauth >>>>> =20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The question is what counts as re-authentication.  

It may be that the = environment is changing.  Re-prompting for a password in many cased = just tells you the user has a form filler.

It may be better to use risk based = factors such as prompting for a pin, or using a local passive biometric, = eg has the phone got screen lock and is it in proximity to the persons = smart watch etc.   

What google seems to be doing is using = the amr to say how they did the last authentication and leave it up to = the client to decide if it is good enough.

Simple always ask for a password may no = longer provide the security that most people think it is = giving.

Looking = at what enterprise customers are asking for, they are becoming more = concerned with checking the MDM posture of the device at = authentication.

This is a larger conversation about authentication context = and methods.

The= establishment of the amr registry will provide a place to document a = part of this, however authentication context (there is already a = registry) and amr values themselves are probably out of scope for this = WG.

John = B.


On = Feb 15, 2016, at 8:22 PM, Jim Manico <jim@manicode.com> = wrote:

Polite comment, = Google in general is pretty "open" about session management in general - = long idle timeout and no apparent absolute timeout. For a bank or other = organization that produces high risk software, this is not standard = practice. Re-authentication is a critical security boundary, not = prompting the user for re-authentication credentials is unacceptable in = those environments.

I may be jumping in out of context, but fair?
--
Jim Manico
@Manicode
+1 (808) = 652-3805

On Feb 15, 2016, at = 3:36 PM, William Denniss <wdenniss@google.com> wrote:

We return 'amr' claims in ID = Tokens if "max_age" is requested (per OpenID Connect), e.g.:

https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%= 3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_type=3Dcode&a= mp;client_id=3D407408718192.apps.googleusercontent.com&scope=3Dopenid+= profile&approval_prompt=3Dforce&access_type=3Doffline&max_age=3D= 1

The reason we do this is to be explicit about how we are = processing the "max_age" reauth request, specifically that we don't = always prompt the user to reauthenticate directly (but do perform = in-session risk analysis).

I can see us potentially using the more generic amr values = like "user", and "mfa" but we will probably avoid very specific ones = like "sms" or "otp" to avoid brittle relationships with RPs. That said, = I don't object to those being in the registry, perhaps there is value in = some tightly coupled enterprise configurations.


On Sun, Feb 14, 2016 at 5:30 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the = current values.

I don't see any harm in the spec that = establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be = reviewed at the same time. 


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to = be the easiest way to address various needs and concerns. 

 =E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht = --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread probably don=E2=80=99= t have is that an IANA registry can only be established by an RFC.  Non-RFC = specifications, such as OpenID specifications, can *register*= values in a registry, but they cannot *establish* = a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA = registries.  Otherwise, they would = have.

 

Instead, RFCs need to be created to establish registries =E2=80=93 = even for values first defined in non-RFC specifications.  = This specification is one example of doing this.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of = torsten@lodderstedt.net
Sent: = Saturday, February 13, 2016 6:37 AM
To: John = Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized

 

We clearly have = this problem between oauth and oidc. Just take a look at the discovery thread.

According= to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I = think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.org

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can=E2=80=99t ask them to all move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we = will need to deal with registering claims.  

 

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 

This document defines the claim for JWT in general.  We still = have almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of = oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCnglich= e Nachricht --------
Von: Roland Hedberg = <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I = believe that it=E2=80=99s now = ready for working group = adoption.
>>
= >>           =             &n= bsp;           &nbs= p;            =            -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption = Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/msg15402.htm= l
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.htm= l James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.htm= l
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.htm= l
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.htm= l that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.htm= l
>> Most of them require more than just editing work. For example, methods listed are really not = useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.htm= l
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> = _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody = should be quiet near a little stream and listen."
>=46rom =E2=80=99Open = House for Butterflies=E2=80=99 by = Ruth Krauss


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

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

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


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




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


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

= --Apple-Mail=_16F9E50F-BE7C-4648-8301-42FD8DD148A0-- --Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTUyMzUwMzhaMCMGCSqGSIb3DQEJBDEWBBRQx+tV5njBTnMKHtGdrWEX 4Tep5zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCrdExTbAAOURhOB8K+lHQuOCHNY9oZ9GRDyv+Vw7kZMz1LjIrA2Jnu AaNaPy179D3jLtaQrWTu8WagSsDMf5OkQ0teo/7bgBb2TarnszxdrcVV48pyvdnlbI9VOeOH4gtF T/R8FrLoWbKFS5JzXW7wSxCzatKTzew586rQ6eWgqYfkqXKFo9XfRJiTCDo3H8KnaYPqcQqqvF8n v6FcJNxRjNHU6WGVpfLBd2zd7N35ZVJPi7dD26wOSGgJkjN3kOzmIG1ZRt3bBIDzoxFI4lfvwXKI huSwyWlb7ly0gfiUdiTy48JUwX6vsxLyDZ+GDQ0WRgrwkN0UuEJkQ1iUFl+4AAAAAAAA --Apple-Mail=_768C296A-4CAF-46B7-BF29-DBF772177A39-- From nobody Mon Feb 15 15:59:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D76D1B2AB5 for ; Mon, 15 Feb 2016 15:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr6wPyRIND8m for ; Mon, 15 Feb 2016 15:59:37 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D9A1B2ABA for ; Mon, 15 Feb 2016 15:59:37 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s68so61142981qkh.3 for ; Mon, 15 Feb 2016 15:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=gCku1JB03/eEl6dudRdITdCdtwhdPARqWbyoMfXXtkA=; b=AJNopBuk+wbKfeD7j8DlAg6FpeJga2ahbUyiY14mdP+qtGufOgYRl12I+U/zwwEye6 1JNAL9VbEGsOgFztIKdpjNR5emMICggca5TGHslaQp07vSjty9U/nqQNcA09CrhwNArP Fs+lvHq7HdP/lqMrZamVaE4e4vj2rduYrMEQbpemHwRxA3tl4nM3gnzZqF4kRbmciSk6 +OImgyeR3l8QwLo0YqsP2/aIsvcD4FPbGBQe6xbsl2VH0eNRQtZEbbQ1j+dmraTJWt+e n2TlkLhMHkH2YGbkbdz0WbD7HL12CtSeuFZHfDxJ6X4MEdt05v2uSNPfYy9B8QamBjqR SZ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=gCku1JB03/eEl6dudRdITdCdtwhdPARqWbyoMfXXtkA=; b=PctjV8Q2rO8wHoVb16WFqjDWNYUa5wXYiBgp/LfVTSaDdH5bw/vZGYoX4zsyjJZZ9S koVNKn6mTszqlJfr62V6BLg6CSH7cle0l1n/4thr2W+qZbqMblgIZjt8S3MX1nydchN+ G4gCSP1GQEcTQ+iAF066p2vSb0p01vF6ZP1sMLf8SIfMOn60xGZc9gVSU0SzPnpPnKs+ RKamqBV8MFo8b1WMjAYalqzY8EurMQ4k630PNrQUU4IOJG9QyFZ86fc4wnuwiK1jL22J b6bOqWF2p95YHFFBIiW2EpWCyoxqxWtClUXU0NJ1+2Mb5yENNyQV3ZjXAv/gM7Yupoyc CH7A== X-Gm-Message-State: AG10YOQIUOQ/GLLsi9gWuaZ8Jv8JvX1Rqh73fiQ0hc+yaUSosPRqMM26Hnogvl25gKdklrwX4WRQLMTpAviBIA== X-Received: by 10.55.71.66 with SMTP id u63mr23558581qka.67.1455580776333; Mon, 15 Feb 2016 15:59:36 -0800 (PST) MIME-Version: 1.0 References: <20160212094043.13011.44662.idtracker@ietfa.amsl.com> In-Reply-To: <20160212094043.13011.44662.idtracker@ietfa.amsl.com> From: Nat Sakimura Date: Mon, 15 Feb 2016 23:59:26 +0000 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a114a79741d89a9052bd7cf85 Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 23:59:39 -0000 --001a114a79741d89a9052bd7cf85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It now shows how to return multiple endpoints in web linking. Also, added Resource Endpoint response header. Best, nat ---------- Forwarded message --------- From: Date: 2016=E5=B9=B42=E6=9C=8812=E6=97=A5(=E9=87=91) 18:40 Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt To: Nov Matake , Nat Sakimura , Sascha Preibisch , Sascha Preibisch < sascha.preibisch@gmail.com> A new version of I-D, draft-sakimura-oauth-meta-07.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-sakimura-oauth-meta Revision: 07 Title: OAuth Response Metadata Document date: 2016-02-12 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/ Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-meta-07 Abstract: This specification defines an extensible metadata that may be inserted into the OAuth 2.0 responses to assist the clients to process those responses. It is expressed either as a link header, or query parameters. It will allow the client to learn where the members in the response could be used, what is the characteristics of the payload is, how it should be processed, and so on. Since they are just additional response header/query parameters, any client that does not understand this extension should not break and work normally while supporting clients can utilize the metadata to take the advantage of the extension. 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 --001a114a79741d89a9052bd7cf85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It now shows how to return multiple endpoints in web linki= ng.=C2=A0
Also, added Resource Endpoint response header.=C2=A0

Best,=C2=A0

nat

---------- Forwarded message -------= --
From: <internet-draft= s@ietf.org>
Date: 2016=E5=B9=B42=E6=9C=8812=E6=97=A5(=E9=87=91) 1= 8:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.= txt
To: Nov Matake <nov@matake.jp>, Nat Sakimura <sakimura@gmai= l.com>, Sascha Preibisch <Sascha.Preibisch@gmail.com>, Sascha Preibisch <sascha.preibisch@gmail.com>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sakimura-oauth-meta
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A007
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth Response Metadata
Document date:=C2=A0 2016-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-sakimura-oauth-me= ta-07.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-sakimura-oauth-meta-07
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-meta-0= 7

Abstract:
=C2=A0 =C2=A0This specification defines an extensible metadata that may be<= br> =C2=A0 =C2=A0inserted into the OAuth 2.0 responses to assist the clients to=
=C2=A0 =C2=A0process those responses.=C2=A0 It is expressed either as a lin= k header, or
=C2=A0 =C2=A0query parameters.=C2=A0 It will allow the client to learn wher= e the
=C2=A0 =C2=A0members in the response could be used, what is the characteris= tics of
=C2=A0 =C2=A0the payload is, how it should be processed, and so on.=C2=A0 S= ince they
=C2=A0 =C2=A0are just additional response header/query parameters, any clie= nt that
=C2=A0 =C2=A0does not understand this extension should not break and work n= ormally
=C2=A0 =C2=A0while supporting clients can utilize the metadata to take the<= br> =C2=A0 =C2=A0advantage of the extension.




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

--001a114a79741d89a9052bd7cf85-- From nobody Mon Feb 15 16:34:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE3B1B2B4F for ; Mon, 15 Feb 2016 16:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br8SOAS5CP13 for ; Mon, 15 Feb 2016 16:34:39 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D6A1B2B68 for ; Mon, 15 Feb 2016 16:34:38 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1G0YW6F013088 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Feb 2016 00:34:32 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1G0YVT2003243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2016 00:34:32 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1G0YQia018099; Tue, 16 Feb 2016 00:34:31 GMT Received: from [25.169.20.206] (/24.114.26.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Feb 2016 16:34:23 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-BB77AED4-A85D-47E1-8AC4-5A089CCA01D9 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> Date: Mon, 15 Feb 2016 17:34:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: <138A2A47-E970-428F-8994-BAEB0BEA3894@oracle.com> References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> To: Jim Manico X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 00:34:45 -0000 --Apple-Mail-BB77AED4-A85D-47E1-8AC4-5A089CCA01D9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In older systems, time based logout is all you have if you aren't assessing r= isk.=20 I would think over time will quickly diminish in its importance (or as best p= ractice) - at least as the single method for determine a session should end o= ther than explicit logout.=20 Phil > On Feb 15, 2016, at 16:22, Jim Manico wrote: >=20 > Polite comment, Google in general is pretty "open" about session managemen= t in general - long idle timeout and no apparent absolute timeout. For a ban= k or other organization that produces high risk software, this is not standa= rd practice. Re-authentication is a critical security boundary, not promptin= g the user for re-authentication credentials is unacceptable in those enviro= nments. >=20 > I may be jumping in out of context, but fair? >=20 > -- > Jim Manico > @Manicode > +1 (808) 652-3805 >=20 >> On Feb 15, 2016, at 3:36 PM, William Denniss wrote:= >>=20 >> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID= Connect), e.g.: >>=20 >> https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fde= velopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D40740= 8718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt=3D= force&access_type=3Doffline&max_age=3D1 >>=20 >> The reason we do this is to be explicit about how we are processing the "= max_age" reauth request, specifically that we don't always prompt the user t= o reauthenticate directly (but do perform in-session risk analysis). >>=20 >> I can see us potentially using the more generic amr values like "user", a= nd "mfa" but we will probably avoid very specific ones like "sms" or "otp" t= o avoid brittle relationships with RPs. That said, I don't object to those b= eing in the registry, perhaps there is value in some tightly coupled enterpr= ise configurations. >>=20 >>=20 >>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt wrote: >>> Hi Denniss, >>>=20 >>> out of curiosity: Does Google use amr values?=20 >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>=20 >>>> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>>=20 >>>>=20 >>>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones wrote: >>>>> It's an acceptable fallback option if the working group decides it doe= sn't want to register the values that are already in production use at the t= ime we establish the registry. But add William points out, Google is already= using some of these values. Microsoft is using some of them. The OpenID MOD= RNA specs are using some of them. So it seems more efficient to register the= m at the same time. >>>>>=20 >>>>> That would be my preference. >>>>=20 >>>> +1, it is also my preference to register the current values. >>>>=20 >>>> I don't see any harm in the spec that establishes the registry also see= ding it with all known values in use at the time of drafting, regardless of t= he group that originally specified them. Makes the original spec more useful= , and avoids the need to submit each value for consideration separately =E2=80= =93 they can be all be reviewed at the same time.=20 >>>>=20 >>>>=20 >>>>> From: Justin Richer >>>>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>>>> To: Phil Hunt >>>>>=20 >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>=20 >>>>> Can we just do that, then? Seems to be the easiest way to address vari= ous needs and concerns.=20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) w= rote: >>>>>>=20 >>>>>> Yes >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" wrote: >>>>>>=20 >>>>>>> So basically, the RFC could also just establish the new registry and= oidf could feel in the values? >>>>>>>=20 >>>>>>> (just trying to understand) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------- Originalnachricht -------- >>>>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized >>>>>>> Von: Mike Jones >>>>>>> An: torsten@lodderstedt.net,John Bradley >>>>>>> Cc: oauth@ietf.org >>>>>>>=20 >>>>>>> The context that most people on this thread probably don=E2=80=99t h= ave is that an IANA registry can only be established by an RFC. Non-RFC spe= cifications, such as OpenID specifications, can *register* values in a regis= try, but they cannot *establish* a registry. The OpenID Foundation inquired= about this with the IETF before OpenID Connect was finalized and learned th= at its specifications could not establish IANA registries. Otherwise, they w= ould have. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Instead, RFCs need to be created to establish registries =E2=80=93 e= ven for values first defined in non-RFC specifications. This specification i= s one example of doing this. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lod= derstedt.net >>>>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>>>> To: John Bradley >>>>>>> Cc: oauth@ietf.org >>>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> We clearly have this problem between oauth and oidc. Just take a loo= k at the discovery thread. >>>>>>>=20 >>>>>>> According to you argument I see two options: >>>>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg j= ust publishes the registry entries. In this case, the spec should clearly ex= plain this. >>>>>>> (2) amr is of any use in oauth (although it has been invented in oid= c) - than define it and motivate it's use in oauth in this spec. >>>>>>>=20 >>>>>>> Right now, I think it creates the impression oauth is for authentica= tion. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------- Originalnachricht -------- >>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized >>>>>>> Von: John Bradley >>>>>>> An: torsten@lodderstedt.net >>>>>>> Cc: roland.hedberg@umu.se,oauth@ietf.org >>>>>>>=20 >>>>>>> This is not a issue between oauth and OIDC. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> This has to do with the registry for JWT being in OAuth. Many prot= ocols that use JWT are going to want to register claims. =20 >>>>>>>=20 >>>>>>> We can=E2=80=99t ask them to all move the parts of there specs that u= se JWT to OAuth. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Perhaps JWT should have been part of JOSE, but that is water under t= he bridge. =20 >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and w= e will need to deal with registering claims. =20 >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> I guess that we can tell people that they need to publish the specs d= efining the claims someplace else, and just do the registry part. >>>>>>>=20 >>>>>>> However doing that will probably not improve interoperability and un= derstanding. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> This document defines the claim for JWT in general. We still have a= lmost no documentation in the WG about what a JWT access token would contain= other than the POP work. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> I basically support adoption of this document. Asserting authenticat= ion methods in access tokens (in this case in JWTS format) is reasonable. We= use it to pass information about the authentication performed prior issuing= an access token to the _resource_ server. >>>>>>>=20 >>>>>>> What worries me is the back and forth between oauth and oidc. The am= r claim is defined in oidc (which sits on top of oauth) but the oauth wg spe= cifies the registry? Moreover, the current text does not give a rationale fo= r using amr in context of oauth. >>>>>>>=20 >>>>>>> As a WG we need to find a clear delineation between both protocols, o= therwise noone will really understand the difference and when to use what. W= e create confusion! >>>>>>>=20 >>>>>>> For this particular draft this means to either move amr to oauth or t= he registry to oidc. >>>>>>>=20 >>>>>>> best regards,=20 >>>>>>> Torsten. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------- Urspr=C3=BCngliche Nachricht -------- >>>>>>> Von: Roland Hedberg >>>>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>>>> An: oauth@ietf.org >>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized >>>>>>>=20 >>>>>>> +1 >>>>>>>=20 >>>>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley : >>>>>>> >=20 >>>>>>> > +1 to adopt this draft. >>>>>>> >=20 >>>>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones wrote: >>>>>>> >>=20 >>>>>>> >> Draft -05 incorporates the feedback described below - deleting th= e request parameter, noting that this spec isn't an encouragement to use OAu= th 2.0 for authentication without employing appropriate extensions, and no l= onger requiring a specification for IANA registration. I believe that it=E2= =80=99s now ready for working group adoption. >>>>>>> >>=20 >>>>>>> >> = -- Mike >>>>>>> >>=20 >>>>>>> >> -----Original Message----- >>>>>>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes T= schofenig >>>>>>> >> Sent: Thursday, February 4, 2016 11:23 = AM >>>>>>> >> To: oauth@ietf.org >>>>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>>> >>=20 >>>>>>> >> Hi all, >>>>>>> >>=20 >>>>>>> >> On January 19th I posted a call for adoption of the Authenticatio= n Method Reference Values specification, see http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15402.html >>>>>>> >>=20 >>>>>>> >> What surprised us is that this work is conceptually very simple: w= e define new claims and create a registry with new values. Not a big deal bu= t that's not what the feedback from the Yokohama IETF meeting and the subseq= uent call for adoption on the list shows. The feedback lead to mixed feeling= s and it is a bit difficult for Derek and myself to = judge consensus. >>>>>>> >>=20 >>>>>>> >> Let me tell you what we see from the comments on the list. >>>>>>> >>=20 >>>>>>> >> In his review at >>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html J= ames Manger asks for signifi= cant changes. Among other things, he = wants to remove one of = the claims. He provides a= detailed review and actionable items. >>>>>>> >>=20 >>>>>>> >> William Denniss believes the document is ready for adoption but a= grees with some of the comments from James. Here is his review: >>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>>>>>> >>=20 >>>>>>> >> Justin is certainly the reviewer with the strongest opinion. Here= is one of his posts: >>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>>>>>> >>=20 >>>>>>> >> Among all concerns Justin expressed the following one is actually= actionable IMHO: Justin is worried that reporting how a person authenticate= d to an authorization endpoint and encouraging people to use OAuth for authe= ntication is a fine line. He believes that this document leads readers to be= lieve the latter. >>>>>>> >>=20 >>>>>>> >> John agrees with Justin in >>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html t= hat we need to make sure that people are not mislead about the intention of t= he document. John also provides additional comments in this post to the >>>>>>> >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441= .html >>>>>>> >> Most of them require more than just editing work. For example, me= thods listed are really not useful, >>>>>>> >>=20 >>>>>>> >> Phil agrees with the document adoption but has some remarks about= the registry although he does not propose specific text. His review is here= : >>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>>>>>> >>=20 >>>>>>> >> With my co-chair hat on: I just wanted to clarify that registerin= g claims (and values within those claims) is within the scope of the OAuth w= orking group. We standardized the JWT in this group and we are also chartere= d to standardize claims, as we are currently doing with various drafts. Not s= tandardizing JWT in the IETF would have lead to reduced interoperability and= less security. I have no doubts that was a wrong decision. >>>>>>> >>=20 >>>>>>> >> In its current form, there is not enough support to have this doc= ument as a WG item. >>>>>>> >>=20 >>>>>>> >> We believe that the document authors should address some of the e= asier comments and submit a new version. This would allow us to reach out to= those who had expressed concerns about the scope of the document to re-eval= uate their decision. A new draft version should at least address the followi= ng issues: >>>>>>> >>=20 >>>>>>> >> * Clarify that this document is not an encouragement for using OA= uth as an authentication protocol. I believe that this would address some of= the concerns raised by Justin and John. >>>>>>> >>=20 >>>>>>> >> * Change the registry policy, which would address one of the comm= ents from James, William, and Phil. >>>>>>> >>=20 >>>>>>> >> Various other items require discussion since they are more diffic= ult to address. For example, John noted that he does not like the use of req= uest parameters. Unfortunately, no alternative is offered. I urge John to pr= ovide an alternative proposal, = if there is one. Also, the remark that the values are meaningless could b= e countered with an alternative proposal. James wanted to remove the "amr_va= lues" parameter. >>>>>>> >> Is this what others want as well? >>>>>>> >>=20 >>>>>>> >> After these items have been addressed we believe that more folks i= n the group will support the document. >>>>>>> >>=20 >>>>>>> >> Ciao >>>>>>> >> Hannes & Derek >>>>>>> >>=20 >>>>>>> >>=20 >>>>>>> >>=20 >>>>>>> >> _______________________________________________ >>>>>>> >> OAuth mailing list >>>>>>> >> OAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >=20 >>>>>>> > _______________________________________________ >>>>>>> > OAuth mailing list >>>>>>> > OAuth@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> =E2=80=94 Roland >>>>>>>=20 >>>>>>> =E2=80=9DEverybody should be quiet near a little stream and listen."= >>>>>>> >=46rom =E2=80=99Open House for = Butterflies=E2=80=99 by Ruth Krauss >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-BB77AED4-A85D-47E1-8AC4-5A089CCA01D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In older systems, time based logout is= all you have if you aren't assessing risk. 

I would think over time w= ill quickly diminish in its importance (or as best practice) - at least as t= he single method for determine a session should end other than explicit logo= ut. 

Phil

On Feb 1= 5, 2016, at 16:22, Jim Manico <jim@ma= nicode.com> wrote:

Polit= e comment, Google in general is pretty "open" about session management in ge= neral - long idle timeout and no apparent absolute timeout. For a bank or ot= her organization that produces high risk software, this is not standard prac= tice. Re-authentication is a critical security boundary, not prompting the u= ser for re-authentication credentials is unacceptable in those environments.=

I may be jumping in out of context, but fair?

--
Jim= Manico
@Manicode
+1 (808) 652-3805

= On Feb 15, 2016, at 3:36 PM, William Denniss <wdenniss@google.com> wrote:

The reason we do this is to be explicit about how we are p= rocessing the "max_age" reauth request, specifically that we don't always pr= ompt the user to reauthenticate directly (but do perform in-session risk ana= lysis).

I can see us potentially using the more gen= eric amr values like "user", and "mfa" but we will probably avoid very speci= fic ones like "sms" or "otp" to avoid brittle relationships with RPs. That s= aid, I don't object to those being in the registry, perhaps there is value i= n some tightly coupled enterprise configurations.


On Sun, Feb 14, 2016 at 5= :30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wr= ote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.

I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be reviewed= at the same time. 


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns. 

 =E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com> An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

T= he context that most people on this thread probably don=E2=80=99t= have is that an IANA registry can only be established by an RFC.  Non-RFC specifications,= such as OpenID specifications, can *register* values in a registry, but they cannot *establish* a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would have.=

&= nbsp;

I= nstead, RFCs need to be created to establish registries =E2=80=93 eve= n for values first defined in non-RFC specifications.  This= specification is one example of doing this.

&= nbsp;

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.o= rg

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can=E2=80=99= t ask them to all move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we will= need to deal with registering claims.  

 

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 

This document defines the claim for JWT in general.  We still hav= e almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lod= derstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I believ= e that it=E2=80=99s now ready f= or working group adoption.
>>
>>   &n= bsp;            =             &nbs= p;            &n= bsp;            =      -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org]= On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/ms= g15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/ms= g15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> ____________________________= ___________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.or= g/mailman/listinfo/oauth
>
> ____________________________= ___________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be= quiet near a little stream and listen."
>=46rom =E2=80=99Open Hou= se for Butterflies=E2=80=99 by Ruth= Krauss


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

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

 

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


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




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


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
= --Apple-Mail-BB77AED4-A85D-47E1-8AC4-5A089CCA01D9-- From nobody Mon Feb 15 16:35:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E839C1B2B4D for ; Mon, 15 Feb 2016 16:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUrAQMj5sQbo for ; Mon, 15 Feb 2016 16:35:12 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E9A1B2AA2 for ; Mon, 15 Feb 2016 16:35:11 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1G0Z9P2027642 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Feb 2016 00:35:10 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1G0Z9Rr011045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2016 00:35:09 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1G0Z9at025238; Tue, 16 Feb 2016 00:35:09 GMT Received: from [25.169.20.206] (/24.114.26.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Feb 2016 16:35:06 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-78198E4D-E743-469E-8865-62ECCA9FB97D Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Mon, 15 Feb 2016 17:34:59 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> To: John Bradley X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 00:35:18 -0000 --Apple-Mail-78198E4D-E743-469E-8865-62ECCA9FB97D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Feb 15, 2016, at 16:50, John Bradley wrote: >=20 > The question is what counts as re-authentication. =20 >=20 > It may be that the environment is changing. Re-prompting for a password i= n many cased just tells you the user has a form filler. >=20 > It may be better to use risk based factors such as prompting for a pin, or= using a local passive biometric, eg has the phone got screen lock and is it= in proximity to the persons smart watch etc. =20 >=20 > What google seems to be doing is using the amr to say how they did the las= t authentication and leave it up to the client to decide if it is good enoug= h. >=20 > Simple always ask for a password may no longer provide the security that m= ost people think it is giving. >=20 > Looking at what enterprise customers are asking for, they are becoming mor= e concerned with checking the MDM posture of the device at authentication. >=20 > This is a larger conversation about authentication context and methods. >=20 > The establishment of the amr registry will provide a place to document a p= art of this, however authentication context (there is already a registry) an= d amr values themselves are probably out of scope for this WG. >=20 > John B. >=20 >=20 >> On Feb 15, 2016, at 8:22 PM, Jim Manico wrote: >>=20 >> Polite comment, Google in general is pretty "open" about session manageme= nt in general - long idle timeout and no apparent absolute timeout. For a ba= nk or other organization that produces high risk software, this is not stand= ard practice. Re-authentication is a critical security boundary, not prompti= ng the user for re-authentication credentials is unacceptable in those envir= onments. >>=20 >> I may be jumping in out of context, but fair? >>=20 >> -- >> Jim Manico >> @Manicode >> +1 (808) 652-3805 >>=20 >>> On Feb 15, 2016, at 3:36 PM, William Denniss wrote= : >>>=20 >>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenI= D Connect), e.g.: >>>=20 >>> https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fd= evelopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D4074= 08718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt=3D= force&access_type=3Doffline&max_age=3D1 >>>=20 >>> The reason we do this is to be explicit about how we are processing the "= max_age" reauth request, specifically that we don't always prompt the user t= o reauthenticate directly (but do perform in-session risk analysis). >>>=20 >>> I can see us potentially using the more generic amr values like "user", a= nd "mfa" but we will probably avoid very specific ones like "sms" or "otp" t= o avoid brittle relationships with RPs. That said, I don't object to those b= eing in the registry, perhaps there is value in some tightly coupled enterpr= ise configurations. >>>=20 >>>=20 >>>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt wrote: >>>> Hi Denniss, >>>>=20 >>>> out of curiosity: Does Google use amr values?=20 >>>>=20 >>>> best regards, >>>> Torsten. >>>>=20 >>>>=20 >>>>> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>>>=20 >>>>>=20 >>>>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones wrote: >>>>>> It's an acceptable fallback option if the working group decides it do= esn't want to register the values that are already in production use at the t= ime we establish the registry. But add William points out, Google is already= using some of these values. Microsoft is using some of them. The OpenID MOD= RNA specs are using some of them. So it seems more efficient to register the= m at the same time. >>>>>>=20 >>>>>> That would be my preference. >>>>>=20 >>>>> +1, it is also my preference to register the current values. >>>>>=20 >>>>> I don't see any harm in the spec that establishes the registry also se= eding it with all known values in use at the time of drafting, regardless of= the group that originally specified them. Makes the original spec more usef= ul, and avoids the need to submit each value for consideration separately =E2= =80=93 they can be all be reviewed at the same time.=20 >>>>>=20 >>>>>=20 >>>>>> From: Justin Richer >>>>>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>>>>> To: Phil Hunt >>>>>>=20 >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>>=20 >>>>>> Can we just do that, then? Seems to be the easiest way to address var= ious needs and concerns.=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) = wrote: >>>>>>>=20 >>>>>>> Yes >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" wrote: >>>>>>>=20 >>>>>>>> So basically, the RFC could also just establish the new registry an= d oidf could feel in the values? >>>>>>>>=20 >>>>>>>> (just trying to understand) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------- Originalnachricht -------- >>>>>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>> Von: Mike Jones >>>>>>>> An: torsten@lodderstedt.net,John Bradley >>>>>>>> Cc: oauth@ietf.org >>>>>>>>=20 >>>>>>>> The context that most people on this thread probably don=E2=80=99t h= ave is that an IANA registry can only be established by an RFC. Non-RFC spe= cifications, such as OpenID specifications, can *register* values in a regis= try, but they cannot *establish* a registry. The OpenID Foundation inquired= about this with the IETF before OpenID Connect was finalized and learned th= at its specifications could not establish IANA registries. Otherwise, they w= ould have. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Instead, RFCs need to be created to establish registries =E2=80=93 e= ven for values first defined in non-RFC specifications. This specification i= s one example of doing this. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> = -- Mike >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lo= dderstedt.net >>>>>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>>>>> To: John Bradley >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> We clearly have this problem between oauth and oidc. Just take a lo= ok at the discovery thread. >>>>>>>>=20 >>>>>>>> According to you argument I see two options: >>>>>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg j= ust publishes the registry entries. In this case, the spec should clearly ex= plain this. >>>>>>>> (2) amr is of any use in oauth (although it has been invented in oi= dc) - than define it and motivate it's use in oauth in this spec. >>>>>>>>=20 >>>>>>>> Right now, I think it creates the impression oauth is for authentic= ation. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------- Originalnachricht -------- >>>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>> Von: John Bradley >>>>>>>> An: torsten@lodderstedt.net >>>>>>>> Cc: roland.hedberg@umu.se,oauth@ietf.org >>>>>>>>=20 >>>>>>>> This is not a issue between oauth and OIDC. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> This has to do with the registry for JWT being in OAuth. Many pro= tocols that use JWT are going to want to register claims. =20 >>>>>>>>=20 >>>>>>>> We can=E2=80=99t ask them to all move the parts of there specs that= use JWT to OAuth. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Perhaps JWT should have been part of JOSE, but that is water under t= he bridge. =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and w= e will need to deal with registering claims. =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> I guess that we can tell people that they need to publish the specs= defining the claims someplace else, and just do the registry part. >>>>>>>>=20 >>>>>>>> However doing that will probably not improve interoperability and u= nderstanding. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> This document defines the claim for JWT in general. We still have a= lmost no documentation in the WG about what a JWT access token would contain= other than the POP work. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> I basically support adoption of this document. Asserting authentica= tion methods in access tokens (in this case in JWTS format) is reasonable. W= e use it to pass information about the authentication performed prior issuin= g an access token to the _resource_ server. >>>>>>>>=20 >>>>>>>> What worries me is the back and forth between oauth and oidc. The a= mr claim is defined in oidc (which sits on top of oauth) but the oauth wg sp= ecifies the registry? Moreover, the current text does not give a rationale f= or using amr in context of oauth. >>>>>>>>=20 >>>>>>>> As a WG we need to find a clear delineation = between both protocols, otherwise noone will really= understand the difference and when to = use what. We create confusion! >>>>>>>>=20 >>>>>>>> For this particular draft = this means to either move amr to oauth or the registry to oidc. >>>>>>>>=20 >>>>>>>> best regards,=20 >>>>>>>> Torsten. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------- Urspr=C3=BCngliche = Nachricht -------- >>>>>>>> Von: Roland Hedberg >>>>>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>>>>> An: oauth@ietf.org >>>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>>=20 >>>>>>>> +1 >>>>>>>>=20 >>>>>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley : >>>>>>>> >=20 >>>>>>>> > +1 to adopt this draft. >>>>>>>> >=20 >>>>>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones wrote: >>>>>>>> >>=20 >>>>>>>> >> Draft -05 incorporates the feedback described below - deleting t= he request parameter, noting that this spec isn't an encouragement to use = OAuth 2.0 for authentication w= ithout employing appropriate = extensions, and no longer requiring a specification for IANA registration. = I believe that it=E2=80=99s now ready for working group adoption. >>>>>>>> >>=20 >>>>>>>> >> = -- Mike >>>>>>>> >>=20 >>>>>>>> >> -----Original Message----- >>>>>>>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes T= schofenig >>>>>>>> >> Sent: Thursday, February 4, 2016 11:23 AM >>>>>>>> >> To: oauth@ietf.org >>>>>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized >>>>>>>> >>=20 >>>>>>>> >> Hi all, >>>>>>>> >>=20 >>>>>>>> >> On January 19th I posted a call for adoption of the Authenticati= on Method Reference Values s= pecification, see http://www.ietf.org/mail-archive/web/oauth/current/msg1540= 2.html >>>>>>>> >>=20 >>>>>>>> >> What surprised us is that this work is conceptually very simple:= we define new claims and create a registry with new values. Not a big deal b= ut that's not what the feedb= ack from the Yokohama IETF meeting and the subsequent call for adoption on t= he list shows. The feedback lead to mixed feelings and it is a bit difficult= for Derek and myself to judge consensus. >>>>>>>> >>=20 >>>>>>>> >> Let me tell you what we see from the comments on the list. >>>>>>>> >>=20 >>>>>>>> >> In his review at >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html= James Manger asks for significant changes. Among other things, he wants to r= emove one of the claims. He provides a detailed review and actionable items.= >>>>>>>> >>=20 >>>>>>>> >> William Denniss believes the document is ready for adoption but a= grees with some of the comments from James. Here is his review: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html= >>>>>>>> >>=20 >>>>>>>> >> Justin is certainly the reviewer with the strongest opinion. Her= e is one of his posts: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html= >>>>>>>> >>=20 >>>>>>>> >> Among all concerns Justin expressed the following one is actuall= y actionable IMHO: Justin is worried that reporting how a person authenticat= ed to an authorization endpoint = and encouraging people to use OAuth for authentication is a fine line. H= e believes that this document leads readers to believe the latter. >>>>>>>> >>=20 >>>>>>>> >> John agrees with Justin in >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html= that we need to make sure that people are not mislead about the intention o= f the document. John also provides additional comments in this post to the >>>>>>>> >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg1544= 1.html >>>>>>>> >> Most of them require more than just editing work. For example, m= ethods listed are really not useful, >>>>>>>> >>=20 >>>>>>>> >> Phil agrees with the document adoption but has some remarks abou= t the registry although he does not propose specific text. His review is her= e: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html= >>>>>>>> >>=20 >>>>>>>> >> With my co-chair hat on: I just wanted to clarify that registeri= ng claims (and values within those claims) is within the scope of the OAuth w= orking group. We standardized the JWT in this group and we are also chartere= d to standardize claims, as we are currently doing with various drafts. Not s= tandardizing JWT in the IETF would have lead to reduced interoperability and= less security. I have no doubts that was a wrong decision. >>>>>>>> >>=20 >>>>>>>> >> In its current form, there is not enough support to have this do= cument as a WG item. >>>>>>>> >>=20 >>>>>>>> >> We believe that the document authors should address some of the e= asier comments and submit a new version. This would allow us to reach out to= those who had expressed concerns about the scope of the document to re-eval= uate their decision. A new draft version should at least address the followi= ng issues: >>>>>>>> >>=20 >>>>>>>> >> * Clarify that this document is not an encouragement for using O= Auth as an authentication protocol. I believe that this would address some o= f the concerns raised by Justin and John. >>>>>>>> >>=20 >>>>>>>> >> * Change the registry policy, which would address one of the com= ments from James, William, and Phil. >>>>>>>> >>=20 >>>>>>>> >> Various other items require discussion since they are more diffi= cult to address. For example, John noted that he does not like the use of re= quest parameters. Unfortunately, no alternative is offered. I urge John to p= rovide an alternative proposal, if there is one. Also, the remark that the v= alues are meaningless could be countered with an alternative proposal. James= wanted to remove the "amr_values" parameter. >>>>>>>> >> Is this what others want as well? >>>>>>>> >>=20 >>>>>>>> >> After these items have been addressed we believe that more folks= in the group will support the document. >>>>>>>> >>=20 >>>>>>>> >> Ciao >>>>>>>> >> Hannes & Derek >>>>>>>> >>=20 >>>>>>>> >>=20 >>>>>>>> >>=20 >>>>>>>> >> _______________________________________________ >>>>>>>> >> OAuth mailing list >>>>>>>> >> OAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >=20 >>>>>>>> > _______________________________________________ >>>>>>>> > OAuth mailing list >>>>>>>> > OAuth@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> =E2=80=94 Roland >>>>>>>>=20 >>>>>>>> =E2=80=9DEverybody should be quiet near a little stream and listen.= " >>>>>>>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss= >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-78198E4D-E743-469E-8865-62ECCA9FB97D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Phil

On Feb 15= , 2016, at 16:50, John Bradley <ve7j= tb@ve7jtb.com> wrote:

The question is what counts as re-authentication.  
It may be that the environm= ent is changing.  Re-prompting for a password in many cased just tells y= ou the user has a form filler.

It may be better to use risk based factors such as prompting fo= r a pin, or using a local passive biometric, eg has the phone got screen loc= k and is it in proximity to the persons smart watch etc.   <= div class=3D"">
What google seems to be d= oing is using the amr to say how they did the last authentication and leave i= t up to the client to decide if it is good enough.

Simple always ask for a password may no long= er provide the security that most people think it is giving.

Looking at what enterprise custom= ers are asking for, they are becoming more concerned with checking the MDM p= osture of the device at authentication.

=
This is a larger conversation about authentication con= text and methods.

= The establishment of the amr registry will provide a place to document a par= t of this, however authentication context (there is already a registry) and a= mr values themselves are probably out of scope for this WG.

John B.


On Feb 15, 2016, at 8:22 PM, Jim Manico <jim@manicode.com> wrote:
Polite comment, Google in general is prett= y "open" about session management in general - long idle timeout and no appa= rent absolute timeout. For a bank or other organization that produces high r= isk software, this is not standard practice. Re-authentication is a critical= security boundary, not prompting the user for re-authentication credentials= is unacceptable in those environments.

=
I may be jumping in out of context, but fair?

--
Jim Manico
@Manicode
+1 (808) 652-3805

On Feb 15, 2016, at 3:36 PM, William Denniss= <wdenniss@google.com> wrote:

We ret= urn 'amr' claims in ID Tokens if "max_age" is requested (per OpenID Connect)= , e.g.:

= https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdevel= opers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D= 407408718192.apps.googleusercontent.com&scope=3Dopenid+profile&appro= val_prompt=3Dforce&access_type=3Doffline&max_age=3D1

The reason we do thi= s is to be explicit about how we are processing the "max_age" reauth request= , specifically that we don't always prompt the user to reauthenticate direct= ly (but do perform in-session risk analysis).

I can see us potentially using the more generic a= mr values like "user", and "mfa" but we will probably avoid very specific on= es like "sms" or "otp" to avoid brittle relationships with RPs. That said, I= don't object to those being in the registry, perhaps there is value in some= tightly coupled enterprise configurations.


On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the cur= rent values.

I don't see any harm in the spec that establishe= s the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be reviewed= at the same time. 


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be t= he easiest way to address various needs and concerns. 

 =E2=80=94 Justin

On Feb 13, 2016, at 11:08 AM, Ph= il Hunt (IDM) <phil.hunt@oracle.com> wrote:

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@loddersted= t.net" <torsten@lodderstedt.net> wrote:

= So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@mi= crosoft.com>
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;co= lor:#002060" class=3D"">The context that most people on this thread probably don=E2=80=99t= have is that an IANA registry can only be established by an RFC.  Non-RFC specifications,= such as OpenID specifications, can *register* v= alues in a registry, but they cannot *establish* a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would have.=

 

I= nstead, RFCs need to be created to establish registries =E2=80=93 eve= n for values first defined in non-RFC specifications.  This= specification is one example of doing this.

 

  &n= bsp;            =             &nbs= p;            &n= bsp;            =      -- Mike

 

From: OAuth [mailto:oauth-bounces@ietf.org= ] On Behalf Of torsten@= lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley= <<= a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank" class=3D"">ve7jtb@ve7j= tb.com>
Cc: oauth@ietf.org
Subject: Re: [OA= UTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

 

W= e clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According t= o you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think i= t creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,o= auth@ietf.org

This is not a issue between oauth and OIDC.

 =

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can=E2=80=99t ask them to all move the parts of there specs that use JWT to OAuth.

 =

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 =

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we will= need to deal with registering claims.  

 =

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 =

This document defines the claim for JWT in general.  We still hav= e almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 =

John B.

On Feb 13, 2016, at 9:18 AM, = torsten@lodderstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For= this particular draft this means to either move amr to oauth or the registry to oidc.

bes= t regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedbe= rg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I believ= e that it=E2=80=99s now ready f= or working group adoption.
>>
>>   &n= bsp;            =             &nbs= p;            &n= bsp;            =      -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth= -bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth= /current/msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth= /current/msg15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth= /current/msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth= /current/msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth= /current/msg15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth= /current/msg15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth= /current/msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
= >> Hannes & Derek
>>
>>
>>
>> ____________________________= ___________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> ____________________________= ___________________
> OAuth mailing list
> OAuth@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be= quiet near a little stream and listen."
>=46rom =E2=80=99Open Hou= se for Butterflies=E2=80=99 by Ruth= Krauss


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

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

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


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




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


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

= --Apple-Mail-78198E4D-E743-469E-8865-62ECCA9FB97D-- From nobody Mon Feb 15 16:38:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37F1A8AD4 for ; Mon, 15 Feb 2016 16:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUu_Gpu484aI for ; Mon, 15 Feb 2016 16:38:16 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 4AB7B1A92B3 for ; Mon, 15 Feb 2016 16:38:16 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id b35so122169276qge.0 for ; Mon, 15 Feb 2016 16:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=+H7RYFekH+oVjtX3Eio8doNirH1Bcyg9w24u1SGZiCw=; b=TZSs2svufln+Y+tWuuxIuz/ivAmR4cI54ISaDFqwfgJ2c86fTZsJOTYW9kZSTxYQZ4 n0cnqR3bn5LyJ6bDdW/0qVc7BI/H9mlgQ0hHRhplUuxQZA5fc5zV7rcidZJrm/+ttP/c WNMs1/kp3L/sV4wh929GDAcIHzXvReoT52qCXQqH/F8Y3K1hJdtmSU95NjAIIVXqxJMP MmVUYPYiZ5ZYDN6LLhifQMFtxO4WU35tl4QQsnWzclabmrgzZEDkHOaw+dTloqJPkhTO NYuLpGGphtjodhueR5tRSCZJMlUpOpiHIR7SiIIio5tV120wPSgK3HYhDrFWd6a+EW8L 1vDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=+H7RYFekH+oVjtX3Eio8doNirH1Bcyg9w24u1SGZiCw=; b=X6KeCGeGWxTsJFWsNMwEBXlZ7MhORallozKuRKao//DMA8Tbs+3NPay9HFEEnJfxNX XqBfNN0Guse2bpW/USiz8sLbTTOJ3COs/MB0Jo2yKpDaWS/u7Zvf6Zn9WvQ1Eu3LeYMa JEO72v5U5vSTbHFcZefYHen/EDtA0xSnGVDmzvfyPIDaERsIhv7B0qqFQFZuLjOa54Jy bm8H8KG+AFz4RbcDTer8dyTsSE+OHkIv5+Bsi0FRXIZ+UTdJRqiVF2cY8FAdBbgI8AON FtCvuXbWXmMpFKHNuiQHORa524giHEb6ShLAqDAw/IbGo51zPdx8N9y8LFQg85mhZLhQ 9XMg== X-Gm-Message-State: AG10YOQJMw0AwODZH3q/qHUxh7zBlFWsMrWobXxkqcLtFS8dRV+fWsZAwaWwKZoBLC/hSuxT5fHBqz1sku6hAQ== X-Received: by 10.140.22.139 with SMTP id 11mr24413753qgn.34.1455583095363; Mon, 15 Feb 2016 16:38:15 -0800 (PST) MIME-Version: 1.0 References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> In-Reply-To: From: Nat Sakimura Date: Tue, 16 Feb 2016 00:38:04 +0000 Message-ID: To: "Phil Hunt (IDM)" , John Bradley Content-Type: multipart/alternative; boundary=001a11c151e25720e7052bd859bb Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 00:38:22 -0000 --001a11c151e25720e7052bd859bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Those login and logout ceremonies giving false impression of security probably will diminish its importance pretty quickly. I recon those more as a privacy feature than security. 2016=E5=B9=B42=E6=9C=8816=E6=97=A5(=E7=81=AB) 9:35 Phil Hunt (IDM) : > +1 > > > Phil > > On Feb 15, 2016, at 16:50, John Bradley wrote: > > The question is what counts as re-authentication. > > It may be that the environment is changing. Re-prompting for a password > in many cased just tells you the user has a form filler. > > It may be better to use risk based factors such as prompting for a pin, o= r > using a local passive biometric, eg has the phone got screen lock and is = it > in proximity to the persons smart watch etc. > > What google seems to be doing is using the amr to say how they did the > last authentication and leave it up to the client to decide if it is good > enough. > > Simple always ask for a password may no longer provide the security that > most people think it is giving. > > Looking at what enterprise customers are asking for, they are becoming > more concerned with checking the MDM posture of the device at > authentication. > > This is a larger conversation about authentication context and methods. > > The establishment of the amr registry will provide a place to document a > part of this, however authentication context (there is already a registry= ) > and amr values themselves are probably out of scope for this WG. > > John B. > > > On Feb 15, 2016, at 8:22 PM, Jim Manico wrote: > > Polite comment, Google in general is pretty "open" about session > management in general - long idle timeout and no apparent absolute timeou= t. > For a bank or other organization that produces high risk software, this i= s > not standard practice. Re-authentication is a critical security boundary, > not prompting the user for re-authentication credentials is unacceptable = in > those environments. > > I may be jumping in out of context, but fair? > > -- > Jim Manico > @Manicode > +1 (808) 652-3805 > > On Feb 15, 2016, at 3:36 PM, William Denniss wrote: > > We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID > Connect), e.g.: > > > https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fde= velopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D4074= 08718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt= =3Dforce&access_type=3Doffline&max_age=3D1 > > The reason we do this is to be explicit about how we are processing the > "max_age" reauth request, specifically that we don't always prompt the us= er > to reauthenticate directly (but do perform in-session risk analysis). > > I can see us potentially using the more generic amr values like "user", > and "mfa" but we will probably avoid very specific ones like "sms" or "ot= p" > to avoid brittle relationships with RPs. That said, I don't object to tho= se > being in the registry, perhaps there is value in some tightly coupled > enterprise configurations. > > > On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Denniss, >> >> out of curiosity: Does Google use amr values? >> >> best regards, >> Torsten. >> >> >> Am 14.02.2016 um 02:40 schrieb William Denniss: >> >> >> >> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > > wrote: >> >>> It's an acceptable fallback option if the working group decides it >>> doesn't want to register the values that are already in production use = at >>> the time we establish the registry. But add William points out, Google = is >>> already using some of these values. Microsoft is using some of them. Th= e >>> OpenID MODRNA specs are using some of them. So it seems more efficient = to >>> register them at the same time. >>> >>> That would be my preference. >>> >> >> +1, it is also my preference to register the current values. >> >> I don't see any harm in the spec that establishes the registry also >> seeding it with all known values in use at the time of drafting, regardl= ess >> of the group that originally specified them. Makes the original spec mor= e >> useful, and avoids the need to submit each value for consideration >> separately =E2=80=93 they can be all be reviewed at the same time. >> >> >> From: Justin Richer >>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>> To: Phil Hunt >>> >>> Cc: >>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call >>> for Adoption Finalized >>> >>> Can we just do that, then? Seems to be the easiest way to address >>> various needs and concerns. >>> >>> =E2=80=94 Justin >>> >>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) >>> wrote: >>> >>> Yes >>> >>> Phil >>> >>> On Feb 13, 2016, at 07:59, " >>> torsten@lodderstedt.net" wrote: >>> >>> So basically, the RFC could also just establish the new registry and >>> oidf could feel in the values? >>> >>> (just trying to understand) >>> >>> >>> -------- Originalnachricht -------- >>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call fo= r >>> Adoption Finalized >>> Von: Mike Jones < >>> Michael.Jones@microsoft.com> >>> An: torsten@lodderstedt.net,John Bradley < >>> ve7jtb@ve7jtb.com> >>> Cc: oauth@ietf.org >>> >>> The context that most people on this thread probably don=E2=80=99t have= is that >>> an IANA registry can only be established by an RFC. Non-RFC >>> specifications, such as OpenID specifications, can **register** values >>> in a registry, but they cannot **establish** a registry. The OpenID >>> Foundation inquired about this with the IETF before OpenID Connect was >>> finalized and learned that its specifications could not establish IANA >>> registries. Otherwise, they would have. >>> >>> >>> Instead, RFCs need to be created to establish registries =E2=80=93 even= for >>> values first defined in non-RFC specifications. This specification is = one >>> example of doing this. >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* OAuth [ mailto:oauth-bounces@ietf.org >>> ] *On Behalf Of * >>> torsten@lodderstedt.net >>> *Sent:* Saturday, February 13, 2016 6:37 AM >>> *To:* John Bradley < ve7jtb@ve7jtb.com> >>> *Cc:* oauth@ietf.org >>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values: Call >>> for Adoption Finalized >>> >>> >>> We clearly have this problem between oauth and oidc. Just take a look a= t >>> the discovery thread. >>> >>> According to you argument I see two options: >>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg just >>> publishes the registry entries. In this case, the spec should clearly >>> explain this. >>> (2) amr is of any use in oauth (although it has been invented in oidc) = - >>> than define it and motivate it's use in oauth in this spec. >>> >>> Right now, I think it creates the impression oauth is for >>> authentication. >>> >>> >>> >>> -------- Originalnachricht -------- >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call fo= r >>> Adoption Finalized >>> Von: John Bradley < ve7jtb@ve7jtb.com> >>> An: torsten@lodderstedt.net >>> Cc: roland.hedberg@umu.se,oauth@ietf.org >>> >>> This is not a issue between oauth and OIDC. >>> >>> >>> This has to do with the registry for JWT being in OAuth. Many >>> protocols that use JWT are going to want to register claims. >>> >>> We can=E2=80=99t ask them to all move the parts of there specs that use= JWT to >>> OAuth. >>> >>> >>> Perhaps JWT should have been part of JOSE, but that is water under the >>> bridge. >>> >>> >>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we w= ill need >>> to deal with registering claims. >>> >>> >>> I guess that we can tell people that they need to publish the specs >>> defining the claims someplace else, and just do the registry part. >>> >>> However doing that will probably not improve interoperability and >>> understanding. >>> >>> >>> This document defines the claim for JWT in general. We still have >>> almost no documentation in the WG about what a JWT access token would >>> contain other than the POP work. >>> >>> >>> John B. >>> >>> On Feb 13, 2016, at 9:18 AM, >>> torsten@lodderstedt.net wrote: >>> >>> >>> I basically support adoption of this document. Asserting authentication >>> methods in access tokens (in this case in JWTS format) is reasonable. W= e >>> use it to pass information about the authentication performed prior iss= uing >>> an access token to the _resource_ server. >>> >>> What worries me is the back and forth between oauth and oidc. The amr >>> claim is defined in oidc (which sits on top of oauth) but the oauth wg >>> specifies the registry? Moreover, the current text does not give a >>> rationale for using amr in context of oauth. >>> >>> As a WG we need to find a clear delineation between both protocols, >>> otherwise noone will really understand the difference and when to use w= hat. >>> We create confusion! >>> >>> For this particular draft this means to either move amr to oauth or the >>> registry to oidc. >>> >>> best regards, >>> Torsten. >>> >>> >>> >>> -------- Urspr=C3=BCngliche Nachricht -------- >>> Von: Roland Hedberg < roland.hedberg@umu.se> >>> Gesendet: Friday, February 12, 2016 05:45 PM >>> An: oauth@ietf.org >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call fo= r >>> Adoption Finalized >>> >>> +1 >>> >>> > 12 feb 2016 kl. 16:58 skrev John Bradley < >>> ve7jtb@ve7jtb.com>: >>> > >>> > +1 to adopt this draft. >>> > >>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote: >>> >> >>> >> Draft -05 incorporates the feedback described below - deleting the >>> request parameter, noting that this spec isn't an encouragement to use >>> OAuth 2.0 for authentication without employing appropriate extensions, = and >>> no longer requiring a specification for IANA registration. I believe t= hat >>> it=E2=80=99s now ready for working group adoption. >>> >> >>> >> -- Mike >>> >> >>> >> -----Original Message----- >>> >> From: OAuth [ mailto:oauth-bounces@ietf.org >>> ] On Behalf Of Hannes Tschofenig >>> >> Sent: Thursday, February 4, 2016 11:23 AM >>> >> To: oauth@ietf.org >>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for >>> Adoption Finalized >>> >> >>> >> Hi all, >>> >> >>> >> On January 19th I posted a call for adoption of the Authentication >>> Method Reference Values specification, see >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html >>> >> >>> >> What surprised us is that this work is conceptually very simple: we >>> define new claims and create a registry with new values. Not a big deal= but >>> that's not what the feedback from the Yokohama IETF meeting and the >>> subsequent call for adoption on the list shows. The feedback lead to mi= xed >>> feelings and it is a bit difficult for Derek and myself to judge consen= sus. >>> >> >>> >> Let me tell you what we see from the comments on the list. >>> >> >>> >> In his review at >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James >>> Manger asks for significant changes. Among other things, he wants to re= move >>> one of the claims. He provides a detailed review and actionable items. >>> >> >>> >> William Denniss believes the document is ready for adoption but >>> agrees with some of the comments from James. Here is his review: >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>> >> >>> >> Justin is certainly the reviewer with the strongest opinion. Here is >>> one of his posts: >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>> >> >>> >> Among all concerns Justin expressed the following one is actually >>> actionable IMHO: Justin is worried that reporting how a person >>> authenticated to an authorization endpoint and encouraging people to us= e >>> OAuth for authentication is a fine line. He believes that this document >>> leads readers to believe the latter. >>> >> >>> >> John agrees with Justin in >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that >>> we need to make sure that people are not mislead about the intention of= the >>> document. John also provides additional comments in this post to the >>> >> list: >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >>> >> Most of them require more than just editing work. For example, >>> methods listed are really not useful, >>> >> >>> >> Phil agrees with the document adoption but has some remarks about th= e >>> registry although he does not propose specific text. His review is here= : >>> >> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>> >> >>> >> With my co-chair hat on: I just wanted to clarify that registering >>> claims (and values within those claims) is within the scope of the OAut= h >>> working group. We standardized the JWT in this group and we are also >>> chartered to standardize claims, as we are currently doing with various >>> drafts. Not standardizing JWT in the IETF would have lead to reduced >>> interoperability and less security. I have no doubts that was a wrong >>> decision. >>> >> >>> >> In its current form, there is not enough support to have this >>> document as a WG item. >>> >> >>> >> We believe that the document authors should address some of the >>> easier comments and submit a new version. This would allow us to reach = out >>> to those who had expressed concerns about the scope of the document to >>> re-evaluate their decision. A new draft version should at least address= the >>> following issues: >>> >> >>> >> * Clarify that this document is not an encouragement for using OAuth >>> as an authentication protocol. I believe that this would address some o= f >>> the concerns raised by Justin and John. >>> >> >>> >> * Change the registry policy, which would address one of the comment= s >>> from James, William, and Phil. >>> >> >>> >> Various other items require discussion since they are more difficult >>> to address. For example, John noted that he does not like the use of >>> request parameters. Unfortunately, no alternative is offered. I urge Jo= hn >>> to provide an alternative proposal, if there is one. Also, the remark t= hat >>> the values are meaningless could be countered with an alternative propo= sal. >>> James wanted to remove the "amr_values" parameter. >>> >> Is this what others want as well? >>> >> >>> >> After these items have been addressed we believe that more folks in >>> the group will support the document. >>> >> >>> >> Ciao >>> >> Hannes & Derek >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> =E2=80=94 Roland >>> >>> =E2=80=9DEverybody should be quiet near a little stream and listen." >>> >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c151e25720e7052bd859bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Those login and logout ceremonies giving false impression of security pr= obably will diminish its importance pretty quickly. I recon those more as a= privacy feature than security.
2016=E5=B9=B42=E6=9C=8816=E6=97=A5(=E7=81=AB) 9:35 Phil Hunt (IDM) <= ;phil.hunt@oracle.com>:
<= /div>
+1


Phil

On = Feb 15, 2016, at 16:50, John Bradley <ve7jtb@ve7jtb.com> wrote:

The question is what counts = as re-authentication. =C2=A0

It may be that the environm= ent is changing.=C2=A0 Re-prompting for a password in many cased just tells= you the user has a form filler.

It may be better = to use risk based factors such as prompting for a pin, or using a local pas= sive biometric, eg has the phone got screen lock and is it in proximity to = the persons smart watch etc. =C2=A0=C2=A0

What goo= gle seems to be doing is using the amr to say how they did the last authent= ication and leave it up to the client to decide if it is good enough.
=

Simple always ask for a password may no longer provide = the security that most people think it is giving.

= Looking at what enterprise customers are asking for, they are becoming more= concerned with checking the MDM posture of the device at authentication.

This is a larger conversation about authentication = context and methods.

The establishment of the amr = registry will provide a place to document a part of this, however authentic= ation context (there is already a registry) and amr values themselves are p= robably out of scope for this WG.

John B.


On Feb 15, 2016, a= t 8:22 PM, Jim Manico <jim@manicode.com> wrote:

P= olite comment, Google in general is pretty "open" about session m= anagement in general - long idle timeout and no apparent absolute timeout. = For a bank or other organization that produces high risk software, this is = not standard practice. Re-authentication is a critical security boundary, n= ot prompting the user for re-authentication credentials is unacceptable in = those environments.

I may be jumping in out of con= text, but fair?

--
Jim Manico
@Manicode
+1 (808) 652-3805

On Feb 15, 2016, at 3:36 PM, W= illiam Denniss <wdenniss@google.com> wrote:

=
We return 'amr' claims in ID Tokens if &= quot;max_age" is requested (per OpenID Connect), e.g.:

<= /div>https://accounts.google.com/o/oauth2/auth?redirect_= uri=3Dhttps%3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_ty= pe=3Dcode&client_id=3D407408718192.apps.googleusercontent.com&scope= =3Dopenid+profile&approval_prompt=3Dforce&access_type=3Doffline&= ;max_age=3D1

The reason we do this is to be expl= icit about how we are processing the "max_age" reauth request, sp= ecifically that we don't always prompt the user to reauthenticate direc= tly (but do perform in-session risk analysis).

I c= an see us potentially using the more generic amr values like "user&quo= t;, and "mfa" but we will probably avoid very specific ones like = "sms" or "otp" to avoid brittle relationships with RPs.= That said, I don't object to those being in the registry, perhaps ther= e is value in some tightly coupled enterprise configurations.

On Sun, Fe= b 14, 2016 at 5:30 AM, Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.

I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be reviewe= d at the same time.=C2=A0


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>=
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns.=C2=A0

=C2=A0=E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net&quo= t; <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just t= rying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com>=
An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

The context that most people on this thread probably don=E2=80=99= t have is that an IANA registry can only be established by an RFC.=C2=A0 Non-RFC specifications= , such as OpenID specifications, can *register* values in a registry, but they cannot *establish* a registry.=C2=A0 The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.=C2=A0 Otherwise, they would have.

=C2=A0

Instead, RFCs need to be created to establish registries =E2=80=93 ev= en for values first defined in non-RFC specifications.=C2=A0 Thi= s specification is one example of doing this.

=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

<= b>From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

=C2=A0

We clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According to you argu= ment I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf= .org

This is not a issue between oauth and OIDC.

=C2=A0

This has = to do with the registry for JWT being in OAuth. =C2=A0 Many protocols that use JWT are going to want to register claims. =C2=A0

We can=E2= =80=99t ask them to all move the parts of there specs that use JWT to OAuth.

=C2=A0

Perhaps J= WT should have been part of JOSE, but that is water under the bridge. =C2=A0

=C2=A0

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we wil= l need to deal with registering claims. =C2=A0

=C2=A0

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

=C2=A0

This document defines the claim for JWT in general.=C2=A0 We still ha= ve almost no documentation in the WG about what a JWT access token would contain other than the POP work.

=C2=A0

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lo= dderstedt.net wrote:

=C2=A0

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

Fo= r this particular draft this means to either move amr to oauth or the registry to oidc.

be= st regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se> Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

<= p class=3D"MsoNormal">+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.=C2=A0 I belie= ve that it=E2=80=99s now ready= for working group adoption.
>>
>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/= msg15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/= msg15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> http://www.ietf.org/mail-archive/web/oauth/current/= msg15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> ___________________________= ____________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf= .org/mailman/listinfo/oauth
>
> ___________________________= ____________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org= /mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should b= e quiet near a little stream and listen." >From =E2=80=99Open Hous= e for Butterflies=E2=80=99 by Rut= h Krauss


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

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

=C2=A0
______________________________= _________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oau= th




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


___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___________________= ____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11c151e25720e7052bd859bb-- From nobody Tue Feb 16 00:23:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CF21A90CF for ; Tue, 16 Feb 2016 00:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_dCNwPkXQGd for ; Tue, 16 Feb 2016 00:23:05 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 928561A88BC for ; Tue, 16 Feb 2016 00:23:04 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id j78so103312665lfb.1 for ; Tue, 16 Feb 2016 00:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=A6kEIuWl8S5vKmGOFWrfYE1tOsJpKGoAKDOr8ryYQUA=; b=pEfK1MSOojHxD3UAOQTIISSPem0+LI4vqxMnSHjtJ6j13GGzVxkhAhsFI2JfIEKBcg RRDwRzF43pI0QXFpfQRK8iVxHUqnwAyM/trbaEe9Q3O7+wrOEW9j3omH7hRkvOOaE2f8 pJZd089iYES69doUe9DbPB91R0bazghcEQJpn+7JTI5yuP7lflv2gGacN8NYuMaIRDXL VT3RQ1LdtPFAyXs9IobckyvpI1Q4esk4zZiH+hhnGDiCoUJGaYFvgGjygekFAtGh5QaL u7FRbC0VAf0rNEPLmI6S0NfskBgQseHk5LfcZoM2I4how33b2R4Wipt+aMGOoJVTOhLE vX2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=A6kEIuWl8S5vKmGOFWrfYE1tOsJpKGoAKDOr8ryYQUA=; b=Eekp/vRjdJVpb71dzKUMC/quSmOZC2iA1nfTDF5Eg9+mbeLGVfuRTY188NrDglXPQm q57UApS84qrzaQ2IstTvyOOKLUe53VYZn32XrWa+0x1izgRNb1moEGFM1E80QaXtd330 tDEt0cJ1JmQviT0iaI5WAHrrilZruZPrYMEh2cA15UxXLc+WcSPfIWPe1HFoTRRehLCH q+0l6dHsZ7tTgvDpaHbuvYtaFDMZ+V0WAHQAG/2v5qZIAHTyRUXNkV0yymoVdOZcKzuE G63stfXB41cunMyJ3WJogezFBYWGVjQuAPK0WN2QCZ9mtxX45s9AMo5gYthtGQ2EBGEU w5rQ== X-Gm-Message-State: AG10YOR1x8zEuRRGSFuypYh4izIGNCUZUW1cygM3Fql969PEG+DhyIzjMIljmwFY3hNqEsAhd59EOgbXX0LRng== X-Received: by 10.25.148.208 with SMTP id w199mr9014513lfd.124.1455610982779; Tue, 16 Feb 2016 00:23:02 -0800 (PST) MIME-Version: 1.0 References: <56B3A400.2080606@gmx.net> <62D1E1DB-17A4-4ABD-81F3-8659F40D7E88@mit.edu> In-Reply-To: From: Thomas Broyer Date: Tue, 16 Feb 2016 08:22:52 +0000 Message-ID: To: Eduardo Gueiros , Adam Lewis Content-Type: multipart/alternative; boundary=001a1140234c8f514c052bded748 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 08:23:07 -0000 --001a1140234c8f514c052bded748 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fwiw, French govt's FranceConnect, which uses OpenID Connect, has sample apps using web views, and not using PKCE :-( (haven't looked in more details; don't know whether their AS supports PKCE). I just implemented PKCE in Ozwillo 10 days ago after reading this doc. I still have some work to do to properly support native apps though, and then I could build a sample app. Le mar. 16 f=C3=A9vr. 2016 00:18, Eduardo Gueiros a =C3= =A9crit : > +1 Being in the mobile space myself and constantly meeting with native ap= p > developers I've heard my share of horror stories on how OAuth was > implemented, myself being guilty of being "creative" around OAuth. > > This draft is be of great value to those of us who are around these > developers, we'll be helping bringing awareness about the correct practic= es > suggested in the document. > > On Fri, Feb 5, 2016 at 8:10 AM, Adam Lewis < > adam.lewis@motorolasolutions.com> wrote: > >> +1 that it should be Informational. >> >> Also, I never got to respond to the original request, but I am heavily i= n >> favor of this draft. I talk with a lot of native app developers who are >> clueless about how to implement OAuth. The core RFC is very web app >> oriented. I look forward to having a more profiled RFC to point them to= :-) >> >> adam >> >> On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer wrote: >> >>> I=E2=80=99d like to note that when Tony brought up it being Experimenta= l on the >>> list, several of us (myself included) pointed out that Informational is= the >>> correct designation for this specification. >>> >>> =E2=80=94 Justin >>> >>> > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig < >>> hannes.tschofenig@gmx.net> wrote: >>> > >>> > Hi all, >>> > >>> > On January 19th I posted a call for adoption of the OAuth 2.0 for >>> Native >>> > Apps specification, see >>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html >>> > >>> > There was very positive feedback during the Yokohama IETF meeting to >>> > work on this document in the OAuth working group. More than 10 person= s >>> > responded positively to the call on the mailing list as well. >>> > >>> > Several persons provided additional input for content changes during >>> the >>> > call and here are the relevant links: >>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html >>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html >>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html >>> > >>> > Tony also noted that this document should become an Experimental RFC >>> > rather than a Standards Track RFC. The chairs will consult with the >>> > Security Area directors on this issue. >>> > >>> > To conclude, based on the call wil= l >>> > become the starting point for work in OAuth. Please submit the docume= nt >>> > as draft-ietf-oauth-native-apps-00.txt. >>> > >>> > Ciao >>> > Hannes & Derek >>> > >>> > >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > -- > *Eduardo Gueiros* > *Director, Mobile B.U.* | Jive Communications, Inc. > jive.com | *egueiros@jive.com * > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1140234c8f514c052bded748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Fwiw, French govt's FranceConnect, which uses OpenID Connect, has sampl= e apps using web views, and not using PKCE :-( (haven't looked in more = details; don't know whether their AS supports PKCE).
I just implemented PKCE in Ozwillo 10 days ago after reading this doc. I st= ill have some work to do to properly support native apps though, and then I= could build a sample app.


Le=C2=A0mar. 16 f=C3=A9vr. = 2016 00:18,=C2=A0Eduardo Gueiros <e= gueiros@jive.com> a =C3=A9crit=C2=A0:
+1 Being in the mobile space myself and constant= ly meeting with native app developers I've heard my share of horror sto= ries on how OAuth was implemented, myself being guilty of being "creat= ive" around OAuth.=C2=A0

This draft is be of great = value to those of us who are around these developers, we'll be helping = bringing awareness about the correct practices suggested in the document.= =C2=A0

On Fri, Feb 5, 2016 at 8:10 AM, Adam Lewi= s <adam.lewis@motorolasolutions.com> wrote:
+1 that it should be Info= rmational.

Also, I never got to respond to the original = request, but I am heavily in favor of this draft. I talk with a lot of nati= ve app developers who are clueless about how to implement OAuth.=C2=A0 The = core RFC is very web app oriented.=C2=A0 I look forward to having a more pr= ofiled RFC to point them to :-)
adam

On Thu, Feb 4, 2016 at 7:13 PM, Justin R= icher <jricher@mit.edu> wrote:
I=E2=80=99d like to note that when Tony brought up it being Experimental= on the list, several of us (myself included) pointed out that Informationa= l is the correct designation for this specification.

=C2=A0=E2=80=94 Justin

> On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:
>
> Hi all,
>
> On January 19th I posted a call for adoption of the OAuth 2.0 for Nati= ve
> Apps specification, see
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15400.html
>
> There was very positive feedback during the Yokohama IETF meeting to > work on this document in the OAuth working group. More than 10 persons=
> responded positively to the call on the mailing list as well.
>
> Several persons provided additional input for content changes during t= he
> call and here are the relevant links:
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15434.html
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15435.html
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15438.html
>
> Tony also noted that this document should become an Experimental RFC > rather than a Standards Track RFC. The chairs will consult with the > Security Area directors on this issue.
>
> To conclude, based on the call <draft-wdenniss-oauth-native-apps>= ; will
> become the starting point for work in OAuth. Please submit the documen= t
> as draft-ietf-oauth-native-apps-00.txt.
>
> Ciao
> Hannes & Derek
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


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



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




--
--=C2=A0
Eduardo Gueir= os
Director, Mobi= le B.U.=C2=A0| =C2=A0Jive Communications, Inc.
jive.com=C2= =A0=C2=A0| =C2=A0egueiros@jive.com
3D"=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1140234c8f514c052bded748-- From nobody Tue Feb 16 03:05:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EE91B331F for ; Tue, 16 Feb 2016 03:05:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrogKX2yr3yD for ; Tue, 16 Feb 2016 03:05:14 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 018411B3323 for ; Tue, 16 Feb 2016 03:05:13 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id fy10so62218441pac.1 for ; Tue, 16 Feb 2016 03:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NS+WTcfAno12/hbp8sKgBmEHO1GakBNjM9UzD8SBdMY=; b=AdGHy1RCgyHAzy5+KWwDUmg19XWmsu5OiuI7wiu0T8bT2SqrXPfKb3sX4x0LfgLIgM Rz4DJJNpfnGeZQwgEuq1dCG3T3BjCO7BXjXBABXwJzd0veXNV+Ktd3FesrF23g0Z9woV c1rAN1I/MCw53WknUqVxaJCQ1EOaoNWYoe5qIQVDb30p/BI7xanzS/xQXCWolPQK4Msj VKTud8O9hEHtOJdyl0vSBa0D//Pjo4LtR7ySv17hA9gyJLTqU+Qt0P5+ydXgy9NrPyk5 uqYvEcrQAX2Mr9q4Daio7WyGaea2yFDulYfoKfqZfopxi8xSEG95G3RkuVr2UjWrQ7/K JSig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NS+WTcfAno12/hbp8sKgBmEHO1GakBNjM9UzD8SBdMY=; b=K24UGvEvuIgh3I+7QA2foNVLlU3i03wslCuMkTltkw9A+1cOmrfKDoUH1qfazCRpyh kg+O1esgLoqTWMwoW9csdOfpbFqIPu0wCjB+5J7uyDVABT+my82EDTI90niAIdNf49xs vC3pOgnRbMGPcM0hEsyoyCeMXMFoN3MtWQezJwmQ8N6pXrt5dOhLVGJYco4SE5EqHI2b cyA+jkuH6yvE6zAISVLITOi7QmiEte6bi/yeo40p72XLnbtIAXwZj/WL7oRncUuzCspz npDw/+hzcwt4/hswdfMpZ8RWRWsXno2R374jJ2elEIMy2Ze/9g5MgDorC7tKdJHHaGHY vBVg== X-Gm-Message-State: AG10YORz5Gl8qvkgoFDUSuFO/HxAznZtciiBi5rkvpJgz+TGX11aHz4VyZBk9yIfCzhzTrkc X-Received: by 10.66.220.104 with SMTP id pv8mr29976527pac.140.1455620713467; Tue, 16 Feb 2016 03:05:13 -0800 (PST) Received: from [10.126.115.111] (mobile-166-176-59-192.mycingular.net. [166.176.59.192]) by smtp.gmail.com with ESMTPSA id t12sm44937750pfa.54.2016.02.16.03.05.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 03:05:11 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-53AA9D07-0964-4ABB-90D3-EA38F0D6F805 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (13D15) In-Reply-To: <138A2A47-E970-428F-8994-BAEB0BEA3894@oracle.com> Date: Tue, 16 Feb 2016 04:05:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <76769768-47AE-4A28-B922-A516EB8F5DDA@manicode.com> References: <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <56C0816B.8070005@lodderstedt.net> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> <138A2A47-E970-428F-8994-BAEB0BEA3894@oracle.com> To: "Phil Hunt (IDM)" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 11:05:21 -0000 --Apple-Mail-53AA9D07-0964-4ABB-90D3-EA38F0D6F805 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phil, There are four standard session ending controls. 1) Logout 2) Idle session timeout 3) Absolute timeout 4) Forced re-authentication I think these are still important and tend to not get full attention from th= e OAuth/OIDC crowd. :)=20 But the OAuth 2 standard in particular is a framework - not a standard - whi= ch can be implemented many ways, of course. Aloha, -- Jim Manico @Manicode > On Feb 15, 2016, at 5:34 PM, Phil Hunt (IDM) wrote:= >=20 > In older systems, time based logout is all you have if you aren't assessin= g risk.=20 >=20 > I would think over time will quickly diminish in its importance (or as bes= t practice) - at least as the single method for determine a session should e= nd other than explicit logout.=20 >=20 > Phil >=20 >> On Feb 15, 2016, at 16:22, Jim Manico wrote: >>=20 >> Polite comment, Google in general is pretty "open" about session manageme= nt in general - long idle timeout and no apparent absolute timeout. For a ba= nk or other organization that produces high risk software, this is not stand= ard practice. Re-authentication is a critical security boundary, not prompti= ng the user for re-authentication credentials is unacceptable in those envir= onments. >>=20 >> I may be jumping in out of context, but fair? >>=20 >> -- >> Jim Manico >> @Manicode >> +1 (808) 652-3805 >>=20 >>> On Feb 15, 2016, at 3:36 PM, William Denniss wrote= : >>>=20 >>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenI= D Connect), e.g.: >>>=20 >>> https://accounts.google.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fd= evelopers.google.com%2Foauthplayground&response_type=3Dcode&client_id=3D4074= 08718192.apps.googleusercontent.com&scope=3Dopenid+profile&approval_prompt=3D= force&access_type=3Doffline&max_age=3D1 >>>=20 >>> The reason we do this is to be explicit about how we are processing the "= max_age" reauth request, specifically that we don't always prompt the user t= o reauthenticate directly (but do perform in-session risk analysis). >>>=20 >>> I can see us potentially using the more generic amr values like "user", a= nd "mfa" but we will probably avoid very specific ones like "sms" or "otp" t= o avoid brittle relationships with RPs. That said, I don't object to those b= eing in the registry, perhaps there is value in some tightly coupled enterpr= ise configurations. >>>=20 >>>=20 >>>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt wrote: >>>> Hi Denniss, >>>>=20 >>>> out of curiosity: Does Google use amr values?=20 >>>>=20 >>>> best regards, >>>> Torsten. >>>>=20 >>>>=20 >>>>> Am 14.02.2016 um 02:40 schrieb William Denniss: >>>>>=20 >>>>>=20 >>>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones wrote: >>>>>> It's an acceptable fallback option if the working group decides it do= esn't want to register the values that are already in production use at the t= ime we establish the registry. But add William points out, Google is already= using some of these values. Microsoft is using some of them. The OpenID MOD= RNA specs are using some of them. So it seems more efficient to register the= m at the same time. >>>>>>=20 >>>>>> That would be my preference. >>>>>=20 >>>>> +1, it is also my preference to register the current values. >>>>>=20 >>>>> I don't see any harm in the spec that establishes the registry also se= eding it with all known values in use at the time of drafting, regardless of= the group that originally specified them. Makes the original spec more usef= ul, and avoids the need to submit each value for consideration separately =E2= =80=93 they can be all be reviewed at the same time.=20 >>>>>=20 >>>>>=20 >>>>>> From: Justin Richer >>>>>> Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM >>>>>> To: Phil Hunt >>>>>>=20 >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call f= or Adoption Finalized >>>>>>=20 >>>>>> Can we just do that, then? Seems to be the easiest way to address var= ious needs and concerns.=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) = wrote: >>>>>>>=20 >>>>>>> Yes >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" wrote: >>>>>>>=20 >>>>>>>> So basically, the RFC could also just establish the new registry an= d oidf could feel in the values? >>>>>>>>=20 >>>>>>>> (just trying to understand) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------- Originalnachricht -------- >>>>>>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>> Von: Mike Jones >>>>>>>> An: torsten@lodderstedt.net,John Bradley >>>>>>>> Cc: oauth@ietf.org >>>>>>>>=20 >>>>>>>> The context that most people on this thread probably don=E2=80=99t h= ave is that an IANA registry can only be established by an RFC. Non-RFC spe= cifications, such as OpenID specifications, can *register* values in a regis= try, but they cannot *establish* a registry. The OpenID Foundation inquired= about this with the IETF before OpenID Connect was finalized and learned th= at its specifications could not establish IANA registries. = Otherwise, they would have. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Instead, RFCs need to be created to establish registries =E2=80=93 e= ven for values first defined in non-RFC specifications. This specification i= s one example of doing this. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lo= dderstedt.net >>>>>>>> Sent: Saturday, February 13, 2016 6:37 AM >>>>>>>> To: John Bradley >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> We clearly have this problem between oauth and oidc. Just take a lo= ok at the discovery thread. >>>>>>>>=20 >>>>>>>> According to you argument I see two options: >>>>>>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg j= ust publishes the registry entries. In this case, the spec should clearly ex= plain this. >>>>>>>> (2) amr is of any use in oauth (although it has been invented in oi= dc) - than define it and motivate it's use in oauth in this spec. >>>>>>>>=20 >>>>>>>> Right now, I think it creates the impression oauth is for authentic= ation. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------- Originalnachricht -------- >>>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>> Von: John Bradley >>>>>>>> An: torsten@lodderstedt.net >>>>>>>> Cc: roland.hedberg@umu.se,oauth@ietf.org >>>>>>>>=20 >>>>>>>> This is not a issue between oauth and OIDC. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> This has to do with the registry for JWT being in OAuth. Many pro= tocols that use JWT are going to want to register claims. =20 >>>>>>>>=20 >>>>>>>> We can=E2=80=99t ask them to all move the parts of there specs that= use JWT to OAuth. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Perhaps JWT should have been part of JOSE, but that is water under t= he bridge. =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> The OAuth WG is responsible for JWT and it=E2=80=99s registry, and w= e will need to deal with registering claims. =20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I guess that we can tell people that they need to publish the specs= defining the claims someplace else, and just do the registry part. >>>>>>>>=20 >>>>>>>> However doing that will probably not improve interoperability and u= nderstanding. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> This document defines the claim for JWT in general. We still have a= lmost no documentation in the WG about what a JWT access token would contain= other than the POP work. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On Feb 13, 2016, at 9:18 AM, torsten@lodderstedt.net wrote: >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I basically support adoption of this document. Asserting authentica= tion methods in access tokens (in this case in JWTS format) is reasonable. W= e use it to pass information about the authentication performed prior issuin= g an access token to the _resource_ server. >>>>>>>>=20 >>>>>>>> What worries me is the back and forth between oauth and oidc. The a= mr claim is defined in oidc (which sits on top of oauth) but the oauth wg sp= ecifies the registry? Moreover, the current text does not give a rationale f= or using amr in context of oauth. >>>>>>>>=20 >>>>>>>> As a WG we need to find a clear delineation between both protocols,= otherwise noone will really understand the difference and when to use what.= We create confusion! >>>>>>>>=20 >>>>>>>> For this particular draft this means to either move amr to oauth or= the registry to oidc. >>>>>>>>=20 >>>>>>>> best regards,=20 >>>>>>>> Torsten. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -------- Urspr=C3=BCngliche Nachricht -------- >>>>>>>> Von: Roland Hedberg >>>>>>>> Gesendet: Friday, February 12, 2016 05:45 PM >>>>>>>> An: oauth@ietf.org >>>>>>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Cal= l for Adoption Finalized >>>>>>>>=20 >>>>>>>> +1 >>>>>>>>=20 >>>>>>>> > 12 feb 2016 kl. 16:58 skrev John Bradley : >>>>>>>> >=20 >>>>>>>> > +1 to adopt this draft. >>>>>>>> >=20 >>>>>>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones wrote: >>>>>>>> >>=20 >>>>>>>> >> Draft -05 incorporates the feedback described below - deleting t= he request parameter, noting that this spec isn't an encouragement to use OA= uth 2.0 for authentication without employing appropriate extensions, and no l= onger requiring a specification for IANA registration. I believe that it=E2= =80=99s now ready for working group adoption. >>>>>>>> >>=20 >>>>>>>> >> -- Mik= e >>>>>>>> >>=20 >>>>>>>> >> -----Original Message----- >>>>>>>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes T= schofenig >>>>>>>> >> Sent: Thursday, February 4, 2016 11:23 AM >>>>>>>> >> To: oauth@ietf.org >>>>>>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call= for Adoption Finalized >>>>>>>> >>=20 >>>>>>>> >> Hi all, >>>>>>>> >>=20 >>>>>>>> >> On January 19th I posted a call for adoption of the Authenticati= on Method Reference Values s= pecification, see http://www.ietf.org/mail-archive/web/oauth/current/msg1540= 2.html >>>>>>>> >>=20 >>>>>>>> >> What surprised us is that this work is conceptually very simple:= we define new claims and create a registry with new values. Not a big deal b= ut that's not what the feedback from the Yokohama IETF meeting and the subse= quent call for adoption on the list shows. The feedback lead to mixed feelin= gs and it is a bit difficult for Derek and myself to judge consensus. >>>>>>>> >>=20 >>>>>>>> >> Let me tell you what we see from the comments on the list. >>>>>>>> >>=20 >>>>>>>> >> In his review at >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html= James Manger asks for significant changes. Among other things, he wants to r= emove one of the claims. He provides a detailed review and actionable items.= >>>>>>>> >>=20 >>>>>>>> >> William Denniss believes the document is ready for adoption but a= grees with some of the comments from James. Here is his review: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html= >>>>>>>> >>=20 >>>>>>>> >> Justin is certainly the reviewer with the strongest opinion. Her= e is one of his posts: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html= >>>>>>>> >>=20 >>>>>>>> >> Among all concerns Justin expressed the following one is actuall= y actionable IMHO: Justin is= worried that reporting how a= person authenticated to an authorization endpoint and encouraging people to= use OAuth for authentication is a fine line. He believes that this document= leads readers to believe the latter. >>>>>>>> >>=20 >>>>>>>> >> John agrees with Justin in >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html= that we need to make sure that people are not mislead about the intention o= f the document. John also provides additional comments in this post to the >>>>>>>> >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg1544= 1.html >>>>>>>> >> Most of them require more than just editing work. For example, m= ethods listed are really not useful, >>>>>>>> >>=20 >>>>>>>> >> Phil agrees with the document adoption but has some remarks abou= t the registry although he does not propose specific text. His review is her= e: >>>>>>>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html= >>>>>>>> >>=20 >>>>>>>> >> With my co-chair hat on: I just wanted to clarify that registeri= ng claims (and values within those claims) is within the scope of the OAuth w= orking group. We standardized the JWT in this group and we are also chartere= d to standardize claims, as we are currently doing with various drafts. Not s= tandardizing JWT in the IETF would have lead to reduced interoperability and= less security. I have no doubts that was a wrong decision. >>>>>>>> >>=20 >>>>>>>> >> In its current form, there is not enough support to have this do= cument as a WG item. >>>>>>>> >>=20 >>>>>>>> >> We believe that the document authors should address some of the e= asier comments and submit a new version. This would allow us to reach out to= those who had expressed concerns about the scope of the document to re-eval= uate their decision. A new draft version should at = least address the following issues: >>>>>>>> >>=20 >>>>>>>> >> * Clarify that this document is not an encouragement for using O= Auth as an authentication protocol. I believe that this would address some o= f the concerns raised by Justin and John. >>>>>>>> >>=20 >>>>>>>> >> * Change the registry policy, which = would address one of the comments from James, William, a= nd Phil. >>>>>>>> >>=20 >>>>>>>> >> Various other items require discussion since they are more diffi= cult to address. For example, John noted that he does not like the use of re= quest parameters. Unfortunately, no alternative is offered. I urge John to p= rovide an alternative proposal, if there is one. Also, the remark that the v= alues are meaningless could be countered with an alternative proposal. James= wanted to remove the "amr_values" parameter. >>>>>>>> >> Is this what others want as well? >>>>>>>> >>=20 >>>>>>>> >> After these items have been addressed we believe that more folks= in the group will support the document. >>>>>>>> >>=20 >>>>>>>> >> Ciao >>>>>>>> >> Hannes & Derek >>>>>>>> >>=20 >>>>>>>> >>=20 >>>>>>>> >>=20 >>>>>>>> >> _______________________________________________ >>>>>>>> >> OAuth mailing list >>>>>>>> >> OAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >=20 >>>>>>>> > _______________________________________________ >>>>>>>> > OAuth mailing list >>>>>>>> > OAuth@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> =E2=80=94 Roland >>>>>>>>=20 >>>>>>>> =E2=80=9DEverybody should be quiet near a little stream and listen.= " >>>>>>>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss= >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-53AA9D07-0964-4ABB-90D3-EA38F0D6F805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Phil,

There are four standard session= ending controls.

1) Logout
2) Idle ses= sion timeout
3) Absolute timeout
4) Forced re-authentication

I think thes= e are still important and tend to not get full attention from the OAuth/OIDC= crowd. :) 

But the OAuth 2 standard in particular is a framework - no= t a standard - which can be implemented many ways, of course.

Aloha,
--
Jim Manico
@Manicode

On Feb 15, 2= 016, at 5:34 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

=
In older systems, time based logout is all you have if you aren't ass= essing risk. 

I would think over time will quickly diminish in its imp= ortance (or as best practice) - at least as the single method for determine a= session should end other than explicit logout. 

Phil

On Feb 15, 2016, at 16:22, Jim Manico &= lt;jim@manicode.com> wrote:
Polite comment, Google in general i= s pretty "open" about session management in general - long idle timeout and n= o apparent absolute timeout. For a bank or other organization that produces h= igh risk software, this is not standard practice. Re-authentication is a cri= tical security boundary, not prompting the user for re-authentication creden= tials is unacceptable in those environments.

I may be jumping in out of con= text, but fair?

--
Jim Manico
@Manicode
+1 (808) 652-3805

On Feb 15, 2016, at 3:36 PM, Wil= liam Denniss <wdenniss@google.com<= /a>> wrote:

=
We return 'amr' claims in ID Tokens if "max_age" is requested (per Open= ID Connect), e.g.:

https://accounts.googl= e.com/o/oauth2/auth?redirect_uri=3Dhttps%3A%2F%2Fdevelopers.google.com%2Foau= thplayground&response_type=3Dcode&client_id=3D407408718192.apps.goog= leusercontent.com&scope=3Dopenid+profile&approval_prompt=3Dforce&= ;access_type=3Doffline&max_age=3D1

The reason= we do this is to be explicit about how we are processing the "max_age" reau= th request, specifically that we don't always prompt the user to reauthentic= ate directly (but do perform in-session risk analysis).

=
I can see us potentially using the more generic amr values like "user",= and "mfa" but we will probably avoid very specific ones like "sms" or "otp"= to avoid brittle relationships with RPs. That said, I don't object to those= being in the registry, perhaps there is value in some tightly coupled enter= prise configurations.


On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt= <torsten@lodderstedt.net> wrote:
=20 =20 =20
Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.


Am 14.02.2016 um 02:40 schrieb William Denniss:


On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:
It's an acceptable fallback option if the working group decides it doesn't want to register the values that are already in production use at the time we establish the registry. But add William points out, Google is already using some of these values. Microsoft is using some of them. The OpenID MODRNA specs are using some of them. So it seems more efficient to register them at the same time.

That would be my preference.

+1, it is also my preference to register the current values.

I don't see any harm in the spec that establishes the registry also seeding it with all known values in use at the time of drafting, regardless of the group that originally specified them. Makes the original spec more useful, and avoids the need to submit each value for consideration separately =E2=80=93 they can be all be reviewed= at the same time. 


From: Justin Richer
Sent: =E2=80=8E2/=E2=80=8E13/=E2=80=8E2016 11:11 AM
To: Phil Hunt

Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns. 

 =E2=80=94 Justin

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

Yes

Phil

On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:

So basically, the RFC could also just establish the new registry and oidf could feel in the values?

(just trying to understand)



-------- Originalnachricht --------
Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Mike Jones <Michael.Jones@microsoft.com> An: torsten@lodderstedt.net,John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org

T= he context that most people on this thread probably don=E2=80=99t= have is that an IANA registry can only be established by an RFC.  Non-RFC specifications,= such as OpenID specifications, can *register* values in a registry, but they cannot *establish* a registry.  The OpenID Foundation inquired about this with the IETF before OpenID Connect was finalized and learned that its specifications could not establish IANA registries.  Otherwise, they would have.=

&= nbsp;

I= nstead, RFCs need to be created to establish registries =E2=80=93 eve= n for values first defined in non-RFC specifications.  This= specification is one example of doing this.

&= nbsp;

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of torsten@lodderstedt.net
Sent: Saturday, February 13, 2016 6:37 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

 

We clearly have this problem between oauth and oidc. Just take a look at the discovery thread.

According to you argument I see two options:
(1) amr stays an oidc claim, is used in oidc only and the oauth wg just publishes the registry entries. In this case, the spec should clearly explain this.
(2) amr is of any use in oauth (although it has been invented in oidc) - than define it and motivate it's use in oauth in this spec.

Right now, I think it creates the impression oauth is for authentication.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: John Bradley <ve7jtb@ve7jtb.com>
An: torsten@lodderstedt.net
Cc: roland.hedberg@umu.se,oauth@ietf.o= rg

This is not a issue between oauth and OIDC.

 

This has to do with the registry for JWT being in OAuth.   Many protocols that use JWT are going to want to register claims.  

We can=E2=80=99= t ask them to all move the parts of there specs that use JWT to OAuth.

 

Perhaps JWT should have been part of JOSE, but that is water under the bridge.  

 

The OAuth WG is responsible for JWT and it=E2=80=99s registry, and we will= need to deal with registering claims.  

 

I guess that we can tell people that they need to publish the specs defining the claims someplace else, and just do the registry part.

However doing that will probably not improve interoperability and understanding.

 

This document defines the claim for JWT in general.  We still hav= e almost no documentation in the WG about what a JWT access token would contain other than the POP work.

 

John B.

On Feb 13, 2016, at 9:18 AM, torsten@lod= derstedt.net wrote:

 

I basically support adoption of this document. Asserting authentication methods in access tokens (in this case in JWTS format) is reasonable. We use it to pass information about the authentication performed prior issuing an access token to the _resource_ server.

What worries me is the back and forth between oauth and oidc. The amr claim is defined in oidc (which sits on top of oauth) but the oauth wg specifies the registry? Moreover, the current text does not give a rationale for using amr in context of oauth.

As a WG we need to find a clear delineation between both protocols, otherwise noone will really understand the difference and when to use what. We create confusion!

For this particular draft this means to either move amr to oauth or the registry to oidc.

best regards,
Torsten.



-------- Urspr=C3=BCngliche Nachricht --------
Von: Roland Hedberg <roland.hedberg@umu.se>
Gesendet: Friday, February 12, 2016 05:45 PM
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

+1

> 12 feb 2016 kl. 16:58 skrev John Bradley <ve7jtb@ve7jtb.com>:
>
> +1 to adopt this draft.
>
>> On Feb 12, 2016, at 3:07 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> Draft -05 incorporates the feedback described below - deleting the request parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for authentication without employing appropriate extensions, and no longer requiring a specification for IANA registration.  I believ= e that it=E2=80=99s now ready f= or working group adoption.
>>
>>   &n= bsp;            =             &nbs= p;            &n= bsp;            =      -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org]= On Behalf Of Hannes Tschofenig
>> Sent: Thursday, February 4, 2016 11:23 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
>>
>> Hi all,
>>
>> On January 19th I posted a call for adoption of the Authentication Method Reference Values specification, see http://www.ietf.org/mail-archive/web/oauth/current/ms= g15402.html
>>
>> What surprised us is that this work is conceptually very simple: we define new claims and create a registry with new values. Not a big deal but that's not what the feedback from the Yokohama IETF meeting and the subsequent call for adoption on the list shows. The feedback lead to mixed feelings and it is a bit difficult for Derek and myself to judge consensus.
>>
>> Let me tell you what we see from the comments on the list.
>>
>> In his review at
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15423.html James Manger asks for significant changes. Among other things, he wants to remove one of the claims. He provides a detailed review and actionable items.
>>
>> William Denniss believes the document is ready for adoption but agrees with some of the comments from James. Here is his review:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15426.html
>>
>> Justin is certainly the reviewer with the strongest opinion. Here is one of his posts:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15457.html
>>
>> Among all concerns Justin expressed the following one is actually actionable IMHO: Justin is worried that reporting how a person authenticated to an authorization endpoint and encouraging people to use OAuth for authentication is a fine line. He believes that this document leads readers to believe the latter.
>>
>> John agrees with Justin in
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15448.html that we need to make sure that people are not mislead about the intention of the document. John also provides additional comments in this post to the
>> list: http://www.ietf.org/mail-archive/web/oauth/current/ms= g15441.html
>> Most of them require more than just editing work. For example, methods listed are really not useful,
>>
>> Phil agrees with the document adoption but has some remarks about the registry although he does not propose specific text. His review is here:
>> = http://www.ietf.org/mail-archive/web/oauth/current/ms= g15462.html
>>
>> With my co-chair hat on: I just wanted to clarify that registering claims (and values within those claims) is within the scope of the OAuth working group. We standardized the JWT in this group and we are also chartered to standardize claims, as we are currently doing with various drafts. Not standardizing JWT in the IETF would have lead to reduced interoperability and less security. I have no doubts that was a wrong decision.
>>
>> In its current form, there is not enough support to have this document as a WG item.
>>
>> We believe that the document authors should address some of the easier comments and submit a new version. This would allow us to reach out to those who had expressed concerns about the scope of the document to re-evaluate their decision. A new draft version should at least address the following issues:
>>
>> * Clarify that this document is not an encouragement for using OAuth as an authentication protocol. I believe that this would address some of the concerns raised by Justin and John.
>>
>> * Change the registry policy, which would address one of the comments from James, William, and Phil.
>>
>> Various other items require discussion since they are more difficult to address. For example, John noted that he does not like the use of request parameters. Unfortunately, no alternative is offered. I urge John to provide an alternative proposal, if there is one. Also, the remark that the values are meaningless could be countered with an alternative proposal. James wanted to remove the "amr_values" parameter.
>> Is this what others want as well?
>>
>> After these items have been addressed we believe that more folks in the group will support the document.
>>
>> Ciao
>> Hannes & Derek
>>
>>
>>
>> ____________________________= ___________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.or= g/mailman/listinfo/oauth
>
> ____________________________= ___________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be= quiet near a little stream and listen."
>=46rom =E2=80=99Open Hou= se for Butterflies=E2=80=99 by Ruth= Krauss


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

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

 

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


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




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


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
= --Apple-Mail-53AA9D07-0964-4ABB-90D3-EA38F0D6F805-- From nobody Tue Feb 16 15:50:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137991AD0AB for ; Tue, 16 Feb 2016 15:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=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 kpwITCTXBNeg for ; Tue, 16 Feb 2016 15:50:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9B31AD068 for ; Tue, 16 Feb 2016 15:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XgOJ6YFpQ1Zlf2Yx+nhOc32hBFItSlYkB18OJTos78E=; b=VbWvncOIICjsil71mAmQ5PuhjOQB5/HWWNXxzBsE9bjeLxf+l7hl/UBqn3sL2Yv7WM7zBBFqhgaqnRRuFQJynQsEz4tpYqPGHhsXpgf4k57J0pTToSCqAHjgmSHBLj0FTsdXZH6m/wjMPv8gkyUwBjYbOqyPBr6ocgZaG15jfJg= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.403.16; Tue, 16 Feb 2016 23:50:08 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.017; Tue, 16 Feb 2016 23:50:08 +0000 From: Anthony Nadalin To: Nat Sakimura , oauth Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt Thread-Index: AQHRaEzy+Urv/eFEWE6v0zAOaJ7fPp8vV24Q Date: Tue, 16 Feb 2016 23:50:08 +0000 Message-ID: References: <20160212094043.13011.44662.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::64b] x-ms-office365-filtering-correlation-id: 611bdcf9-25db-4d14-44ea-08d3372be6d1 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:bothdwLhi0KEdCgwI0Owbxsm0AEV6D2dZnCN+4GCKrbiGyt9BN/LWDYQSnosQ/OgLpo7NsWmyBrpcrxaZTSpIx3KMx0ScqeB4+eoG5XhfDCpMw76IzWLxaVhJgbfth2N02I8gYaT9VPbbticPEBbrg==; 24:EIvBBu1a1G8QH8Bki4t+7t+c/Qqv9uxqw2wTvRgyE7F9fT2n+Y2cHDQkOb8Z/yMtqqME0zwGwim5WBEYtcl6ia6S5BPMkagIM76rzr8N8cs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 0854128AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(2473001)(22974007)(377454003)(377424004)(5002640100001)(92566002)(15975445007)(77096005)(5005710100001)(2950100001)(2900100001)(10400500002)(189998001)(5003600100002)(1220700001)(2906002)(1096002)(5001770100001)(10710500007)(2420400007)(7110500001)(107886002)(586003)(790700001)(5001960100002)(102836003)(6116002)(19300405004)(15650500001)(50986999)(19580395003)(19625215002)(106116001)(76576001)(5004730100002)(14971765001)(33656002)(19617315012)(19609705001)(74316001)(10090500001)(86362001)(10290500002)(230783001)(76176999)(54356999)(11100500001)(87936001)(19580405001)(99286002)(86612001)(40100003)(16236675004)(122556002)(5008740100001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123433D1ED9BF9B1118BC751A6AD0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2016 23:50:08.2311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:50:18 -0000 --_000_BN3PR0301MB123433D1ED9BF9B1118BC751A6AD0BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFsbHkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgc3RlcCBiYWNrd2FyZHMgcmVsYXRpdmUgdG8g dGVjaG5vbG9neSBhbmQgd2hhdCB0aGUgZGV2ZWxvcGVycyB3b3VsZCBhY2NlcHQuIFRoZSBMaW5r IFJlbGF0aW9ucyB0YWtlcyB1cyBiYWNrIHRvIHRoZSBYTUwgZGF5cywgSSB0aG91Z2h0IHdlIGhh dmUgYWxsIG1vdmVkIG9uIGZyb20gdGhhdCBhbmQgYXQgbGVhc3QgdHJ5aW5nIHRvIG1vdmUgT2F1 dGggdG8gSlNPTi4gSSB0aGluayBpZiB0aGlzIHdlcmUgYWRvcHRlZCB3ZSBtaWdodCBiZSBzcGxp dHRpbmcgdGhlIGRldmVsb3BlcnMgaW50byBmb2xrcyB0aGF0IGFyZSBhbHJlYWR5IGdvaW5nIGRv d24gdGhlIGN1cnJlbnQgSlNPTiBwYXRoIHdpdGggT2F1dGggYW5kIHRob3NlIHRoYXQgd2FudCB0 byBnbyBiYWNrIHRvIFhNTC4NCg0KVGhpcyBqdXN0IHNlZW1zIGEgdmVyeSBvZGQgZHJhZnQgdG8g YWRvcHQgdGhpcyB0ZWNobm9sb2d5Lg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYXQgU2FraW11cmENClNlbnQ6IE1vbmRheSwgRmVi cnVhcnkgMTUsIDIwMTYgMzo1OSBQTQ0KVG86IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtPQVVUSC1XR10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNh a2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0DQoNCkl0IG5vdyBzaG93cyBob3cgdG8gcmV0dXJuIG11 bHRpcGxlIGVuZHBvaW50cyBpbiB3ZWIgbGlua2luZy4NCkFsc28sIGFkZGVkIFJlc291cmNlIEVu ZHBvaW50IHJlc3BvbnNlIGhlYWRlci4NCg0KQmVzdCwNCg0KbmF0DQoNCi0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogMjAxNuW5tDLmnIgxMuaX pSjph5EpIDE4OjQwDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0DQpUbzogTm92IE1hdGFrZSA8bm92QG1hdGFrZS5q cDxtYWlsdG86bm92QG1hdGFrZS5qcD4+LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNv bTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4sIFNhc2NoYSBQcmVpYmlzY2ggPFNhc2NoYS5Q cmVpYmlzY2hAZ21haWwuY29tPG1haWx0bzpTYXNjaGEuUHJlaWJpc2NoQGdtYWlsLmNvbT4+LCBT YXNjaGEgUHJlaWJpc2NoIDxzYXNjaGEucHJlaWJpc2NoQGdtYWlsLmNvbTxtYWlsdG86c2FzY2hh LnByZWliaXNjaEBnbWFpbC5jb20+Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IE5hdCBTYWtpbXVyYSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOiAgICAgICAgICAgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YQ0KUmV2aXNpb246ICAg ICAgIDA3DQpUaXRsZTogICAgICAgICAgT0F1dGggUmVzcG9uc2UgTWV0YWRhdGENCkRvY3VtZW50 IGRhdGU6ICAyMDE2LTAyLTEyDQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczogICAgICAgICAgMTANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNy50eHQ8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl MmZ3d3cuaWV0Zi5vcmclMmZpbnRlcm5ldC1kcmFmdHMlMmZkcmFmdC1zYWtpbXVyYS1vYXV0aC1t ZXRhLTA3LnR4dCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzNhOTky ZDVmZjRhMjQyODgwNGYyMDhkMzM2NjQxMjkyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJnNkYXRhPTZNMTBROVg0Y3ElMmIlMmZScm9SJTJmSFlROUlOM1AxSE8wNkpuYnV6 WTZQM29XdGMlM2Q+DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZkYXRhdHJhY2tlci5pZXRm Lm9yZyUyZmRvYyUyZmRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGElMmYmZGF0YT0wMSU3YzAxJTdj dG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzYTk5MmQ1ZmY0YTI0Mjg4MDRmMjA4ZDMzNjY0MTI5 MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT03dHdFTTBGenRT YXN3dEZpWXNsdkp1YWRUeVdiV1JTRFdRNnVUJTJiZXZLd00lM2Q+DQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDc8 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRh LTA3JmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjM2E5OTJkNWZmNGEy NDI4ODA0ZjIwOGQzMzY2NDEyOTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmc2RhdGE9a2gybkg0SXlObTNPQUE1bmtyU0Z6Wk4xNlhpYyUyYjJFRFVPZnIlMmZHNkNqVlkl M2Q+DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDc8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZyZmNkaWZm JTNmdXJsMiUzZGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcmZGF0YT0wMSU3YzAxJTdjdG9u eW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzYTk5MmQ1ZmY0YTI0Mjg4MDRmMjA4ZDMzNjY0MTI5MiU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1JQ3RrNVUxZTZrQlBG SThvdjBuMDZUQWNxRFgzSHVyZ0ZUeWRYS0Q3M1lvJTNkPg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg c3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuIGV4dGVuc2libGUgbWV0YWRhdGEgdGhhdCBtYXkgYmUN CiAgIGluc2VydGVkIGludG8gdGhlIE9BdXRoIDIuMCByZXNwb25zZXMgdG8gYXNzaXN0IHRoZSBj bGllbnRzIHRvDQogICBwcm9jZXNzIHRob3NlIHJlc3BvbnNlcy4gIEl0IGlzIGV4cHJlc3NlZCBl aXRoZXIgYXMgYSBsaW5rIGhlYWRlciwgb3INCiAgIHF1ZXJ5IHBhcmFtZXRlcnMuICBJdCB3aWxs IGFsbG93IHRoZSBjbGllbnQgdG8gbGVhcm4gd2hlcmUgdGhlDQogICBtZW1iZXJzIGluIHRoZSBy ZXNwb25zZSBjb3VsZCBiZSB1c2VkLCB3aGF0IGlzIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YNCiAg IHRoZSBwYXlsb2FkIGlzLCBob3cgaXQgc2hvdWxkIGJlIHByb2Nlc3NlZCwgYW5kIHNvIG9uLiAg U2luY2UgdGhleQ0KICAgYXJlIGp1c3QgYWRkaXRpb25hbCByZXNwb25zZSBoZWFkZXIvcXVlcnkg cGFyYW1ldGVycywgYW55IGNsaWVudCB0aGF0DQogICBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoaXMg ZXh0ZW5zaW9uIHNob3VsZCBub3QgYnJlYWsgYW5kIHdvcmsgbm9ybWFsbHkNCiAgIHdoaWxlIHN1 cHBvcnRpbmcgY2xpZW50cyBjYW4gdXRpbGl6ZSB0aGUgbWV0YWRhdGEgdG8gdGFrZSB0aGUNCiAg IGFkdmFudGFnZSBvZiB0aGUgZXh0ZW5zaW9uLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHAlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyZkYXRhPTAxJTdjMDElN2N0b255bmFk JTQwbWljcm9zb2Z0LmNvbSU3YzNhOTkyZDVmZjRhMjQyODgwNGYyMDhkMzM2NjQxMjkyJTdjNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWFpakM2ckFuMDFuMDRtRHlC NWxwVjd0UWl0eEl5ZjBkcmRoZWxlUjk1NUElM2Q+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K --_000_BN3PR0301MB123433D1ED9BF9B1118BC751A6AD0BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3Nl LTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN YWxndW4gR290aGljIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHJlYWxseSB0aGlu ayB0aGF0IHRoaXMgaXMgYSBzdGVwIGJhY2t3YXJkcyByZWxhdGl2ZSB0byB0ZWNobm9sb2d5IGFu ZCB3aGF0IHRoZSBkZXZlbG9wZXJzIHdvdWxkIGFjY2VwdC4gVGhlIExpbmsgUmVsYXRpb25zIHRh a2VzIHVzIGJhY2sgdG8gdGhlIFhNTCBkYXlzLCBJDQogdGhvdWdodCB3ZSBoYXZlIGFsbCBtb3Zl ZCBvbiBmcm9tIHRoYXQgYW5kIGF0IGxlYXN0IHRyeWluZyB0byBtb3ZlIE9hdXRoIHRvIEpTT04u IEkgdGhpbmsgaWYgdGhpcyB3ZXJlIGFkb3B0ZWQgd2UgbWlnaHQgYmUgc3BsaXR0aW5nIHRoZSBk ZXZlbG9wZXJzIGludG8gZm9sa3MgdGhhdCBhcmUgYWxyZWFkeSBnb2luZyBkb3duIHRoZSBjdXJy ZW50IEpTT04gcGF0aCB3aXRoIE9hdXRoIGFuZCB0aG9zZSB0aGF0IHdhbnQgdG8gZ28gYmFjayB0 byBYTUwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGp1 c3Qgc2VlbXMgYSB2ZXJ5IG9kZCBkcmFmdCB0byBhZG9wdCB0aGlzIHRlY2hub2xvZ3kuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5hdCBTYWtpbXVyYTxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDE1LCAyMDE2IDM6NTkgUE08YnI+DQo8Yj5Ubzo8L2I+IG9h dXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdH XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2FraW11cmEtb2F1dGgt bWV0YS0wNy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBub3cg c2hvd3MgaG93IHRvIHJldHVybiBtdWx0aXBsZSBlbmRwb2ludHMgaW4gd2ViIGxpbmtpbmcuJm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYWRk ZWQgUmVzb3VyY2UgRW5kcG9pbnQgcmVzcG9uc2UgaGVhZGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5uYXQ8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8 YnI+DQpEYXRlOiAyMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3Ro aWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MTI8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m l6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1 b3Q7LHNhbnMtc2VyaWYiPumHkTwvc3Bhbj4pDQogMTg6NDA8YnI+DQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0PGJy Pg0KVG86IE5vdiBNYXRha2UgJmx0OzxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIj5ub3ZA bWF0YWtlLmpwPC9hPiZndDssIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2lt dXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDssIFNhc2NoYSBQcmVpYmlz Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzpTYXNjaGEuUHJlaWJpc2NoQGdtYWlsLmNvbSI+U2FzY2hh LlByZWliaXNjaEBnbWFpbC5jb208L2E+Jmd0OywgU2FzY2hhIFByZWliaXNjaCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNhc2NoYS5wcmVpYmlzY2hAZ21haWwuY29tIj5zYXNjaGEucHJlaWJpc2NoQGdt YWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0PGJyPg0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOYXQgU2FraW11cmEgYW5kIHBvc3RlZCB0 byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGE8YnI+ DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswNzxicj4NClRpdGxlOiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT0F1dGggUmVzcG9uc2UgTWV0YWRhdGE8YnI+ DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE2LTAyLTEyPGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDEwPGJyPg0KVVJMOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYu b3JnJTJmaW50ZXJuZXQtZHJhZnRzJTJmZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNy50eHQm YW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjM2E5OTJkNWZmNGEy NDI4ODA0ZjIwOGQzMzY2NDEyOTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmYW1wO3NkYXRhPTZNMTBROVg0Y3ElMmIlMmZScm9SJTJmSFlROUlOM1AxSE8wNkpuYnV6WTZQ M29XdGMlM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3LnR4dDwvYT48YnI+DQpTdGF0dXM6 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGF0YXRy YWNrZXIuaWV0Zi5vcmclMmZkb2MlMmZkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJTJmJmFtcDtk YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzNhOTkyZDVmZjRhMjQyODgw NGYyMDhkMzM2NjQxMjkyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFt cDtzZGF0YT03dHdFTTBGenRTYXN3dEZpWXNsdkp1YWRUeVdiV1JTRFdRNnVUJTJiZXZLd00lM2Qi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1z YWtpbXVyYS1vYXV0aC1tZXRhLzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LXNh a2ltdXJhLW9hdXRoLW1ldGEtMDcmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv ZnQuY29tJTdjM2E5OTJkNWZmNGEyNDI4ODA0ZjIwOGQzMzY2NDEyOTIlN2M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWtoMm5INEl5Tm0zT0FBNW5rclNGelpO MTZYaWMlMmIyRURVT2ZyJTJmRzZDalZZJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDc8L2E+PGJyPg0KRGlm ZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm JTJmd3d3LmlldGYub3JnJTJmcmZjZGlmZiUzZnVybDIlM2RkcmFmdC1zYWtpbXVyYS1vYXV0aC1t ZXRhLTA3JmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzNhOTky ZDVmZjRhMjQyODgwNGYyMDhkMzM2NjQxMjkyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN2MxJmFtcDtzZGF0YT1JQ3RrNVUxZTZrQlBGSThvdjBuMDZUQWNxRFgzSHVyZ0ZUeWRY S0Q3M1lvJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDc8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6 PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuIGV4dGVuc2li bGUgbWV0YWRhdGEgdGhhdCBtYXkgYmU8YnI+DQombmJzcDsgJm5ic3A7aW5zZXJ0ZWQgaW50byB0 aGUgT0F1dGggMi4wIHJlc3BvbnNlcyB0byBhc3Npc3QgdGhlIGNsaWVudHMgdG88YnI+DQombmJz cDsgJm5ic3A7cHJvY2VzcyB0aG9zZSByZXNwb25zZXMuJm5ic3A7IEl0IGlzIGV4cHJlc3NlZCBl aXRoZXIgYXMgYSBsaW5rIGhlYWRlciwgb3I8YnI+DQombmJzcDsgJm5ic3A7cXVlcnkgcGFyYW1l dGVycy4mbmJzcDsgSXQgd2lsbCBhbGxvdyB0aGUgY2xpZW50IHRvIGxlYXJuIHdoZXJlIHRoZTxi cj4NCiZuYnNwOyAmbmJzcDttZW1iZXJzIGluIHRoZSByZXNwb25zZSBjb3VsZCBiZSB1c2VkLCB3 aGF0IGlzIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2Y8YnI+DQombmJzcDsgJm5ic3A7dGhlIHBheWxv YWQgaXMsIGhvdyBpdCBzaG91bGQgYmUgcHJvY2Vzc2VkLCBhbmQgc28gb24uJm5ic3A7IFNpbmNl IHRoZXk8YnI+DQombmJzcDsgJm5ic3A7YXJlIGp1c3QgYWRkaXRpb25hbCByZXNwb25zZSBoZWFk ZXIvcXVlcnkgcGFyYW1ldGVycywgYW55IGNsaWVudCB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwO2Rv ZXMgbm90IHVuZGVyc3RhbmQgdGhpcyBleHRlbnNpb24gc2hvdWxkIG5vdCBicmVhayBhbmQgd29y ayBub3JtYWxseTxicj4NCiZuYnNwOyAmbmJzcDt3aGlsZSBzdXBwb3J0aW5nIGNsaWVudHMgY2Fu IHV0aWxpemUgdGhlIG1ldGFkYXRhIHRvIHRha2UgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2FkdmFu dGFnZSBvZiB0aGUgZXh0ZW5zaW9uLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyZhbXA7ZGF0YT0w MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzYTk5MmQ1ZmY0YTI0Mjg4MDRmMjA4 ZDMzNjY0MTI5MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2Rh dGE9YWlqQzZyQW4wMW4wNG1EeUI1bHBWN3RRaXR4SXlmMGRyZGhlbGVSOTU1QSUzZCIgdGFyZ2V0 PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3Jl dGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB123433D1ED9BF9B1118BC751A6AD0BN3PR0301MB1234_-- From nobody Tue Feb 16 16:55:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90391B2C49 for ; Tue, 16 Feb 2016 16:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=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 6i1jtQrKqhHH for ; Tue, 16 Feb 2016 16:55:17 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CB91B2C47 for ; Tue, 16 Feb 2016 16:55:17 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id s5so572233qkd.0 for ; Tue, 16 Feb 2016 16:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=JNYoPKHqhA3YZBAMVLp1QzL0pScVmhhtKGX9dNbZML8=; b=DyooUwJR7DAyOyQLgFAoB2CfxPbcVaxbV0LE0u/RpDBjVsGBVJGJzB3IF5LOylpjbr y04VGB7tO5YDPJWE3ibfwvP4OvW6yZKl4e68X/CkaAOReLH9aI5EFfzqlfeSIaYbMvh5 l/WspUv3YXmEjCgdyobUwZBKuQ21EGSdXHSgBuBaLsDZ1y7JUECcsNrCX8gn8zl6SvVQ fK6T4N2Ly5BsuZno8wQGhUe3ym5KVEzQnswqjYd8LjR/zT/aI8ko/aDgpgn5gxkhXYXE ilZ6RYXam8RzQOLkJua64/OlsCLjIM7MkJjV2zVBK+e6pJYXSlzxnEMufTEiQopXd4hA 94Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=JNYoPKHqhA3YZBAMVLp1QzL0pScVmhhtKGX9dNbZML8=; b=c3GMozZIK8XXL7q3YWA46A+gPQCRpi3/vMiTMQ4RDU2JhvJ03cwU4f+1jdaXtkAIZh ArjjJbAsfZrgTV9ws6xNATViVKboY+3jvK1OJ5p6FnTvS4hF4kckO7BSRccu9bgdOTtG QMbl+PzsWGe9Nh/Txlcmh31sV1Tfb94zkOgSLFEqDBv8x5zlms9i8RwJcIbIfpEG8o8P RHLzI5U1ck41OWyjIXUwvyj8ZVMoPMODeuvIH1QaQCz+HY9fjUNgwtgwIA5LMrcacbAV zROdGQECtdJk8J2+sa8bSiTGfkBrJOQ93HwU9x3KgH6LwgdXjsG7QvgkH8pQKZ4u8FQP wfrA== X-Gm-Message-State: AG10YOSvXHT6EaVEX970g1zKz0G5QizicI7wzK1Cr5i5Xj8w4kRcW2N2sK8U2MnpSOC5kgGsihoOSd6wlD+E4g== X-Received: by 10.55.71.135 with SMTP id u129mr31711273qka.26.1455670516486; Tue, 16 Feb 2016 16:55:16 -0800 (PST) MIME-Version: 1.0 References: <20160212094043.13011.44662.idtracker@ietfa.amsl.com> In-Reply-To: From: Nat Sakimura Date: Wed, 17 Feb 2016 00:55:05 +0000 Message-ID: To: Anthony Nadalin , oauth Content-Type: multipart/alternative; boundary=001a114a7d200b988a052becb42c Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 00:55:19 -0000 --001a114a7d200b988a052becb42c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Link relation is not at all XML. It is a step forward to RESTfulness. In the older version of the draft, I was using JSONized version of it as well, but I splitted it out for the sake of brevity. It is all about dynamic metadata about the response. Once we do it with RFC5988, we could easily create a parallel to it with JSON meta object of your flavour. (Currently, JSON schema seems to be in fashion, though I personally prefer HAL.) Good things about using JSONized version is that it will be usable outside the HTTP and the fact that it can be stored in a single JSON object together with the data. Bad thing about it is that we have to start from the syntax for it, which we can avoid by using RFC5988. If people want the JSON version of this, I could do it as well. However, since we are processing HTTP response headers anyways, there is not much compelling reason for that as long as we stick with HTTP. That's why I am just sticking with RFC5988. Nat. 2016=E5=B9=B42=E6=9C=8817=E6=97=A5(=E6=B0=B4) 8:50 Anthony Nadalin : > I really think that this is a step backwards relative to technology and > what the developers would accept. The Link Relations takes us back to the > XML days, I thought we have all moved on from that and at least trying to > move Oauth to JSON. I think if this were adopted we might be splitting th= e > developers into folks that are already going down the current JSON path > with Oauth and those that want to go back to XML. > > > > This just seems a very odd draft to adopt this technology. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakimura > *Sent:* Monday, February 15, 2016 3:59 PM > *To:* oauth > *Subject:* [OAUTH-WG] Fwd: New Version Notification for > draft-sakimura-oauth-meta-07.txt > > > > It now shows how to return multiple endpoints in web linking. > > Also, added Resource Endpoint response header. > > > > Best, > > > > nat > > > > ---------- Forwarded message --------- > From: > Date: 2016=E5=B9=B42=E6=9C=8812=E6=97=A5(=E9=87=91) 18:40 > Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt > To: Nov Matake , Nat Sakimura , Sascha > Preibisch , Sascha Preibisch < > sascha.preibisch@gmail.com> > > > > > A new version of I-D, draft-sakimura-oauth-meta-07.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Name: draft-sakimura-oauth-meta > Revision: 07 > Title: OAuth Response Metadata > Document date: 2016-02-12 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt > > Status: > https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/ > > Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-meta-07 > > > Abstract: > This specification defines an extensible metadata that may be > inserted into the OAuth 2.0 responses to assist the clients to > process those responses. It is expressed either as a link header, or > query parameters. It will allow the client to learn where the > members in the response could be used, what is the characteristics of > the payload is, how it should be processed, and so on. Since they > are just additional response header/query parameters, any client that > does not understand this extension should not break and work normally > while supporting clients can utilize the metadata to take the > advantage of the extension. > > > > > 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 > --001a114a7d200b988a052becb42c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Link relation is not at all XML. It is a step forward to R= ESTfulness.=C2=A0
In the older version of the draft, I was using JSONiz= ed version of it as well, but I splitted it out for the sake of brevity.=C2= =A0
It is all about dynamic metadata about the response.=C2=A0
Once we do it with RFC5988, we could easily create a parallel to it= with JSON meta object of your flavour.=C2=A0
(Currently, JSON sc= hema seems to be in fashion, though I personally prefer HAL.)=C2=A0
Good things about using JSONized version is that it will be usable outsi= de the HTTP and the fact that it can be stored in a single JSON object toge= ther with the data.=C2=A0
Bad thing about it is that we have to s= tart from the syntax for it, which we can avoid by using RFC5988.=C2=A0
If people want the JSON version of this, I could do it as well.=C2= =A0
However, since we are processing HTTP response headers anyway= s, there is not much compelling reason for that as long as we stick with HT= TP.=C2=A0
That's why I am just sticking with RFC5988.=C2=A0

Nat.=C2=A0


2016=E5=B9=B42=E6=9C=8817=E6=97=A5(=E6=B0= =B4) 8:50 Anthony Nadalin <tony= nad@microsoft.com>:

I really think that this is a step ba= ckwards relative to technology and what the developers would accept. The Li= nk Relations takes us back to the XML days, I thought we have all moved on from that and at least trying to move Oauth t= o JSON. I think if this were adopted we might be splitting the developers i= nto folks that are already going down the current JSON path with Oauth and = those that want to go back to XML.

=C2=A0

This just seems a very odd draft to a= dopt this technology.

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura= -oauth-meta-07.txt

=C2=A0

It now shows how to return multiple endpoints in web= linking.=C2=A0

Also, added Resource Endpoint response header.=C2=A0=

=C2=A0

Best,=C2=A0

=C2=A0

nat

=C2=A0

---------- Forwarded message ---------
From: <int= ernet-drafts@ietf.org>
Date: 2016= =E5=B9=B42=E6=9C=8812=E6=97=A5(=E9=87=91) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake <nov@m= atake.jp>, Nat Sakimura <sakimura@gmail.com>, Sascha Preibisch <Sascha.Preibisch@gmai= l.com>, Sascha Preibisch <sascha.preibisch@gmail.com>




A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sakimura-oauth-meta
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A007
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth Response Metadata
Document date:=C2=A0 2016-02-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-sakimura-oauth-meta-07
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-meta-07=

Abstract:
=C2=A0 =C2=A0This specification defines an extensible metadata that may be<= br> =C2=A0 =C2=A0inserted into the OAuth 2.0 responses to assist the clients to=
=C2=A0 =C2=A0process those responses.=C2=A0 It is expressed either as a lin= k header, or
=C2=A0 =C2=A0query parameters.=C2=A0 It will allow the client to learn wher= e the
=C2=A0 =C2=A0members in the response could be used, what is the characteris= tics of
=C2=A0 =C2=A0the payload is, how it should be processed, and so on.=C2=A0 S= ince they
=C2=A0 =C2=A0are just additional response header/query parameters, any clie= nt that
=C2=A0 =C2=A0does not understand this extension should not break and work n= ormally
=C2=A0 =C2=A0while supporting clients can utilize the metadata to take the<= br> =C2=A0 =C2=A0advantage of the extension.




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

--001a114a7d200b988a052becb42c-- From nobody Wed Feb 17 22:45:43 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9901B36B2; Wed, 17 Feb 2016 22:45:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218064540.18410.23600.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 22:45:40 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 06:45:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Discovery Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-01.txt Pages : 21 Date : 2016-02-17 Abstract: This specification defines a discovery metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 17 22:48:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CFD1B3700 for ; Wed, 17 Feb 2016 22:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJcVfwzf9Ry5 for ; Wed, 17 Feb 2016 22:48:25 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B031B36FC for ; Wed, 17 Feb 2016 22:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=47AgaeOeGzz3JFlpHmggkBe6E2LZT+MBZgI6MB9HsfY=; b=i7Jv9gLlxe7alwexEM3hCWj9YTcgiuATUIuiBnFm7+7ZBts2j5RrMjMxYsfjmzeXhxkbCJ+bpoIqmZakl7o4g4rEmX+1ak5DxOoKhvBmnZ/05pv6OVS9Y5B8kS7BsKNWMohkWWFtirMNsFHN1yrlatcA6Fy90bHqqf8eVtjQQ2k= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 06:48:22 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 06:48:22 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSA== Date: Thu, 18 Feb 2016 06:48:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 9d276bec-2340-4107-ae08-08d3382f7e9d x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:kHd/AcP3u3QuyNuyHOt9lDlpy+Q0tkHnIzlbapjdJMnlIjrfFixurQwfnv/W6dYdOZMgAThm5dX35I3pnc/QeNjWzs4NYun7SuyqkOK6frCOfngngT2ALg4iQ2ekiuv7DL6tmBG858Eed1PEqb2L4Q==; 24:O5/Kl2IWyahjXqdNqz4unvDBPa9w3nLZVf97Q4MtKbTveFh61P5fukMmydYDT6TkVsUNCDx/HV0+BwBvgt4H/wDemSbwyAAyWT7mponH+cQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(5008740100001)(15975445007)(33656002)(1096002)(19580395003)(5003600100002)(11100500001)(74316001)(229853001)(3280700002)(2351001)(450100001)(66066001)(1220700001)(5002640100001)(87936001)(54356999)(6116002)(1730700002)(189998001)(790700001)(40100003)(5001960100002)(122556002)(10090500001)(107886002)(8990500004)(5005710100001)(10400500002)(102836003)(16236675004)(3846002)(19300405004)(92566002)(99286002)(5004730100002)(19617315012)(3660700001)(19625215002)(76576001)(110136002)(10290500002)(586003)(2900100001)(77096005)(50986999)(2906002)(2501003)(86362001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44236EF33376F8C2BB135E8F5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 06:48:22.3565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 06:48:29 -0000 --_000_BY2PR03MB44236EF33376F8C2BB135E8F5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In response to working group input, this version of the OAuth Discovery spe= cification has been pared down to its essence - leaving only the features t= hat are already widely deployed. Specifically, all that remains is the def= inition of the authorization server discovery metadata document and the met= adata values used in it. The WebFinger discovery logic has been removed. = The relationship between the issuer identifier URL and the well-known URI p= ath relative to it at which the discovery metadata document is located has = also been clarified. Given that this now describes only features that are in widespread deployme= nt, the editors believe that this version is ready for working group last c= all. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html -- Mike & Nat & J= ohn P.S. This notice was also posted at http://self-issued.info/?p=3D1544 and = as @selfissued. --_000_BY2PR03MB44236EF33376F8C2BB135E8F5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In response to working group input, this version of = the OAuth Discovery specification has been pared down to its essence –= ; leaving only the features that are already widely deployed.  Specifi= cally, all that remains is the definition of the authorization server discovery metadata document and the metadata valu= es used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known URI p= ath relative to it at which the discovery metadata document is located has also been clarified.

 

Given that this now describes only features that are= in widespread deployment, the editors believe that this version is ready f= or working group last call.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-iet= f-oauth-discovery-01

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/= draft-ietf-oauth-discovery-01.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike &= amp; Nat & John

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.

--_000_BY2PR03MB44236EF33376F8C2BB135E8F5AF0BY2PR03MB442namprd_-- From nobody Wed Feb 17 23:38:04 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 533261B3121; Wed, 17 Feb 2016 23:38:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218073801.25090.54788.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 23:38:01 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 07:38:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Device Flow Authors : William Denniss Stein Myrseth John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-00.txt Pages : 8 Date : 2016-02-17 Abstract: The device flow is suitable for OAuth 2.0 clients executing on devices which do not have an easy data-entry method (e.g., game consoles, TVs, picture frames, and media hubs), but where the end- user has separate access to a user-agent on another computer or device (e.g., desktop computer, a laptop, a smart phone, or a tablet). Note: This version of the document is a continuation of an earlier, long expired draft. The content of the expired draft has been copied almost unmodified. The goal of the work on this document is to capture deployment experience. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 18 00:35:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524E81B3A80 for ; Thu, 18 Feb 2016 00:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMAGSPVg4zy9 for ; Thu, 18 Feb 2016 00:35:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE1E1B39FE for ; Thu, 18 Feb 2016 00:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HIUvNPhA4m55ePNAI37pHsF+6FY25GaZ6YVznN6J7w8=; b=iO61rbGzscLGMEP8OhWsNOPUX/KOA0QsyAZby4P/pxliuaBG1Viioy4jD/XcK/1qFdC4Gz5xS7Ao8ApJGPx//RrjsR/qIFNBfpGDgHbPu1Pl40cLDBNyuaBXGDtNNaBgi0c8LZrljQrF9CPkp4ThV160/tLHrskcgfqedTf5Vlg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 08:34:54 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 08:34:54 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Initial OAuth working group Device Flow specification Thread-Index: AdFqJWJ6MePOVJvyQJOSI0sxEV1zpw== Date: Thu, 18 Feb 2016 08:34:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 2f1e2974-93bc-48b8-09e8-08d3383e603d x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:C4bHJHOFWjF7Qr4yyy/4YObjeAYOk/VQ64h4ZrnAeITZ7VaOjnWKfJL6w4RdTNi9iNTyQsjtyhLnHZB2jWEnoIrJBa0DIZkZmX1KvJXaKMYip+WmNheKvMa19IiaWKkxM4s0QL/sqOFM25Fy1d+sCg==; 24:lG3GU5SzfkWf1H0+J8tpqsg5HP/RF7CJAShidgzkstTc7kgbyZOLzTcWpNli5JNyrrViAOGd6GOHegy1Z9FBwt/MWND348vm+Aylrx2D5gM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(99286002)(19625215002)(11100500001)(16236675004)(5003600100002)(1730700002)(5004730100002)(50986999)(5005710100001)(5008740100001)(19300405004)(2906002)(10090500001)(33656002)(40100003)(450100001)(10290500002)(5002640100001)(10400500002)(76576001)(3280700002)(74316001)(1096002)(87936001)(2900100001)(3660700001)(15975445007)(77096005)(586003)(229853001)(1220700001)(2351001)(5001960100002)(2501003)(86362001)(19617315012)(3846002)(790700001)(110136002)(92566002)(102836003)(107886002)(189998001)(19580395003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A0B5B7BDCE7100215714F5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 08:34:54.0925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] Initial OAuth working group Device Flow specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 08:35:19 -0000 --_000_BY2PR03MB442A0B5B7BDCE7100215714F5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to William Denniss for creating the initial working group version of= the OAuth 2.0 Device Flow specification. The abstract of the specificatio= n is: The device flow is suitable for OAuth 2.0 clients executing on devices whic= h do not have an easy data-entry method (e.g., game consoles, TVs, picture = frames, and media hubs), but where the end-user has separate access to a us= er-agent on another computer or device (e.g., desktop computer, a laptop, a= smart phone, or a tablet). Note: This version of the document is a continuation of an earlier, long ex= pired draft. The content of the expired draft has been copied almost unmod= ified. The goal of the work on this document is to capture deployment expe= rience. If you're using an OAuth device flow, please let us know whether this speci= fication matches your usage, and if not, how yours differs. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-device-flow-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-device-flow-00.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1546 and = as @selfissued. --_000_BY2PR03MB442A0B5B7BDCE7100215714F5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to William Denniss for creating the initial w= orking group version of the OAuth 2.0 Device Flow specification.  The = abstract of the specification is:

 

The device flow is suitab= le for OAuth 2.0 clients executing on devices which do not have an easy dat= a-entry method (e.g., game consoles, TVs, picture frames, and media hubs), = but where the end-user has separate access to a user-agent on another computer or device (e.g., desktop comput= er, a laptop, a smart phone, or a tablet).

 

Note: This version of the= document is a continuation of an earlier, long expired draft.  The co= ntent of the expired draft has been copied almost unmodified.  The goa= l of the work on this document is to capture deployment experience.

 

If you’re using an OAuth device flow, please l= et us know whether this specification matches your usage, and if not, how y= ours differs.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-devi= ce-flow-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft-ietf-o= auth-device-flow-00.html

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1546 and as @selfissued.

--_000_BY2PR03MB442A0B5B7BDCE7100215714F5AF0BY2PR03MB442namprd_-- From nobody Thu Feb 18 05:09:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6E1A1EFD for ; Thu, 18 Feb 2016 05:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZcBqhGisEPM for ; Thu, 18 Feb 2016 05:09:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA4F1A1EF6 for ; Thu, 18 Feb 2016 05:09:00 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LlqNY-1Zx3Zh1YnY-00ZM7P for ; Thu, 18 Feb 2016 14:08:57 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56C5C273.30406@gmx.net> Date: Thu, 18 Feb 2016 14:09:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BBdFCB3Kr4rhH9nLTPpkKbo3UBPFu0x5K" X-Provags-ID: V03:K0:zUToVodNp7MRJ4qEw4dfbkPywcC+HHIZ9+y0AkfMT2Sg0p3LsMS /rQAMNzj8/Q2CagSdOI07i9y07Y0Js/SBubcDRQoPwtYC087aMIQZ0dVRvvJhULoTi4QKWf dLBgdLAeDCva0Iw0dxsEpQlniZr9hoXJWD0TYU7yRX10dPlILu/32tuvec1Dy3OmUPlEZvb q3WyH6KIkhVZRq9olCYWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:01CjVhK9PNI=:d3tYS9ssXLbVHtCddzEeok 8LWkRI9dvUW/XDydaAckdz63PPF1oPf9QTimBi2/Yg3FHAE6ox5naqp+MGWNY09aTG9IJv4Xi 5dG7mJsj7HU9ixbTiXb7AbYC6uLBuRLbxknmgopR9VU0Wfu7ncYa5wty3eAXj5XSBxL2vwyqH CtORdtUMJsITni4j6BZsSPcpTR1JZ/0cLKzmb/9w61JABByo8qKtFJtKT7LcU17a2N4W0Qer5 culPnHyumbk2l9HRmSxcd6BDqZ2NL2uGBVO3GCgSVlUGbCIMFtRPpa6cbxdRRpLpTOZkb+its /h3/pEqw2WuwQpIpHWDbBo0dI7JypjCWTonOhKEiXl+TnAURd6LN1VfNgrvtVeZGqQ6vMVzU6 1obb1UvKdRxuZaQDBkeEXuEKPuRfLkdWVXB/jsjUahVL6bnWgXi3i1NHkeTIPNOcmfv5YQbsh 5135UYl4qnbKdmzi9uTOC2+8VrVTw0DUPOhp/KIsm9+EnQVqZYoripYwd/vSSUY7wEPBvNsBs kCoPh4+D9IMb6Mf+7IpWcfk2x1GoPPGAni6Q7PWnpq8PMz2pky5MiiQQcWLnglCnefMw4ZejR QQPuK1J/Nza/o1B/5McXxE2pJ2R/VnC7aHXygR49ZQIn0lY555NS46sH6lJOmxVqUdRUXf1lh +rCdPKswVFBJIhQMnHt0PHFl85KD6Gjlhuw23gH5nza9akIBkPFLITfJZBvfafs4rjxv0o4Yh lnb2qVr2aSIQ47ZK/bzlmuMJ7OqPU4YBWL79PRQ9oXJqb722Evf7oCj9iNU= Archived-At: Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 13:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BBdFCB3Kr4rhH9nLTPpkKbo3UBPFu0x5K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In response to my message to the list regarding the initial call for adoption of the Authentication Method Reference Values draft, see https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike submitted an updated version of the document to take raised concerns into account. Several working group participants responded positively to the new version. We would therefore like to issue a 2nd call for adoption of the recently submitted version -05: https://tools.ietf.org/html/draft-jones-oauth-amr-values-05 Please let us know by March 3rd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Derek --BBdFCB3Kr4rhH9nLTPpkKbo3UBPFu0x5K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWxcJzAAoJEGhJURNOOiAt4x8H/0xaEQEbJkHr2l044yWFz0ku 9kvUqbSK/xU2sPa/47UDID5fYrlnk77dObZsIR+5/RMIwlz1BMarfYhMIyZ0Sl02 0FpFkfQwDiI2Qcyb2shB5W4334KEvYzMafC1ul8sMOf4ckL9yPdWrnf2BFv/tGcX E5NcbGAGr2ycu64ggdle8vYdlDI7tWu0foUZVAvrp84mdQJAc1x25RYW/LPMI+Du fQzK07VxxOGLXBPmsrxROiQqUvBERdy8vOk3rPT4xLBp6kzot0asC8IdfIv0o+SO mFmbMnnHQOIovOaV9rnQhJWueqQqIVmsikHQB9hp908jQaz0xiCum4vfqQ/VMBI= =x67Y -----END PGP SIGNATURE----- --BBdFCB3Kr4rhH9nLTPpkKbo3UBPFu0x5K-- From nobody Thu Feb 18 05:35:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2C1A8A12 for ; Thu, 18 Feb 2016 05:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oCZAQGm9PVQ for ; Thu, 18 Feb 2016 05:35:32 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD2A1A8998 for ; Thu, 18 Feb 2016 05:35:31 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1IDZV4A002549 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Feb 2016 13:35:31 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1IDZUs8002510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Feb 2016 13:35:30 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1IDZUAt012511; Thu, 18 Feb 2016 13:35:30 GMT Received: from [10.5.50.249] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 05:35:29 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_BBC28EB5-C417-4DA4-8727-370974085868" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Thu, 18 Feb 2016 06:35:28 -0700 Message-Id: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> References: To: Mike Jones X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 13:35:34 -0000 --Apple-Mail=_BBC28EB5-C417-4DA4-8727-370974085868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I still find the following text objectionable and confusing=E2=80=A6 By default, for historical reasons, unless an application-specific well-known URI path suffix is registered and used for an application, the client for that application SHOULD use the well-known URI path suffix "openid-configuration" and publish the metadata document at the path formed by concatenating "/.well-known/openid-configuration" to the authorization server's issuer identifier. As described in Section 5 = , = despite the identifier "/.well-known/openid-configuration", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect. Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). GET /.well-known/openid-configuration and GET /.well-known/scim Retrieve the OAuth configuration for the application openid and scim = respectively. The use of: GET /.well-known/oauth2/ Should be the default used when there is no known application based = well-known application based URI discovery. Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? It seemed better to me to use the webfinger syntax to allow the client = to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 17, 2016, at 11:48 PM, Mike Jones = wrote: >=20 > In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. > =20 > Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. > =20 > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = > =20 > An HTML-formatted version is also available at: > =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = > =20 > -- Mike & = Nat & John > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1544 = and as @selfissued = . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_BBC28EB5-C417-4DA4-8727-370974085868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I still find the following text objectionable = and confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.




On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_BBC28EB5-C417-4DA4-8727-370974085868-- From nobody Thu Feb 18 05:40:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A207F1A8A52 for ; Thu, 18 Feb 2016 05:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_3PMYzEMSns for ; Thu, 18 Feb 2016 05:40:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11431A8A23 for ; Thu, 18 Feb 2016 05:40:29 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MYsEZ-1aSG521GkN-00Vj5p for ; Thu, 18 Feb 2016 14:40:27 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56C5C9D5.6040703@gmx.net> Date: Thu, 18 Feb 2016 14:40:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KrntmGT2DaIM6THAlmumXaAu98EQsmULp" X-Provags-ID: V03:K0:8jQOC6ebW5KiQRngZwx1jqB0IsyA8bFYA6stljP0mLe1zF1CNeq +bWZEKVTw1HADGCHzsl/8aCk/lUNKxtYXcSrao7eUGM/1VIP1rDvTe8k5i9uXkGUdbjfBNI /5bvmPVZt75pLOKZriMBRdUnsJYeX0/jkXC5cZQh71Wxhh2Cc0FUFz48wgbahtBWaYUfMsw YOVKD06TY2NhIV0kUsYMQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ErPsEjSUCgY=:xNwyyi3bJu8zqI56kbEDL8 8jjlIKfS/jq1Y/tjmq7HZ8USdzZsAAdoaLd+DNGr2ARnPOIbovx5qluJW6atE/TJYjHKjco+i DvPnZe3/M1H+VBq3yQ82/nX78dDLaT5uc4tCDSVf8y8O68txtktRzQ9y4RRf7GA9XzOxqiPoM zi+TO1/mar2b2SETnCf1rwNNz/YvbifH+n4bD3QGhiVuE3y7vnhYkxIAiO5JVZXxfM9rnghvn RbtWMLe70uHzwiYZ1inydsS9J5vNZMKPcJbJfmp81msWQR6LvCuFJTrOYx90noscunqLH2u5l 3MWDJVF+9d5+rov8wXxmOm49lVzPHClb5VOPCZQ+ObSlZT4hf8jKtj7lkkKyKUlGzwjOhH0yM HQiokZYCBAmrq6mX1sQH77KcXWnr/7V8CQZcpTQ9tTJ+ECzUP1wCPTOro9VTaHqmNWObqHCQk Y3p8u9/sYgPm5xjq7UxaRtfIk8kgfqxmoH1ngSnM5UZod3UUDV5LOweOVeARJOgt0WP/Q2NLu ru0LG3dHahdiC+aW93XLc9FwYRfMVORI4wgrc0T1ZWo1jh+MZptdiAS+B5jbEcZ9VhXmvtXsH 8xe7QzTMGHPTMS+eNcPT8tyvOZ5uCmMegSGWNPnBCHpbORvjdEIkh3mI8GL3NHbYJspqx4+pN FMEyU1F9uDksnBVG5Rl/jD9S7dFA4yVw8O58WafT+BLadmSQ/LzuFND2f7xgvM7Lha4aV4UK9 /RY75dOWQGwLcMhBzNAFQ6gfi8D1WoG44fqonpzyy+Jx0DHfqjJxMpIdT+I= Archived-At: Subject: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 13:40:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KrntmGT2DaIM6THAlmumXaAu98EQsmULp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, This is a Last Call for comments on the OAuth 2.0 Discovery specificatio= n: https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 Since this document was only adopted recently we are running this last call for **3 weeks**. Please have your comments in no later than March 10th. Ciao Hannes & Derek --KrntmGT2DaIM6THAlmumXaAu98EQsmULp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWxcnWAAoJEGhJURNOOiAt2cUH/3ULcNWKwJRZ5NE8yZMXhSkZ zMwCXvCpj6bfv3qUfyFSirUu/VZsKxYeZt0y7oNnwscvuiqY7Xn1FEYtWyF+PgvL QCZ0dHoexRWyXSKknn09p00CsQ2FPAcou01mYYxDjx5ZKaUIm8lE0N+itInkOMB8 /KICVzJ5WXQkjZW4dnBs2lZTdNF41d1BVIbrEmubZ3oHV9XpViiocWdD8N1iDgm1 vHlsg//atfw6hssIpHdwfbgCSLOaGx4s6yGE9sgSvkvaWbJ/KyKp4bMwbpmOveHY f0K7tmCX393qlkvdN8qy/+z69FVsWwKGfWno14dKRShSgzZXnLEjlU7yrZhA03I= =v02i -----END PGP SIGNATURE----- --KrntmGT2DaIM6THAlmumXaAu98EQsmULp-- From nobody Thu Feb 18 05:55:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775A21A904F for ; Thu, 18 Feb 2016 05:55:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icYdcjYwP713 for ; Thu, 18 Feb 2016 05:55:44 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EAD1A903D for ; Thu, 18 Feb 2016 05:55:43 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id c3so44585985vkb.3 for ; Thu, 18 Feb 2016 05:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=EiMv8iRKf07K3jgqOugfOBTb9SeOML0GSYTk0EGjevM=; b=I37ytp2JsNhMXhIopWr5fZvL9qucsaBm6Y8nIwEsykELqVeOf8WLKiPDuDijNY2/Ek owwOXP4fI6ChQBSQ05YG6VAFG6Nn+Kv2bdGI3GGVTIAxIRmSIqy0svlRCRRp+6feQEZo LM3EuyTtgDQsPPAyqZ7mFYn28zSeN+C/dfvkg5l485bsTOalMiCP0ra3h+4iA+KKg4a6 JvA3BUmGCC5+2NDoVhP8AQn0+Tg5t5baN5719TM/pP4DEsExVabG0EfkITf93JG06q9v gRh7bolS8JES+xdjHFdbSKI04q6V0CV/SjLapqq1dmOLWjv2LxESqnNwJ/nWFRoubCNN U0Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=EiMv8iRKf07K3jgqOugfOBTb9SeOML0GSYTk0EGjevM=; b=bYkxqbSA7XtCXmsIol8G1HFTvGmSQcTcH/NCUnf64aEHWrdHExSsa+l/rTmjgailbW ZrBcyF/ZdHnSHDvoREMx0hDR3NV39G+rL+UmKGtkMA8fj5N+lUXOW3GpdTyWZbaORQZN CLY16WjVV9ZDv/jHFmr2Oe4FA/ZOUWqpnkwBG/kK4BqulPE68hGHVUWts1p2MKNr2hIM CcuoA+wgyxAEt9ZSLJRyAB1evFx9QCcfrEwmRUVqnGFwXMzxXkwt3aX8JOd1iZgy/ydD pr6hSMugCXrvZdXscNjwzT4q6P+rCVfKTRSZnfkRvItln5MDu3F7HXVG2i5sh6m6XnZa xoyw== X-Gm-Message-State: AG10YOTWF5BIrW2rJ7IIYIhyNdXjt0o4hmlSkLOTKqidNlhj6oyZ8iLuGAqgHiWHZ5RnIw== X-Received: by 10.31.52.133 with SMTP id b127mr6120984vka.77.1455803742739; Thu, 18 Feb 2016 05:55:42 -0800 (PST) Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id h22sm755071vka.26.2016.02.18.05.55.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 05:55:41 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> Date: Thu, 18 Feb 2016 08:55:39 -0500 Message-Id: <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 13:55:47 -0000 --Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF Content-Type: multipart/alternative; boundary="Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF" --Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. It should be posable to have them as one document, but forcing them to = use one document is going to cause a explosion of claim registration for = discovery. I think it is better for SCIM to register one well known than to have to = register 20 claims with scim prefixes or something silly like that. Name-spacing the claims by allowing them to be in different well known = files is not unreasonable. Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. Nothing stops a protocol from doing what it likes with webfinger if it = wants to use that for discovery. In principal I like the idea of having another protocol as an example. My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 I personally think sorting out discovery for SCIM is a good idea, but = OAUTh is but one of several authentication methods for SCIM, and there = are probably other non OAuth things that want to be described. I would feel better about using it as an example if it were adopted by = the WG and some general interest shown. I encourage you to do that so we can use it as a example. John B. > On Feb 18, 2016, at 8:35 AM, Phil Hunt wrote: >=20 > I still find the following text objectionable and confusing=E2=80=A6 > By default, for historical reasons, unless an application-specific > well-known URI path suffix is registered and used for an = application, > the client for that application SHOULD use the well-known URI path > suffix "openid-configuration" and publish the metadata document at > the path formed by concatenating = "/.well-known/openid-configuration" > to the authorization server's issuer identifier. As described in > Section 5 = , = despite the identifier > "/.well-known/openid-configuration", appearing to be = OpenID-specific, > its usage in this specification is actually referring to a general > OAuth 2.0 feature that is not specific to OpenID Connect. >=20 > Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >=20 > It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >=20 > GET /.well-known/openid-configuration > and > GET /.well-known/scim > Retrieve the OAuth configuration for the application openid and scim = respectively. >=20 > The use of: > GET /.well-known/oauth2/ > Should be the default used when there is no known application based = well-known application based URI discovery. >=20 > Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >=20 > It seemed better to me to use the webfinger syntax to allow the client = to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: >>=20 >> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >> =20 >> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >> =20 >> The specification is available at: >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >> =20 >> An HTML-formatted version is also available at: >> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >> =20 >> -- Mike & = Nat & John >> =20 >> P.S. This notice was also posted at http://self-issued.info/?p=3D1544 = and as @selfissued = . >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes = etc.

It should be = posable to have them as one document, but forcing them to use one = document is going to cause a explosion of claim registration for = discovery.

I = think it is better for SCIM to register one well known than to have to = register 20 claims with scim prefixes or something silly like = that.

Name-spacing the claims by allowing them to be in different = well known files is not unreasonable.

Remember some of these protocols may be = hosted on SaaS so there is no guarantee that all protocols will have the = same OAuth Config.

Nothing stops a protocol from doing what it likes with = webfinger if it wants to use that for discovery.

In principal I like the idea of having = another protocol as an example.

My only concern is that I haven=E2=80=99t= seen any discussion of your SCIM discovery document in the SCIM WG. =  
I personally think sorting out discovery for = SCIM is a good idea,  but OAUTh is but one of several = authentication methods for SCIM, and there are probably other non OAuth = things that want to be described.

I would feel better about using it as = an example if it were adopted by the WG and some general interest = shown.

I = encourage you to do that so we can use it as a example.

John B.

On Feb 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionable and = confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.





On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_7EDD57F4-67C4-4E79-ACAB-878D9106F5DF-- --Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTgxMzU1NDBaMCMGCSqGSIb3DQEJBDEWBBRcvVPLAVunnQpKio7PwJPh qZ8N6DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCoJI3KW/NMhDQ9Rm7fLW+qW67O747MMgUeTcpD7RT/6MRy7cI9fYZA hQV2oQ6QQu67TxmDImPPRhLtkfgCtlAYDbgEFZebE9HwMEyx74ZciOEkeXnvx2VApkudAvpX+iPe CCCDd6gNxJYOWKBewQIQapIID9TEOtcmAsXp0AD9ML0WYxutPar3SN4e+spqHChL2RLsPUn8ylZ/ 26LwgGipeeaLzF2hyUUdLZrYtI6pDfiE4aTRqvZPazjo+vzNfxyotUJIgKUg3QenK6A5B08darSg EhDEpeFFvobPLEtP4bWm1I81Jed/E9Nc6SjtdyQEShK12gqi2cLbbx3Wk4bDAAAAAAAA --Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF-- From nobody Thu Feb 18 06:06:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4741A1BEF for ; Thu, 18 Feb 2016 06:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3FpeHG-a1qq for ; Thu, 18 Feb 2016 06:06:40 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4421A014E for ; Thu, 18 Feb 2016 06:06:39 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1IE6c4W012659 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Feb 2016 14:06:39 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1IE6cAv025521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Feb 2016 14:06:38 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1IE6bFd023756; Thu, 18 Feb 2016 14:06:37 GMT Received: from [10.5.50.249] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 06:06:37 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_B65C2111-0824-465D-9DC3-069C0056CFCA" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> Date: Thu, 18 Feb 2016 07:06:35 -0700 Message-Id: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:06:45 -0000 --Apple-Mail=_B65C2111-0824-465D-9DC3-069C0056CFCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Maybe SCIM was a bad example. It functions as a RESTful resource in the = context of OAuth. I find the use of OIDC to be confusing as an example (and the default) = because it is both an OAuth resource and a security service. It is a = modification of OAuth. Start thinking about every application ever written that uses OAuth. Are = we expecting 100s of thousands of these to each register? To me, this specification is a fine specification for OIDC and it should = be published there because the specification defines how to discovery = OAuth and OpenID information. Likewise you suggest it is ok for SCIM to do the same.=20 How do we expect normal applications to set up and do discovery? It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. That still allows me to have a separate discovery service that says, = tell me about resource service X itself. BTW. I think we are FAR from Last Call on this topic. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 18, 2016, at 6:55 AM, John Bradley wrote: >=20 > Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >=20 > It should be posable to have them as one document, but forcing them to = use one document is going to cause a explosion of claim registration for = discovery. >=20 > I think it is better for SCIM to register one well known than to have = to register 20 claims with scim prefixes or something silly like that. >=20 > Name-spacing the claims by allowing them to be in different well known = files is not unreasonable. >=20 > Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. >=20 > Nothing stops a protocol from doing what it likes with webfinger if it = wants to use that for discovery. >=20 > In principal I like the idea of having another protocol as an example. >=20 > My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 > I personally think sorting out discovery for SCIM is a good idea, but = OAUTh is but one of several authentication methods for SCIM, and there = are probably other non OAuth things that want to be described. >=20 > I would feel better about using it as an example if it were adopted by = the WG and some general interest shown. >=20 > I encourage you to do that so we can use it as a example. >=20 > John B. >=20 >> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >>=20 >> I still find the following text objectionable and confusing=E2=80=A6 >> By default, for historical reasons, unless an application-specific >> well-known URI path suffix is registered and used for an = application, >> the client for that application SHOULD use the well-known URI path >> suffix "openid-configuration" and publish the metadata document at >> the path formed by concatenating = "/.well-known/openid-configuration" >> to the authorization server's issuer identifier. As described in >> Section 5 = , = despite the identifier >> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >> its usage in this specification is actually referring to a general >> OAuth 2.0 feature that is not specific to OpenID Connect. >>=20 >> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >>=20 >> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >>=20 >> GET /.well-known/openid-configuration >> and >> GET /.well-known/scim >> Retrieve the OAuth configuration for the application openid and scim = respectively. >>=20 >> The use of: >> GET /.well-known/oauth2/ >> Should be the default used when there is no known application based = well-known application based URI discovery. >>=20 >> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >>=20 >> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 17, 2016, at 11:48 PM, Mike Jones = > = wrote: >>>=20 >>> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >>> =20 >>> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >>> =20 >>> The specification is available at: >>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >>> =20 >>> An HTML-formatted version is also available at: >>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >>> =20 >>> -- Mike & = Nat & John >>> =20 >>> P.S. This notice was also posted at http://self-issued.info/?p=3D1544= and as @selfissued = . >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_B65C2111-0824-465D-9DC3-069C0056CFCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Maybe SCIM was a bad example.  It functions as a RESTful = resource in the context of OAuth.

I find the use of OIDC to be confusing as an example (and = the default) because it is both an OAuth resource and a security = service.  It is a modification of OAuth.

Start thinking about = every application ever written that uses OAuth. Are we expecting 100s of = thousands of these to each register?

To me, this specification is a fine = specification for OIDC and it should be published there because the = specification defines how to discovery OAuth and OpenID = information.

Likewise you suggest it is ok for SCIM to do the = same. 

How do we expect normal applications to set up and do = discovery?

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec = should have a parameter to ask, I want to discover OAuth configuration = for resource service X.

That still allows me to have a separate discovery service = that says, tell me about resource service X itself.

BTW. I think we are FAR = from Last Call on this topic.




On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Diffrent = protocols like Connect and SCIM may have different configurations, = endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as = one document, but forcing them to use one document is going to cause a = explosion of claim registration for discovery.

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like that.

Name-spacing the claims by allowing = them to be in different well known files is not unreasonable.

Remember some of these = protocols may be hosted on SaaS so there is no guarantee that all = protocols will have the same OAuth Config.

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

In = principal I like the idea of having another protocol as an = example.

My = only concern is that I haven=E2=80=99t seen any discussion of your SCIM = discovery document in the SCIM WG.  
I = personally think sorting out discovery for SCIM is a good idea, =  but OAUTh is but one of several authentication methods for SCIM, = and there are probably other non OAuth things that want to be = described.

I = would feel better about using it as an example if it were adopted by the = WG and some general interest shown.

I encourage you to do that so we can = use it as a example.

John B.

On Feb = 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionable and = confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.





On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


= --Apple-Mail=_B65C2111-0824-465D-9DC3-069C0056CFCA-- From nobody Thu Feb 18 06:19:18 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95A1AC3CA for ; Thu, 18 Feb 2016 06:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPtrl99AdVMA for ; Thu, 18 Feb 2016 06:19:14 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F94A1AC3DF for ; Thu, 18 Feb 2016 06:19:12 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e6so45240428vkh.2 for ; Thu, 18 Feb 2016 06:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RnM3WYt32y338cvY0ypttvwJyFx9IIIvsCgsvEFTYyU=; b=VsIv4OaAhzvnnx+aMbPW+EU2V3EkDgq12iILxzi8FEGsyXDRL0aoplDRtZjk0FuqOr Wfo+tAFjKyKgsqXwSXBSXQrLB0Pa9izTr5NvV4OFXrtlVVcT5uLZ3pZv64IUv5P3a3Vh YlG0mjf37VN0NEDXgsYhiKxNOVidgZoZW46GfqnoHGj7kcUdG1P5rF1fCYdI2+dKEkp8 yrN1vBaXjto0AWC3x3c4OfFZps5sFg7+w47msE66i6BL+liGY+FGCMIW5IsHpQ29yUv1 VeymPWF1WIpisP2hmF9s7tCAQqJdcuS7ugl2H/kEB1JIDy9AUoZJlEbsTe/tMvboY1Gm +90A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RnM3WYt32y338cvY0ypttvwJyFx9IIIvsCgsvEFTYyU=; b=WbnmJ1gbu49rZsFW6vvoxkUktWxj3IyUcoLOOMeEQEzmxgAi05oK3tvFv1ndcQGwYx 6AMEfJBO8dsE5vNFYmJEtjZ6PTX32xQtg54NZVU9OYNtGBCadsnu2PSO+Sc5obwfFevL F6IU0seNs32KGAH9SfbwWmy/PQuy95Tk4t3QhE8rLhqrwRFuf9lEZckriHRjfC5A2mkx NlSrsWXlzg6TQ8zUGl/bhBOXi3MjZIGHkhVZQTj4ouzS7Vxh7C7tmOtBv0M2DQx72e+D glVBFe2KYzelU4PnBDK3Xyr94Orjku2tvLJvurddVTRNFJqxMwKFjiFL5t9Z7zO9Oove 8pxA== X-Gm-Message-State: AG10YORBShQhZUu8+R/JhQqDueFfwK9bde3pOP2HJ2GlDmLl+zVeY2AWTjeh4PbzFMxhcA== X-Received: by 10.31.44.77 with SMTP id s74mr6123602vks.4.1455805151892; Thu, 18 Feb 2016 06:19:11 -0800 (PST) Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id v19sm757939vkd.22.2016.02.18.06.19.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 06:19:10 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 18 Feb 2016 09:19:09 -0500 Message-Id: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:19:18 -0000 --Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116 Content-Type: multipart/alternative; boundary="Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C" --Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? Is that the RS base URI for the resource, a specific URI that the = client is requesting? That is getting UMA ish.=20 The concept of a base RS URI is a rat hole that I prefer not to go down, = as it is something everyone thinks exists but like SCIM if it exists it = is protocol or deployment specific. The notion that you would send the URI you are planning on requesting to = a Webfinger server to find the OAuth server, is probably going to have = privacy issues. I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. RS discovery probably wants to be separate from AS discovery. (Yes I do = think we need something, UMA rpt or something like it might be a way to = go) John B. > On Feb 18, 2016, at 9:06 AM, Phil Hunt wrote: >=20 > Maybe SCIM was a bad example. It functions as a RESTful resource in = the context of OAuth. >=20 > I find the use of OIDC to be confusing as an example (and the default) = because it is both an OAuth resource and a security service. It is a = modification of OAuth. >=20 > Start thinking about every application ever written that uses OAuth. = Are we expecting 100s of thousands of these to each register? >=20 > To me, this specification is a fine specification for OIDC and it = should be published there because the specification defines how to = discovery OAuth and OpenID information. >=20 > Likewise you suggest it is ok for SCIM to do the same.=20 >=20 > How do we expect normal applications to set up and do discovery? >=20 > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. >=20 > That still allows me to have a separate discovery service that says, = tell me about resource service X itself. >=20 > BTW. I think we are FAR from Last Call on this topic. >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: >>=20 >> Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >>=20 >> It should be posable to have them as one document, but forcing them = to use one document is going to cause a explosion of claim registration = for discovery. >>=20 >> I think it is better for SCIM to register one well known than to have = to register 20 claims with scim prefixes or something silly like that. >>=20 >> Name-spacing the claims by allowing them to be in different well = known files is not unreasonable. >>=20 >> Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. >>=20 >> Nothing stops a protocol from doing what it likes with webfinger if = it wants to use that for discovery. >>=20 >> In principal I like the idea of having another protocol as an = example. >>=20 >> My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 >> I personally think sorting out discovery for SCIM is a good idea, = but OAUTh is but one of several authentication methods for SCIM, and = there are probably other non OAuth things that want to be described. >>=20 >> I would feel better about using it as an example if it were adopted = by the WG and some general interest shown. >>=20 >> I encourage you to do that so we can use it as a example. >>=20 >> John B. >>=20 >>> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >>>=20 >>> I still find the following text objectionable and confusing=E2=80=A6 >>> By default, for historical reasons, unless an = application-specific >>> well-known URI path suffix is registered and used for an = application, >>> the client for that application SHOULD use the well-known URI = path >>> suffix "openid-configuration" and publish the metadata document = at >>> the path formed by concatenating = "/.well-known/openid-configuration" >>> to the authorization server's issuer identifier. As described in >>> Section 5 = , = despite the identifier >>> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >>> its usage in this specification is actually referring to a = general >>> OAuth 2.0 feature that is not specific to OpenID Connect. >>>=20 >>> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >>>=20 >>> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >>>=20 >>> GET /.well-known/openid-configuration >>> and >>> GET /.well-known/scim >>> Retrieve the OAuth configuration for the application openid and scim = respectively. >>>=20 >>> The use of: >>> GET /.well-known/oauth2/ >>> Should be the default used when there is no known application based = well-known application based URI discovery. >>>=20 >>> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >>>=20 >>> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 17, 2016, at 11:48 PM, Mike Jones = > = wrote: >>>>=20 >>>> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >>>> =20 >>>> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >>>> =20 >>>> The specification is available at: >>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >>>> =20 >>>> An HTML-formatted version is also available at: >>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >>>> =20 >>>> -- Mike & = Nat & John >>>> =20 >>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued . >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 --Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Can you clarify what you mean by =E2=80=9Cresource service = x=E2=80=9D?

Is that = the RS base URI for the resource,  a specific URI that the client = is requesting?

That is getting UMA ish. 

The concept of a base RS URI is a rat = hole that I prefer not to go down, as it is something everyone thinks = exists but like SCIM if it exists it is protocol or deployment = specific.

The = notion that you would send the URI you are planning on requesting to a = Webfinger server to find the OAuth server, is probably going to have = privacy issues.

I suspect that you need to hand back a error from the = resource to say where the AS is, or have a .well-known for the = RS.

RS = discovery probably wants to be separate from AS discovery.  (Yes I = do think we need something,  UMA rpt or something like it might be = a way to go)

John B.

On = Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Maybe SCIM was = a bad example.  It functions as a RESTful resource in the context = of OAuth.

I find the = use of OIDC to be confusing as an example (and the default) because it = is both an OAuth resource and a security service.  It is a = modification of OAuth.

Start thinking about every application = ever written that uses OAuth. Are we expecting 100s of thousands of = these to each register?

To me, this specification is a fine specification for OIDC = and it should be published there because the specification defines how = to discovery OAuth and OpenID information.

Likewise you suggest it is ok for SCIM = to do the same. 

How do we expect normal applications to set = up and do discovery?

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec = should have a parameter to ask, I want to discover OAuth configuration = for resource service X.

That still allows me to have a separate discovery service = that says, tell me about resource service X itself.

BTW. I think we are FAR = from Last Call on this topic.





On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Diffrent = protocols like Connect and SCIM may have different configurations, = endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as = one document, but forcing them to use one document is going to cause a = explosion of claim registration for discovery.

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like that.

Name-spacing the claims by allowing = them to be in different well known files is not unreasonable.

Remember some of these = protocols may be hosted on SaaS so there is no guarantee that all = protocols will have the same OAuth Config.

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

In = principal I like the idea of having another protocol as an = example.

My = only concern is that I haven=E2=80=99t seen any discussion of your SCIM = discovery document in the SCIM WG.  
I = personally think sorting out discovery for SCIM is a good idea, =  but OAUTh is but one of several authentication methods for SCIM, = and there are probably other non OAuth things that want to be = described.

I = would feel better about using it as an example if it were adopted by the = WG and some general interest shown.

I encourage you to do that so we can = use it as a example.

John B.

On Feb = 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionable and = confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.





On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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



= --Apple-Mail=_AD2AFE33-99A6-41E3-87B0-9135EBE6227C-- --Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTgxNDE5MDlaMCMGCSqGSIb3DQEJBDEWBBQGGCudZzlBUW2f+8iI3CPe lq1NdjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCSQQT+PXdQSgyOf17lnGFzmZwGCYOCnQE9TnEKPrWFc2+z2Qa0aS28 JcUOFNBz+Q6jeH9dh56v263KBTmXGdeABuwBy5c74jUdXEYWa5QVHPwGPkpx7dwMQvpvQgPCNGHy ovWVT9yr25QJhanU6fGcfBUdWJX8nNNG4ZI81uKsQqVxZ9YtwEWujQzRrfCHw8ENhUwXp5Pal60v 6vTaPPRUX0dF1gBItkwkrf4+M9l/oww0OwmqOOWnxxz2rKASepxCGd6awjeSKCkuy1L5TOyvS9mk Ehe+tmSXo8dZYhQWz5XNpIREq7tYTHXpC6JidlncQJEOsv0Kbsu9wGH+hpziAAAAAAAA --Apple-Mail=_6ADD2369-3884-4482-859A-CF187414C116-- From nobody Thu Feb 18 06:26:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D51AC3B1 for ; Thu, 18 Feb 2016 06:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgkccYZGo-3n for ; Thu, 18 Feb 2016 06:26:36 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 3A4B21A00BC for ; Thu, 18 Feb 2016 06:26:36 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id y89so37526100qge.2 for ; Thu, 18 Feb 2016 06:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=JXiJBAXpqmkXygVASY0UyjUyvWsy06GhNw5z3dBtxeM=; b=VhRcilXVf6NA1JipKHyfkgIhapPFq4C3aAyan/i3PZJ4B29x5VaUPrFDU8xw+k39rb 0J3oBoRVfpIdKCRTclUXjSRYNMCGUJ5PoYNlyali3S+W70zlDtTO79pmTdTw4BmeaAGG 7Uds8Nuz0SuxdN0hudm85xFfWUilOTMG4QWIsc0FVZeNOVXZBHI7AgyvIxjFSPuJnSsv k1HR1qPgff6CMwclsnT2ms4UN+EnGSGPhWLtClLFwOWC0gTnYXbbeVKg+Wl0hntlswiJ X59upc2QujjQS9VnFaBuRyBlCVk+3FWpH8DM5CiPQXefbceBrYtZI30TpnhtED1VRR53 rO2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=JXiJBAXpqmkXygVASY0UyjUyvWsy06GhNw5z3dBtxeM=; b=Rj/R6djj5RAHTtOGYyumpJIrhdOBtz76ekgN1rTa2Yr/VI6U0IX1p4vGPHSPeO7Xmh LtWD164TDBBYBAUdQ4JLPIMptqzqyDdqV02ZIotvUazLSrRWrCcc/Scy3nyJC9+iy5Mv jyL8YmeZZ7oO6+gWOCIXSQ5VJXB264uZ73mhAoY81caMAB1bmqKgnoSHFltj2fUUEJHA 8wNgf+aw305oJytl0V+fCSGBGxVt8vCQVDTsE7wxktn30b5F5kQVmww1mV6hrs/R77U4 cT3znYD3AJ9xzT44l1Y2tTBX13UhplJaL79S9Wn9U92EKgIKZZ+xyzK/VI8yxaj1HSFK 9QIw== X-Gm-Message-State: AG10YOR9o/C5uv6og9hbUWZ+w/mF4SV8o5zIHqCJ1SPDXmaIK+LZkEyJiQUXiKgbCEyXUVNhh09fwSnxOyB9SA== X-Received: by 10.140.165.205 with SMTP id l196mr9869927qhl.58.1455805595279; Thu, 18 Feb 2016 06:26:35 -0800 (PST) MIME-Version: 1.0 References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> In-Reply-To: From: Nat Sakimura Date: Thu, 18 Feb 2016 14:26:24 +0000 Message-ID: To: Phil Hunt , John Bradley Content-Type: multipart/alternative; boundary=001a1134f04c5e8e22052c0c2710 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:26:40 -0000 --001a1134f04c5e8e22052c0c2710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, >From the RESTful perspective, it is the resource that should specify where the client should find the configuration etc. through RFC5988. As RFC5785 states, /.well-known/ uri is a last resort when this approach does not work, e.g., when you cannot access the resource before knowing the metadta. If I read your message correctly, your use case seems to be able to be accessed first. Then RFC5988 approach seems to work perfectly. I am advocating oauth-meta [1] for such cases. [1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-2 Nat 2016=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=9C=A8) 23:06 Phil Hunt : > Maybe SCIM was a bad example. It functions as a RESTful resource in the > context of OAuth. > > I find the use of OIDC to be confusing as an example (and the default) > because it is both an OAuth resource and a security service. It is a > modification of OAuth. > > Start thinking about every application ever written that uses OAuth. Are > we expecting 100s of thousands of these to each register? > > To me, this specification is a fine specification for OIDC and it should > be published there because the specification defines how to discovery OAu= th > and OpenID information. > > Likewise you suggest it is ok for SCIM to do the same. > > How do we expect normal applications to set up and do discovery? > > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should have= a parameter to > ask, I want to discover OAuth configuration for resource service X. > > That still allows me to have a separate discovery service that says, tell > me about resource service X itself. > > BTW. I think we are FAR from Last Call on this topic. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Feb 18, 2016, at 6:55 AM, John Bradley wrote: > > Diffrent protocols like Connect and SCIM may have different > configurations, endpoints , keys , authentication methods, scopes etc. > > It should be posable to have them as one document, but forcing them to us= e > one document is going to cause a explosion of claim registration for > discovery. > > I think it is better for SCIM to register one well known than to have to > register 20 claims with scim prefixes or something silly like that. > > Name-spacing the claims by allowing them to be in different well known > files is not unreasonable. > > Remember some of these protocols may be hosted on SaaS so there is no > guarantee that all protocols will have the same OAuth Config. > > Nothing stops a protocol from doing what it likes with webfinger if it > wants to use that for discovery. > > In principal I like the idea of having another protocol as an example. > > My only concern is that I haven=E2=80=99t seen any discussion of your SCI= M > discovery document in the SCIM WG. > I personally think sorting out discovery for SCIM is a good idea, but > OAUTh is but one of several authentication methods for SCIM, and there ar= e > probably other non OAuth things that want to be described. > > I would feel better about using it as an example if it were adopted by th= e > WG and some general interest shown. > > I encourage you to do that so we can use it as a example. > > John B. > > On Feb 18, 2016, at 8:35 AM, Phil Hunt wrote: > > I still find the following text objectionable and confusing=E2=80=A6 > > By default, for historical reasons, unless an application-specific > well-known URI path suffix is registered and used for an application, > the client for that application SHOULD use the well-known URI path > suffix "openid-configuration" and publish the metadata document at > the path formed by concatenating "/.well-known/openid-configuration" > to the authorization server's issuer identifier. As described in > Section 5 , despite the identifier > "/.well-known/openid-configuration", appearing to be OpenID-specific, > its usage in this specification is actually referring to a general > OAuth 2.0 feature that is not specific to OpenID Connect. > > > Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the defau= lt further gives > people the impression that a plain OAuth server *is* an authentication > server and that the normal access token received is evidence of a > successful authentication. > > It would be better to point out that application may include oauth > discovery in their discovery URI and that OAuth is an example of this. It > might be good to include two examples. E.g. OIDC and SCIM (as another > referenceable example). > > GET /.well-known/openid-configuration > > and > > GET /.well-known/scim > > Retrieve the OAuth configuration for the application openid and scim > respectively. > > The use of: > > GET /.well-known/oauth2/ > > Should be the default used when there is no known application based > well-known application based URI discovery. > > Of course, the concern I raised earlier is that this approach of > application specific URIs ends up requiring every application to make an > IANA registration if they don=E2=80=99t want to use the default of =E2=80= =9Coauth2=E2=80=9D (or > =E2=80=9Copenid-configuration=E2=80=9D). Is that what the authors expect= ? > > It seemed better to me to use the webfinger syntax to allow the client to > say =E2=80=9CI want the designated OAuth configuration for the resource s= ervice X=E2=80=9D > would be a better design that avoids extensive IANA registration. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: > > In response to working group input, this version of the OAuth Discovery > specification has been pared down to its essence =E2=80=93 leaving only t= he > features that are already widely deployed. Specifically, all that remain= s > is the definition of the authorization server discovery metadata document > and the metadata values used in it. The WebFinger discovery logic has be= en > removed. The relationship between the issuer identifier URL and the > well-known URI path relative to it at which the discovery metadata docume= nt > is located has also been clarified. > > Given that this now describes only features that are in widespread > deployment, the editors believe that this version is ready for working > group last call. > > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > > An HTML-formatted version is also available at: > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-01.h= tml > > -- Mike & Nat & > John > > P.S. This notice was also posted at http://self-issued.info/?p=3D1544 an= d > as @selfissued . > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1134f04c5e8e22052c0c2710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,=C2=A0

From the RESTful p= erspective, it is the resource that should specify where the client should = find the configuration etc. through RFC5988.=C2=A0
As RFC5785 states,=C2=A0/.well-known/ uri is a last resort when= this approach does not work, e.g., when you cannot access the resource bef= ore knowing the metadta.=C2=A0
If I read your message correctly, your use case seems to be able to be= accessed first. Then RFC5988 approach seems to work perfectly.=C2=A0
I am advocating oauth-meta [1] for such cases.=C2=A0
=

Nat
=C2=A0


20= 16=E5=B9=B42=E6=9C=8818=E6=97=A5(=E6=9C=A8) 23:06 Phil Hunt <phil.hunt@oracle.com>:
Maybe SCIM was = a bad example.=C2=A0 It functions as a RESTful resource in the context of O= Auth.

I find the use of OIDC to be confusing as an examp= le (and the default) because it is both an OAuth resource and a security se= rvice.=C2=A0 It is a modification of OAuth.

Start th= inking about every application ever written that uses OAuth. Are we expecti= ng 100s of thousands of these to each register?

To= me, this specification is a fine specification for OIDC and it should be p= ublished there because the specification defines how to discovery OAuth and= OpenID information.

Likewise you suggest it is ok= for SCIM to do the same.=C2=A0

How do we exp= ect normal applications to set up and do discovery?

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec shoul= d have a parameter to ask, I want to discover OAuth configuration for resou= rce service X.

That still allows me to have a sepa= rate discovery service that says, tell me about resource service X itself.<= /div>

BTW. I think we are FAR from Last Call on this top= ic.


On Feb 18, 2016, at 6:55 AM, John B= radley <ve7jtb@ve= 7jtb.com> wrote:

D= iffrent protocols like Connect and SCIM may have different configurations, = endpoints , keys , authentication methods, scopes etc.

I= t should be posable to have them as one document, but forcing them to use o= ne document is going to cause a explosion of claim registration for discove= ry.

I think it is better for SCIM to register one = well known than to have to register 20 claims with scim prefixes or somethi= ng silly like that.

Name-spacing the claims by all= owing them to be in different well known files is not unreasonable.

Remember some of these protocols may be hosted on SaaS so= there is no guarantee that all protocols will have the same OAuth Config.<= /div>

Nothing stops a protocol from doing what it likes = with webfinger if it wants to use that for discovery.

<= div>In principal I like the idea of having another protocol as an example.<= /div>

My only concern is that I haven=E2=80=99t seen any= discussion of your SCIM discovery document in the SCIM WG. =C2=A0
I personally think sorting out discovery for SCIM is a good idea, =C2=A0b= ut OAUTh is but one of several authentication methods for SCIM, and there a= re probably other non OAuth things that want to be described.
I would feel better about using it as an example if it were ado= pted by the WG and some general interest shown.

I = encourage you to do that so we can use it as a example.

John B.

On Feb 18, = 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionabl= e and confusing=E2=80=A6
   By default, for historical reasons, unless an app=
lication-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata documen=
t at
   the path formed by concatenating "/.well-known/openid-configuration=
"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-sp=
ecific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, as a default =E2=80=9Copenid-confi= guration=E2=80=9D as the default further gives people the impression that a= plain OAuth server *is* an authentication server and that the normal acces= s token received is evidence of a successful authentication.

=
It would be better to point out that application may include oau= th discovery in their discovery URI and that OAuth is an example of this. I= t might be good to include two examples.=C2=A0 E.g. OIDC and SCIM (as anoth= er referenceable example).

 GET /.well-known/openid-configurat=
ion
and
 GET /.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application based well-k= nown application based URI discovery.

Of cou= rse, the concern I raised earlier is that this approach of application spec= ific URIs ends up requiring every application to make an IANA registration = if they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (= or =E2=80=9Copenid-configuration=E2=80=9D).=C2=A0 Is that what the authors = expect?

It seemed better to me to use the webfinge= r syntax to allow the client to say =E2=80=9CI want the designated OAuth co= nfiguration for the resource service X=E2=80=9D would be a better design th= at avoids extensive IANA registration.

<= span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p= x">





On Feb 17, 2016, at 11:48 PM, Mike = Jones <= Michael.Jones@microsoft.com> wrote:

In response t= o working group input, this version of the OAuth Discovery specification ha= s been pared down to its essence =E2=80=93 leaving only the features that a= re already widely deployed.=C2=A0 Specifically, all that remains is the def= inition of the authorization server discovery metadata document and the met= adata values used in it.=C2=A0 The WebFinger discovery logic has been remov= ed.=C2=A0 The relationship between the issuer identifier URL and the well-k= nown URI path relative to it at which the discovery metadata document is lo= cated has also been clarified.
=C2=A0
Given that this now describes only features that are i= n widespread deployment, the editors believe that this version is ready for= working group last call.
=C2=A0=
The specification is available at:
=C2=B7=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0http://tools.ietf.org/html/= draft-ietf-oauth-discovery-01
=C2=A0
An HTML-formatted version is also available = at:
<= span>=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html
=C2=A0
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike & Nat & John=
=C2=A0
P.S.=C2=A0 This = notice was also posted at=C2=A0http://self-issued.info/?p=3D1544=C2=A0and= as=C2=A0@selfissu= ed.
__________= _____________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=
_______________________________________________
OAuth ma= iling list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1134f04c5e8e22052c0c2710-- From nobody Thu Feb 18 06:47:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3441A907F for ; Thu, 18 Feb 2016 06:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFlKvBPjII1H for ; Thu, 18 Feb 2016 06:47:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE6B1A00DB for ; Thu, 18 Feb 2016 06:47:06 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQiB3-1aOOwz1IHF-00U6XJ; Thu, 18 Feb 2016 15:47:00 +0100 To: Phil Hunt , John Bradley References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56C5D96D.7000805@gmx.net> Date: Thu, 18 Feb 2016 15:47:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bsLEbrAPHRJklss1MeOiopxbuPS07b4fP" X-Provags-ID: V03:K0:VPcr4Pr6ptO+QB6FVyGE5U62CqXWk014wIhTCznWNYdurdfHTeD t3pEppEGVo2U2DSwf4J2ipsJBz8cnGru1sNh4u1/V/YFkf4Vy/dJffAIt4YQsYpCHgg0gQT LvBPfAGpt3yVc08JGvf8f398U74MkghuKB017BVZlS9GKB8bnCYpnCYCXriblpKmR05wnzd fxvMd1i/IAhM5kk3JKx+A== X-UI-Out-Filterresults: notjunk:1;V01:K0:4MZffgFvJnU=:41vhb/sBTUeUcwqbxFUU9H i+FH2XQP/Nletva0VnhMLycrdIhwHR6n3hVg+NsCU32D3w6M1Zd9bug/RQSG9y4oB/O589rVw Xx2UtUro3gG8gGb9j2DBfMO/3T+pOhhnTXQ1Dz65jmxb4ocf2YqYeBeaG+ntU1r7Ei5xAYUV+ jz2pVrG1mZZOKCOfw+8TY4BWFROFHUGTUMfwwYz9SR8f3SMRiIAqmUnFZVKTw+7/1OpiILucQ RnnOlc9MxMDFuze0NFmTCuLAUFC8ObENwATwgBAy4RixJZq/JDovm+puF9h8gMe7+Zg3vvO2R 4BZPSJNwUHrLDKLUsu/qyGkhXz6tQ7MGAE+fFpjAu76bS5qur41KntDUBJ2T98jcdfR5+z8fz 9BkSmvOb8rDODSWrKMfZbcS0iI2io6WLXdQTmZxiI5E2/SO31CDdnjUJvta+U443iOtHCdnVO 5YzWOfjKA70xgdnVW8tdxSnPDO+q10BjDZNVF/p4/EZaJFBS9t5o+hQwv5taM0RfZ3RMlPTYC HEbcoA4myE+5Hi8RciF07Vy4vIXBFeWix8zWEJjNIjVS+9YOZ8JVzonz9IBZcsJd5ISVtC1Di XRcwTNfurvX2z594CNVgRetmNGyN526wgpD0wzq93FG6ztJQWWniiJVIGGh8i1VDyNGaTGJ7B P7VkZlO+T9nSoO4JxVgy8KNE0RwI7F3P5Dfn0b4zjOJ9NeyPORSExWfo8K6Ce0QaIUXaciafz UPChOSC62axhlTg1H+VRVu1BpKpJfDmTVBUWbpGIzG/pUnC4M2Dxn/o+0ak= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:47:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bsLEbrAPHRJklss1MeOiopxbuPS07b4fP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/18/2016 03:06 PM, Phil Hunt wrote: > BTW. I think we are FAR from Last Call on this topic. Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to your message based on the claim from the authors that they believe the document is finished. We will, of course, take all reviews into account and see where we are with the discovery spec. I, as the shepherd, will also do my review and I encourage many working group members to also take a look at the document and to provide their input. Ciao Hannes --bsLEbrAPHRJklss1MeOiopxbuPS07b4fP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWxdltAAoJEGhJURNOOiAt8GoH/Ru7YPnPvfAT1rw1s7RfG2Qa sGE5QJDVbJ5W2ixRk+h3L7aD5UsvF17lr+VmTaf2oubftWb+1db12R35M1ZBZAFF vYkVmDVWfBh9uy3CspYoJX1jov179gyAbGjUo+IEX5YzmRkFwliCVx8rcefS8mQA 0jERzX5CLHyTO4cE9PWZhB+HUkgB/Ov5FkCDrkfy7qTJYJ61DfbbaSD7mSMHYJR9 yAl6DoYfrWgm7prpMdslEwdw+lvySH4PnyBoWpnDWCm8nIHBEj3J6m1d5CMG9tkp qQl2STpTx3NoDGWSE0PYjMWSO79A0GpUL/NjbhH990mNwiFzfaikX0ocq1xvuag= =8x7q -----END PGP SIGNATURE----- --bsLEbrAPHRJklss1MeOiopxbuPS07b4fP-- From nobody Thu Feb 18 06:49:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2791ACE06 for ; Thu, 18 Feb 2016 06:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG5MIE3-VmkK for ; Thu, 18 Feb 2016 06:49:16 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A321ACE5E for ; Thu, 18 Feb 2016 06:49:15 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1IEnEsT012631 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Feb 2016 14:49:14 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1IEnDWY004391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Feb 2016 14:49:14 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1IEn7Ug001181; Thu, 18 Feb 2016 14:49:13 GMT Received: from [10.5.50.249] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 06:49:07 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_C414C8A8-F6B0-4FBC-92C3-BBF505C0B7CE" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Thu, 18 Feb 2016 07:49:05 -0700 Message-Id: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:49:20 -0000 --Apple-Mail=_C414C8A8-F6B0-4FBC-92C3-BBF505C0B7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 resource service X could be any http accessible service: * CRM * Finance * Payroll * ERP * any application on the web. The spec seems to suggest that we use /.well-known/crm to discover OAuth = config for crm. But that may cause conflict if crm has its own = discovery. Which leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. Then there is confusion about what host the discovery is done on. For example, hypothetically do I do: GET /.well-known/crm Host: example.com But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? Or, what If we put the oauth configuration at the host for the crm = service: GET /.well-known/openid-configuration Host: crm.example.com I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 The client needs to discover: * Where is its designated resource service and what security does it use * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 18, 2016, at 7:19 AM, John Bradley wrote: >=20 > Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? >=20 > Is that the RS base URI for the resource, a specific URI that the = client is requesting? >=20 > That is getting UMA ish.=20 >=20 > The concept of a base RS URI is a rat hole that I prefer not to go = down, as it is something everyone thinks exists but like SCIM if it = exists it is protocol or deployment specific. >=20 > The notion that you would send the URI you are planning on requesting = to a Webfinger server to find the OAuth server, is probably going to = have privacy issues. >=20 > I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. >=20 > RS discovery probably wants to be separate from AS discovery. (Yes I = do think we need something, UMA rpt or something like it might be a way = to go) >=20 > John B. >=20 >> On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: >>=20 >> Maybe SCIM was a bad example. It functions as a RESTful resource in = the context of OAuth. >>=20 >> I find the use of OIDC to be confusing as an example (and the = default) because it is both an OAuth resource and a security service. = It is a modification of OAuth. >>=20 >> Start thinking about every application ever written that uses OAuth. = Are we expecting 100s of thousands of these to each register? >>=20 >> To me, this specification is a fine specification for OIDC and it = should be published there because the specification defines how to = discovery OAuth and OpenID information. >>=20 >> Likewise you suggest it is ok for SCIM to do the same.=20 >>=20 >> How do we expect normal applications to set up and do discovery? >>=20 >> It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. >>=20 >> That still allows me to have a separate discovery service that says, = tell me about resource service X itself. >>=20 >> BTW. I think we are FAR from Last Call on this topic. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: >>>=20 >>> Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >>>=20 >>> It should be posable to have them as one document, but forcing them = to use one document is going to cause a explosion of claim registration = for discovery. >>>=20 >>> I think it is better for SCIM to register one well known than to = have to register 20 claims with scim prefixes or something silly like = that. >>>=20 >>> Name-spacing the claims by allowing them to be in different well = known files is not unreasonable. >>>=20 >>> Remember some of these protocols may be hosted on SaaS so there is = no guarantee that all protocols will have the same OAuth Config. >>>=20 >>> Nothing stops a protocol from doing what it likes with webfinger if = it wants to use that for discovery. >>>=20 >>> In principal I like the idea of having another protocol as an = example. >>>=20 >>> My only concern is that I haven=E2=80=99t seen any discussion of = your SCIM discovery document in the SCIM WG. =20 >>> I personally think sorting out discovery for SCIM is a good idea, = but OAUTh is but one of several authentication methods for SCIM, and = there are probably other non OAuth things that want to be described. >>>=20 >>> I would feel better about using it as an example if it were adopted = by the WG and some general interest shown. >>>=20 >>> I encourage you to do that so we can use it as a example. >>>=20 >>> John B. >>>=20 >>>> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >>>>=20 >>>> I still find the following text objectionable and confusing=E2=80=A6 >>>> By default, for historical reasons, unless an = application-specific >>>> well-known URI path suffix is registered and used for an = application, >>>> the client for that application SHOULD use the well-known URI = path >>>> suffix "openid-configuration" and publish the metadata document = at >>>> the path formed by concatenating = "/.well-known/openid-configuration" >>>> to the authorization server's issuer identifier. As described = in >>>> Section 5 = , = despite the identifier >>>> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >>>> its usage in this specification is actually referring to a = general >>>> OAuth 2.0 feature that is not specific to OpenID Connect. >>>>=20 >>>> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >>>>=20 >>>> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >>>>=20 >>>> GET /.well-known/openid-configuration >>>> and >>>> GET /.well-known/scim >>>> Retrieve the OAuth configuration for the application openid and = scim respectively. >>>>=20 >>>> The use of: >>>> GET /.well-known/oauth2/ >>>> Should be the default used when there is no known application based = well-known application based URI discovery. >>>>=20 >>>> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >>>>=20 >>>> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com = phil.hunt@oracle.com = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Feb 17, 2016, at 11:48 PM, Mike Jones = > = wrote: >>>>>=20 >>>>> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >>>>> =20 >>>>> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >>>>> =20 >>>>> The specification is available at: >>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >>>>> =20 >>>>> An HTML-formatted version is also available at: >>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >>>>> =20 >>>>> -- Mike = & Nat & John >>>>> =20 >>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued . >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>=20 >=20 --Apple-Mail=_C414C8A8-F6B0-4FBC-92C3-BBF505C0B7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 resource service X could be any http accessible service:

* CRM
* Finance
* Payroll
*= ERP
* any application on the web.

The spec seems to = suggest that we use /.well-known/crm to discover OAuth config for crm. =  But that may cause conflict if crm has its own discovery. Which = leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D.

Then there is confusion about what host = the discovery is done on.

For example, hypothetically do I do:

GET /.well-known/crm
Host: example.com

But what about the CRM=E2=80=99s configuration information. = Is this stomping on it?

Or, what If we put the oauth configuration at the host for = the crm service:
GET = /.well-known/openid-configuration
Host: crm.example.com

I think the point is that there is a = relationship between a protected resource and its designated OAuth = service. 

The client needs to discover:
* Where is = its designated resource service and what security does it use
* If it is OAuth, where is the intended OAuth configuration = for that resource service instance?




On Feb 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Can you = clarify what you mean by =E2=80=9Cresource service x=E2=80=9D?

Is that the RS base URI = for the resource,  a specific URI that the client is = requesting?

That= is getting UMA ish. 

The concept of a base RS URI is a rat hole that I prefer not = to go down, as it is something everyone thinks exists but like SCIM if = it exists it is protocol or deployment specific.

The notion that you would send the URI = you are planning on requesting to a Webfinger server to find the OAuth = server, is probably going to have privacy issues.
I suspect that you need to hand back a = error from the resource to say where the AS is, or have a .well-known = for the RS.

RS = discovery probably wants to be separate from AS discovery.  (Yes I = do think we need something,  UMA rpt or something like it might be = a way to go)

John B.

On Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Maybe SCIM was = a bad example.  It functions as a RESTful resource in the context = of OAuth.

I find the = use of OIDC to be confusing as an example (and the default) because it = is both an OAuth resource and a security service.  It is a = modification of OAuth.

Start thinking about every application = ever written that uses OAuth. Are we expecting 100s of thousands of = these to each register?

To me, this specification is a fine specification for OIDC = and it should be published there because the specification defines how = to discovery OAuth and OpenID information.

Likewise you suggest it is ok for SCIM = to do the same. 

How do we expect normal applications to set = up and do discovery?

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec = should have a parameter to ask, I want to discover OAuth configuration = for resource service X.

That still allows me to have a separate discovery service = that says, tell me about resource service X itself.

BTW. I think we are FAR = from Last Call on this topic.





On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Diffrent = protocols like Connect and SCIM may have different configurations, = endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as = one document, but forcing them to use one document is going to cause a = explosion of claim registration for discovery.

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like that.

Name-spacing the claims by allowing = them to be in different well known files is not unreasonable.

Remember some of these = protocols may be hosted on SaaS so there is no guarantee that all = protocols will have the same OAuth Config.

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

In = principal I like the idea of having another protocol as an = example.

My = only concern is that I haven=E2=80=99t seen any discussion of your SCIM = discovery document in the SCIM WG.  
I = personally think sorting out discovery for SCIM is a good idea, =  but OAUTh is but one of several authentication methods for SCIM, = and there are probably other non OAuth things that want to be = described.

I = would feel better about using it as an example if it were adopted by the = WG and some general interest shown.

I encourage you to do that so we can = use it as a example.

John B.

On Feb = 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionable and = confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.





On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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




= --Apple-Mail=_C414C8A8-F6B0-4FBC-92C3-BBF505C0B7CE-- From nobody Thu Feb 18 07:41:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BE71ACE4A for ; Thu, 18 Feb 2016 07:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgUfk_miQkRX for ; Thu, 18 Feb 2016 07:41:32 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 017A71A03A2 for ; Thu, 18 Feb 2016 07:41:27 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id e6so47742256vkh.2 for ; Thu, 18 Feb 2016 07:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WkeNyuMtYBTAitRH8lTt+qEDfuqhpLstaClAQCfsGo0=; b=m0HbPgJs46HBiuewRmV7gS3/8+BUCCEQX9B3BBRufkCWfY6GiZ3IVEnPOSeDrF3eZ0 7n5omLhK1FTlnFllRN/Jl5F+FEgy9xKYVVsTT7+SCiR+usAgrMybGVS79zq/qm66Hmbb 0/8MvnEK9FPOaRjuAIPd1gA7fHTWvzlDOanrFDpHUCiuZYsFizgrMWHN3fpmU9t06kMx vaG3Lg80kDF83yXmUFoVeodaet4+W4lZVIoyy/KS2iHElWUX5Kzh1wK7pCXP8ENFl/yO fMDKhFU++tbAxMJyvx07Tq3IcYMxMMYf4Tv9a8AznZ8kaAc7uJt4K6voH9nEbiG/37H2 +19A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WkeNyuMtYBTAitRH8lTt+qEDfuqhpLstaClAQCfsGo0=; b=V4wn8F7R+lYO7RpAhmc7RDbuJ9HyPv5cL18lT3VR/E9v8zV9U4X0aaujCK9+5YzjpS 8WZsTvzn25TXeiAuSsRlh9nTQ/BN1WjI5d+g3NUnIWa90IaVIzPpUAL12zWyIZxu6gVG E2fSMrglanOCDovkP2lWS5EGWF3m5xq+L57id5KTQgUxOTZpOfJdphL3y9PXQUT4qrgB 0TFHz9V+sWTLCpYEiXjYQgDGltqHkLneBc9cS1MmNTSYmSY1cyO5hC88Lf4G/uhgPEW1 4hL1TFoH2uMNT+D3EhqX9uz9DgtpqtTe0tS5K39DI5jxxf94clqNcnMzgB27TKykafZv bOBw== X-Gm-Message-State: AG10YOTqaSGVY1N/ib7j8u12SWUicN1mczI4mHkLXmBUyfNjNGH/QJcyuUnlZf65pNst7g== X-Received: by 10.31.155.131 with SMTP id d125mr5685688vke.146.1455810085826; Thu, 18 Feb 2016 07:41:25 -0800 (PST) Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id o141sm796656vkd.19.2016.02.18.07.41.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 07:41:24 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_07C71601-5D3B-4095-9967-69C0C94FD967"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 18 Feb 2016 10:41:23 -0500 Message-Id: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> To: Phil Hunt X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:41:40 -0000 --Apple-Mail=_07C71601-5D3B-4095-9967-69C0C94FD967 Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3E85A2-DEBF-4FE6-8BA8-F05FC3EB1327" --Apple-Mail=_0F3E85A2-DEBF-4FE6-8BA8-F05FC3EB1327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I suspect that the configuration well-knowns are going to be on the root = domain. You could try and get a user to put in crm.example.com, but I = suspect that is not going to work. If the app doesn=E2=80=99t have a specific protocol identifier then it = would use the default. =20 I don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app. John B. > On Feb 18, 2016, at 9:49 AM, Phil Hunt wrote: >=20 > resource service X could be any http accessible service: >=20 > * CRM > * Finance > * Payroll > * ERP > * any application on the web. >=20 > The spec seems to suggest that we use /.well-known/crm to discover = OAuth config for crm. But that may cause conflict if crm has its own = discovery. Which leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. >=20 > Then there is confusion about what host the discovery is done on. >=20 > For example, hypothetically do I do: >=20 > GET /.well-known/crm > Host: example.com >=20 > But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? >=20 > Or, what If we put the oauth configuration at the host for the crm = service: > GET /.well-known/openid-configuration > Host: crm.example.com >=20 > I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 >=20 > The client needs to discover: > * Where is its designated resource service and what security does it = use > * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? >=20 > Phil >=20 > @independentid > www.independentid.com = phil.hunt@oracle.com = >=20 >=20 >=20 >=20 >=20 >> On Feb 18, 2016, at 7:19 AM, John Bradley > wrote: >>=20 >> Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? >>=20 >> Is that the RS base URI for the resource, a specific URI that the = client is requesting? >>=20 >> That is getting UMA ish.=20 >>=20 >> The concept of a base RS URI is a rat hole that I prefer not to go = down, as it is something everyone thinks exists but like SCIM if it = exists it is protocol or deployment specific. >>=20 >> The notion that you would send the URI you are planning on requesting = to a Webfinger server to find the OAuth server, is probably going to = have privacy issues. >>=20 >> I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. >>=20 >> RS discovery probably wants to be separate from AS discovery. (Yes I = do think we need something, UMA rpt or something like it might be a way = to go) >>=20 >> John B. >>=20 >>> On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: >>>=20 >>> Maybe SCIM was a bad example. It functions as a RESTful resource in = the context of OAuth. >>>=20 >>> I find the use of OIDC to be confusing as an example (and the = default) because it is both an OAuth resource and a security service. = It is a modification of OAuth. >>>=20 >>> Start thinking about every application ever written that uses OAuth. = Are we expecting 100s of thousands of these to each register? >>>=20 >>> To me, this specification is a fine specification for OIDC and it = should be published there because the specification defines how to = discovery OAuth and OpenID information. >>>=20 >>> Likewise you suggest it is ok for SCIM to do the same.=20 >>>=20 >>> How do we expect normal applications to set up and do discovery? >>>=20 >>> It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. >>>=20 >>> That still allows me to have a separate discovery service that says, = tell me about resource service X itself. >>>=20 >>> BTW. I think we are FAR from Last Call on this topic. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com = phil.hunt@oracle.com = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: >>>>=20 >>>> Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >>>>=20 >>>> It should be posable to have them as one document, but forcing them = to use one document is going to cause a explosion of claim registration = for discovery. >>>>=20 >>>> I think it is better for SCIM to register one well known than to = have to register 20 claims with scim prefixes or something silly like = that. >>>>=20 >>>> Name-spacing the claims by allowing them to be in different well = known files is not unreasonable. >>>>=20 >>>> Remember some of these protocols may be hosted on SaaS so there is = no guarantee that all protocols will have the same OAuth Config. >>>>=20 >>>> Nothing stops a protocol from doing what it likes with webfinger if = it wants to use that for discovery. >>>>=20 >>>> In principal I like the idea of having another protocol as an = example. >>>>=20 >>>> My only concern is that I haven=E2=80=99t seen any discussion of = your SCIM discovery document in the SCIM WG. =20 >>>> I personally think sorting out discovery for SCIM is a good idea, = but OAUTh is but one of several authentication methods for SCIM, and = there are probably other non OAuth things that want to be described. >>>>=20 >>>> I would feel better about using it as an example if it were adopted = by the WG and some general interest shown. >>>>=20 >>>> I encourage you to do that so we can use it as a example. >>>>=20 >>>> John B. >>>>=20 >>>>> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >>>>>=20 >>>>> I still find the following text objectionable and confusing=E2=80=A6= >>>>> By default, for historical reasons, unless an = application-specific >>>>> well-known URI path suffix is registered and used for an = application, >>>>> the client for that application SHOULD use the well-known URI = path >>>>> suffix "openid-configuration" and publish the metadata document = at >>>>> the path formed by concatenating = "/.well-known/openid-configuration" >>>>> to the authorization server's issuer identifier. As described = in >>>>> Section 5 = , = despite the identifier >>>>> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >>>>> its usage in this specification is actually referring to a = general >>>>> OAuth 2.0 feature that is not specific to OpenID Connect. >>>>>=20 >>>>> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as = the default further gives people the impression that a plain OAuth = server *is* an authentication server and that the normal access token = received is evidence of a successful authentication. >>>>>=20 >>>>> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >>>>>=20 >>>>> GET /.well-known/openid-configuration >>>>> and >>>>> GET /.well-known/scim >>>>> Retrieve the OAuth configuration for the application openid and = scim respectively. >>>>>=20 >>>>> The use of: >>>>> GET /.well-known/oauth2/ >>>>> Should be the default used when there is no known application = based well-known application based URI discovery. >>>>>=20 >>>>> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >>>>>=20 >>>>> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com = phil.hunt@oracle.com = >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Feb 17, 2016, at 11:48 PM, Mike Jones = > = wrote: >>>>>>=20 >>>>>> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >>>>>> =20 >>>>>> Given that this now describes only features that are in = widespread deployment, the editors believe that this version is ready = for working group last call. >>>>>> =20 >>>>>> The specification is available at: >>>>>> =C2=B7 = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >>>>>> =20 >>>>>> An HTML-formatted version is also available at: >>>>>> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >>>>>> =20 >>>>>> -- Mike = & Nat & John >>>>>> =20 >>>>>> P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued . >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth = >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_0F3E85A2-DEBF-4FE6-8BA8-F05FC3EB1327 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I suspect that the configuration well-knowns are going to be = on the root domain.   You could try and get a user to put in crm.example.com, but I = suspect that is not going to work.

If the app doesn=E2=80=99t have a = specific protocol identifier then it would use the default. =  

I = don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app.

John B.





On Feb 18, 2016, at 9:49 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:

resource = service X could be any http accessible service:

* CRM
* = Finance
* Payroll
* = ERP
* any application on the web.

The spec seems to = suggest that we use /.well-known/crm to discover OAuth config for crm. =  But that may cause conflict if crm has its own discovery. Which = leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D.

Then there is confusion about what host = the discovery is done on.

For example, hypothetically do I do:

GET /.well-known/crm
Host: example.com

But what about the CRM=E2=80=99s configuration information. = Is this stomping on it?

Or, what If we put the oauth configuration at the host for = the crm service:
GET = /.well-known/openid-configuration
Host: crm.example.com

I think the point is that there is a = relationship between a protected resource and its designated OAuth = service. 

The client needs to discover:
* Where is = its designated resource service and what security does it use
* If it is OAuth, where is the intended OAuth configuration = for that resource service instance?





On Feb 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Can you = clarify what you mean by =E2=80=9Cresource service x=E2=80=9D?

Is that the RS base URI = for the resource,  a specific URI that the client is = requesting?

That= is getting UMA ish. 

The concept of a base RS URI is a rat hole that I prefer not = to go down, as it is something everyone thinks exists but like SCIM if = it exists it is protocol or deployment specific.

The notion that you would send the URI = you are planning on requesting to a Webfinger server to find the OAuth = server, is probably going to have privacy issues.
I suspect that you need to hand back a = error from the resource to say where the AS is, or have a .well-known = for the RS.

RS = discovery probably wants to be separate from AS discovery.  (Yes I = do think we need something,  UMA rpt or something like it might be = a way to go)

John B.

On Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

Maybe SCIM was = a bad example.  It functions as a RESTful resource in the context = of OAuth.

I find the = use of OIDC to be confusing as an example (and the default) because it = is both an OAuth resource and a security service.  It is a = modification of OAuth.

Start thinking about every application = ever written that uses OAuth. Are we expecting 100s of thousands of = these to each register?

To me, this specification is a fine specification for OIDC = and it should be published there because the specification defines how = to discovery OAuth and OpenID information.

Likewise you suggest it is ok for SCIM = to do the same. 

How do we expect normal applications to set = up and do discovery?

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec = should have a parameter to ask, I want to discover OAuth configuration = for resource service X.

That still allows me to have a separate discovery service = that says, tell me about resource service X itself.

BTW. I think we are FAR = from Last Call on this topic.





On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Diffrent = protocols like Connect and SCIM may have different configurations, = endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as = one document, but forcing them to use one document is going to cause a = explosion of claim registration for discovery.

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like that.

Name-spacing the claims by allowing = them to be in different well known files is not unreasonable.

Remember some of these = protocols may be hosted on SaaS so there is no guarantee that all = protocols will have the same OAuth Config.

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

In = principal I like the idea of having another protocol as an = example.

My = only concern is that I haven=E2=80=99t seen any discussion of your SCIM = discovery document in the SCIM WG.  
I = personally think sorting out discovery for SCIM is a good idea, =  but OAUTh is but one of several authentication methods for SCIM, = and there are probably other non OAuth things that want to be = described.

I = would feel better about using it as an example if it were adopted by the = WG and some general interest shown.

I encourage you to do that so we can = use it as a example.

John B.

On Feb = 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I still find the following text objectionable and = confusing=E2=80=A6
   By default, for historical reasons, =
unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, = as a default =E2=80=9Copenid-configuration=E2=80=9D as the default = further gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).

 GET =
/.well-known/openid-configuration
and
 GET =
/.well-known/scim
Retrieve = the OAuth configuration for the application openid and scim = respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.

Of course, the concern I = raised earlier is that this approach of application specific URIs ends = up requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

It = seemed better to me to use the webfinger syntax to allow the client to = say =E2=80=9CI want the designated OAuth configuration for the resource = service X=E2=80=9D would be a better design that avoids extensive IANA = registration.





On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

In response to working group input, = this version of the OAuth Discovery specification has been pared down to = its essence =E2=80=93 leaving only the features that are already widely = deployed.  Specifically, all that remains is the definition of the = authorization server discovery metadata document and the metadata values = used in it.  The WebFinger discovery logic has been removed.  = The relationship between the issuer identifier URL and the well-known = URI path relative to it at which the discovery metadata document is = located has also been clarified.
 
Given that this now describes only = features that are in widespread deployment, the editors believe that = this version is ready for working group last call.
 
The = specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
An = HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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





= --Apple-Mail=_0F3E85A2-DEBF-4FE6-8BA8-F05FC3EB1327-- --Apple-Mail=_07C71601-5D3B-4095-9967-69C0C94FD967 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTgxNTQxMjNaMCMGCSqGSIb3DQEJBDEWBBTUKpOk4yh4bHEBn9Ca6QF0 o7LcAjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCKu5pL1dl6+F+89SwzP9Vnp+wQKhtaY8L7+Py3CumFLLKi0JXSuHHK MXjtiT6nI/PeQR/ysDmkNfUZMAZsqL0ngFvnb11ELOScKMG6oIOAPWD2Bc2my3RP2jJpz5dC7POj 3A5DdPmi8pSkiUHHecPMMrlgFB7OGm6liPPiNhsOXhucqmahK14C+m9vthGirztrfGtbiskdrges 5foJddY/B+1ICsBybC+Mz2suwf6LETMy3NX6FIQwTRchaQYfJijeWoiMMUYMNN+T6zTQrWoROoeO v2Arw6B0aXfI67yLXntkOYTOD2Tnrh0l/jZqcMX3MbZPFC0zCVlMmbV0ohzEAAAAAAAA --Apple-Mail=_07C71601-5D3B-4095-9967-69C0C94FD967-- From nobody Thu Feb 18 08:41:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F491A0469 for ; Thu, 18 Feb 2016 08:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzsTXdOmKD9R for ; Thu, 18 Feb 2016 08:41:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0A01A0074 for ; Thu, 18 Feb 2016 08:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kTC5eElJSdpXHOKO5zNgJ/L5/12/nIpD5X6ojpoIYVM=; b=XZXOFTLE4xEyrmpNVpp72mSITGc4pju7n2QZsCb9mz4BAI5b+Aj8ccVyP5D2x6Q2pXWRXxPYFcum2dWxRMvX27Pw3gB297EfF1zC5HDr8ZNx873cSdD2KChOqZfeVjPRIhOF2IdmEUaR4vLun5k7knFqvUdP4bnBMogn1WX+2Jg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 16:41:16 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 16:41:16 +0000 From: Mike Jones To: John Bradley , Phil Hunt Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAAAcFuAAAELoIAAAdOZgAABqOPw Date: Thu, 18 Feb 2016 16:41:16 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 4aa41198-b5fb-44d6-ecf9-08d338825270 x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:etUPOGSld1qFtGSmEfseClqjqrgIRKQQyWzZXkbEtyir9z6r/VTr/nUslN7GsKOKkLLRZuRdUtm+kCHJUa6fbApjvrdnsfs38EHH8UVjnTKL3QMbg9yaIKqJD6yQmPj0r75U4KnYbvkaoB/3PnRl8Q==; 24:0PlIChcMSk/j9+ABZO5ojVuPSNG79UEpxosJuTZvVNtN6C5wX45zGnc+1Etc844m9XuB01bfAalBfgn4cf7Knsq5PU+qlL5lP1ATVf4lCuY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(24454002)(377454003)(10400500002)(5005710100001)(16601075003)(10090500001)(3846002)(76176999)(102836003)(16236675004)(4326007)(93886004)(54356999)(86612001)(6116002)(790700001)(122556002)(40100003)(5001960100002)(189998001)(2900100001)(586003)(50986999)(5004730100002)(10290500002)(1680700002)(86362001)(2950100001)(2906002)(19617315012)(92566002)(19300405004)(99286002)(15395725005)(76576001)(77096005)(19625215002)(3660700001)(33656002)(19580395003)(19580405001)(1096002)(5003600100002)(11100500001)(15975445007)(5008740100001)(66066001)(5001770100001)(87936001)(1220700001)(5002640100001)(74316001)(3280700002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4425DF67B0BB624401EE7A0F5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 16:41:16.6908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:41:23 -0000 --_000_BY2PR03MB4425DF67B0BB624401EE7A0F5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIHNlY29uZCBKb2hu4oCZcyBwb2ludCB0aGF0IE9BdXRoIGNvbmZpZ3VyYXRpb24gaW5m b3JtYXRpb24gYW5kIGFwcGxpY2F0aW9uIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbmVlZCBu b3QgYmUgaW50ZXJzcGVyc2VkLiAgRm9yIGluc3RhbmNlLCBpZiB0aGUgc2VydmljZSBpcyBhdCBo dHRwczovL2V4YW1wbGUuY29tIGFuZCB0aGUgWFlaIGFwcGxpY2F0aW9uIGlzIGJlaW5nIHVzZWQs IHRoZW4gdGhlc2UgY29uZmlndXJhdGlvbiBtZXRhZGF0YSBkb2N1bWVudHMgY291bGQgYm90aCBi ZSB1c2VkOg0KDQrCtyAgICAgICBodHRwczovL2V4YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5p ZC1jb25maWd1cmF0aW9uIC0gT0F1dGggY29uZmlndXJhdGlvbiBtZXRhZGF0YQ0KDQrCtyAgICAg ICBodHRwczovL2V4YW1wbGUuY29tLy53ZWxsLWtub3duL3h5ei1jb25maWd1cmF0aW9uIC0gWFla IGNvbmZpZ3VyYXRpb24gbWV0YWRhdGENCg0KVGhlcmXigJlzIG5vdCBtdWNoIHBvaW50IGluIGRl ZmluaW5nIGEgbmV3IC8ud2VsbC1rbm93bi9vYXV0aDIuMCB2YWx1ZSwgc2luY2UgdGhlcmUgaXMg bm8gc3VjaCB0aGluZyBhcyBnZW5lcmljIE9BdXRoIDIuMC4gIEJ5IGRlZmluaXRpb24sIGl0IG11 c3QgYWx3YXlzIGJlIHVzZWQgaW4gYW4gYXBwbGljYXRpb24gY29udGV4dCB0aGF0IHByb2ZpbGVz IE9BdXRoIDIuMCB0byBlbmFibGUgaW50ZXJvcGVyYWJpbGl0eS4gIFRoZSBleGlzdGluZyAvLndl bGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24gdmFsdWUgd29ya3MgZmluZSBmb3IgdGhpcyBw dXJwb3NlLiAgWWVzLCB0aGUgb3B0aWNzIG9mIGhhdmluZyBhIGRpZmZlcmVudCB2YWx1ZSBtaWdo dCBzZWVtIGJldHRlciBidXQgaXQgY29tZXMgYXQgdGhlIGNvc3Qgb2YgaW50ZXJvcGVyYWJpbGl0 eSBwcm9ibGVtcy4gIEluIG15IHZpZXcsIGludGVyb3AgdHJ1bXBzIG9wdGljcy4NCg0KVG8gYSBw b2ludCB0aGF0IEdlb3JnZSBGbGV0Y2hlciBtYWRlLCBXZWJGaW5nZXIgY291bGQgc3RpbGwgYmUg dXNlZCB0byBsZWFybiB0aGUgbG9jYXRpb25zIG9mIHRoZXNlIGNvbmZpZ3VyYXRpb24gbWV0YWRh dGEgZG9jdW1lbnRzIGlmIHRoYXQgbWFrZXMgc2Vuc2UgaW4gdGhlIGFwcGxpY2F0aW9uIGNvbnRl eHQuICBUaGUgZWRpdG9ycyB0b29rIFdlYkZpbmdlciBvdXQgb2YgdGhlIE9BdXRoIERpc2NvdmVy eSBkb2N1bWVudCBzaW5jZSBpdCBpc27igJl0IGFsd2F5cyBhcHBsaWNhYmxlLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJz LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UNCg0KRnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5j b21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgNzo0MSBBTQ0KVG86IFBoaWwg SHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE9BdXRoIERpc2NvdmVyeSBzcGVjIHBhcmVkIGRvd24gdG8gaXRzIGVzc2VuY2UNCg0KSSBzdXNw ZWN0IHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24gd2VsbC1rbm93bnMgYXJlIGdvaW5nIHRvIGJlIG9u IHRoZSByb290IGRvbWFpbi4gICBZb3UgY291bGQgdHJ5IGFuZCBnZXQgYSB1c2VyIHRvIHB1dCBp biBjcm0uZXhhbXBsZS5jb208aHR0cDovL2NybS5leGFtcGxlLmNvbT4sIGJ1dCBJIHN1c3BlY3Qg dGhhdCBpcyBub3QgZ29pbmcgdG8gd29yay4NCg0KSWYgdGhlIGFwcCBkb2VzbuKAmXQgaGF2ZSBh IHNwZWNpZmljIHByb3RvY29sIGlkZW50aWZpZXIgdGhlbiBpdCB3b3VsZCB1c2UgdGhlIGRlZmF1 bHQuDQoNCkkgZG9u4oCZdCBrbm93IGlmIHlvdSBjYW4gZ2V0IGFyb3VuZCBoYXZpbmcgc29tZSBz b3J0IG9mIGFwcC9wcm90b2NvbCBpZGVudGlmaWVyIGNvbmZpZ3VyZWQgaW4gdGhlIGFwcC4NCg0K Sm9obiBCLg0KDQoNCg0KDQoNCg0KT24gRmViIDE4LCAyMDE2LCBhdCA5OjQ5IEFNLCBQaGlsIEh1 bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdy b3RlOg0KDQpyZXNvdXJjZSBzZXJ2aWNlIFggY291bGQgYmUgYW55IGh0dHAgYWNjZXNzaWJsZSBz ZXJ2aWNlOg0KDQoqIENSTQ0KKiBGaW5hbmNlDQoqIFBheXJvbGwNCiogRVJQDQoqIGFueSBhcHBs aWNhdGlvbiBvbiB0aGUgd2ViLg0KDQpUaGUgc3BlYyBzZWVtcyB0byBzdWdnZXN0IHRoYXQgd2Ug dXNlIC8ud2VsbC1rbm93bi9jcm0gdG8gZGlzY292ZXIgT0F1dGggY29uZmlnIGZvciBjcm0uICBC dXQgdGhhdCBtYXkgY2F1c2UgY29uZmxpY3QgaWYgY3JtIGhhcyBpdHMgb3duIGRpc2NvdmVyeS4g V2hpY2ggbGVhZHMgdXMgZG93biB0aGUgcGF0aCBvZiBkb2luZyBzb21ldGhpbmcgbGlrZSDigJxj cm0tb2F1dGjigJ0uDQoNClRoZW4gdGhlcmUgaXMgY29uZnVzaW9uIGFib3V0IHdoYXQgaG9zdCB0 aGUgZGlzY292ZXJ5IGlzIGRvbmUgb24uDQoNCkZvciBleGFtcGxlLCBoeXBvdGhldGljYWxseSBk byBJIGRvOg0KDQpHRVQgLy53ZWxsLWtub3duL2NybQ0KSG9zdDogZXhhbXBsZS5jb208aHR0cDov L2V4YW1wbGUuY29tLz4NCg0KQnV0IHdoYXQgYWJvdXQgdGhlIENSTeKAmXMgY29uZmlndXJhdGlv biBpbmZvcm1hdGlvbi4gSXMgdGhpcyBzdG9tcGluZyBvbiBpdD8NCg0KT3IsIHdoYXQgSWYgd2Ug cHV0IHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGF0IHRoZSBob3N0IGZvciB0aGUgY3JtIHNlcnZp Y2U6DQpHRVQgLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uDQpIb3N0OiBjcm0uZXhh bXBsZS5jb208aHR0cDovL2NybS5leGFtcGxlLmNvbS8+DQoNCkkgdGhpbmsgdGhlIHBvaW50IGlz IHRoYXQgdGhlcmUgaXMgYSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHByb3RlY3RlZCByZXNvdXJj ZSBhbmQgaXRzIGRlc2lnbmF0ZWQgT0F1dGggc2VydmljZS4NCg0KVGhlIGNsaWVudCBuZWVkcyB0 byBkaXNjb3ZlcjoNCiogV2hlcmUgaXMgaXRzIGRlc2lnbmF0ZWQgcmVzb3VyY2Ugc2VydmljZSBh bmQgd2hhdCBzZWN1cml0eSBkb2VzIGl0IHVzZQ0KKiBJZiBpdCBpcyBPQXV0aCwgd2hlcmUgaXMg dGhlIGludGVuZGVkIE9BdXRoIGNvbmZpZ3VyYXRpb24gZm9yIHRoYXQgcmVzb3VyY2Ugc2Vydmlj ZSBpbnN0YW5jZT8NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQu Y29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208 bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpPbiBGZWIgMTgsIDIwMTYsIGF0 IDc6MTkgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tPj4gd3JvdGU6DQoNCkNhbiB5b3UgY2xhcmlmeSB3aGF0IHlvdSBtZWFuIGJ5IOKA nHJlc291cmNlIHNlcnZpY2UgeOKAnT8NCg0KSXMgdGhhdCB0aGUgUlMgYmFzZSBVUkkgZm9yIHRo ZSByZXNvdXJjZSwgIGEgc3BlY2lmaWMgVVJJIHRoYXQgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5n Pw0KDQpUaGF0IGlzIGdldHRpbmcgVU1BIGlzaC4NCg0KVGhlIGNvbmNlcHQgb2YgYSBiYXNlIFJT IFVSSSBpcyBhIHJhdCBob2xlIHRoYXQgSSBwcmVmZXIgbm90IHRvIGdvIGRvd24sIGFzIGl0IGlz IHNvbWV0aGluZyBldmVyeW9uZSB0aGlua3MgZXhpc3RzIGJ1dCBsaWtlIFNDSU0gaWYgaXQgZXhp c3RzIGl0IGlzIHByb3RvY29sIG9yIGRlcGxveW1lbnQgc3BlY2lmaWMuDQoNClRoZSBub3Rpb24g dGhhdCB5b3Ugd291bGQgc2VuZCB0aGUgVVJJIHlvdSBhcmUgcGxhbm5pbmcgb24gcmVxdWVzdGlu ZyB0byBhIFdlYmZpbmdlciBzZXJ2ZXIgdG8gZmluZCB0aGUgT0F1dGggc2VydmVyLCBpcyBwcm9i YWJseSBnb2luZyB0byBoYXZlIHByaXZhY3kgaXNzdWVzLg0KDQpJIHN1c3BlY3QgdGhhdCB5b3Ug bmVlZCB0byBoYW5kIGJhY2sgYSBlcnJvciBmcm9tIHRoZSByZXNvdXJjZSB0byBzYXkgd2hlcmUg dGhlIEFTIGlzLCBvciBoYXZlIGEgLndlbGwta25vd24gZm9yIHRoZSBSUy4NCg0KUlMgZGlzY292 ZXJ5IHByb2JhYmx5IHdhbnRzIHRvIGJlIHNlcGFyYXRlIGZyb20gQVMgZGlzY292ZXJ5LiAgKFll cyBJIGRvIHRoaW5rIHdlIG5lZWQgc29tZXRoaW5nLCAgVU1BIHJwdCBvciBzb21ldGhpbmcgbGlr ZSBpdCBtaWdodCBiZSBhIHdheSB0byBnbykNCg0KSm9obiBCLg0KDQpPbiBGZWIgMTgsIDIwMTYs IGF0IDk6MDYgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCk1heWJlIFNDSU0gd2FzIGEgYmFkIGV4YW1wbGUu ICBJdCBmdW5jdGlvbnMgYXMgYSBSRVNUZnVsIHJlc291cmNlIGluIHRoZSBjb250ZXh0IG9mIE9B dXRoLg0KDQpJIGZpbmQgdGhlIHVzZSBvZiBPSURDIHRvIGJlIGNvbmZ1c2luZyBhcyBhbiBleGFt cGxlIChhbmQgdGhlIGRlZmF1bHQpIGJlY2F1c2UgaXQgaXMgYm90aCBhbiBPQXV0aCByZXNvdXJj ZSBhbmQgYSBzZWN1cml0eSBzZXJ2aWNlLiAgSXQgaXMgYSBtb2RpZmljYXRpb24gb2YgT0F1dGgu DQoNClN0YXJ0IHRoaW5raW5nIGFib3V0IGV2ZXJ5IGFwcGxpY2F0aW9uIGV2ZXIgd3JpdHRlbiB0 aGF0IHVzZXMgT0F1dGguIEFyZSB3ZSBleHBlY3RpbmcgMTAwcyBvZiB0aG91c2FuZHMgb2YgdGhl c2UgdG8gZWFjaCByZWdpc3Rlcj8NCg0KVG8gbWUsIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhIGZp bmUgc3BlY2lmaWNhdGlvbiBmb3IgT0lEQyBhbmQgaXQgc2hvdWxkIGJlIHB1Ymxpc2hlZCB0aGVy ZSBiZWNhdXNlIHRoZSBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGRpc2NvdmVyeSBPQXV0 aCBhbmQgT3BlbklEIGluZm9ybWF0aW9uLg0KDQpMaWtld2lzZSB5b3Ugc3VnZ2VzdCBpdCBpcyBv ayBmb3IgU0NJTSB0byBkbyB0aGUgc2FtZS4NCg0KSG93IGRvIHdlIGV4cGVjdCBub3JtYWwgYXBw bGljYXRpb25zIHRvIHNldCB1cCBhbmQgZG8gZGlzY292ZXJ5Pw0KDQpJdCBzZWVtcyB0byBtZSB0 aGF0IGFuIOKAnE9BVVRI4oCdIGRpc2NvdmVyeSBzcGVjIHNob3VsZCBoYXZlIGEgcGFyYW1ldGVy IHRvIGFzaywgSSB3YW50IHRvIGRpc2NvdmVyIE9BdXRoIGNvbmZpZ3VyYXRpb24gZm9yIHJlc291 cmNlIHNlcnZpY2UgWC4NCg0KVGhhdCBzdGlsbCBhbGxvd3MgbWUgdG8gaGF2ZSBhIHNlcGFyYXRl IGRpc2NvdmVyeSBzZXJ2aWNlIHRoYXQgc2F5cywgdGVsbCBtZSBhYm91dCByZXNvdXJjZSBzZXJ2 aWNlIFggaXRzZWxmLg0KDQpCVFcuIEkgdGhpbmsgd2UgYXJlIEZBUiBmcm9tIExhc3QgQ2FsbCBv biB0aGlzIHRvcGljLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRp ZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIEZlYiAxOCwgMjAxNiwg YXQgNjo1NSBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRi QHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KRGlmZnJlbnQgcHJvdG9jb2xzIGxpa2UgQ29ubmVjdCBh bmQgU0NJTSBtYXkgaGF2ZSBkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMsIGVuZHBvaW50cyAsIGtl eXMgLCBhdXRoZW50aWNhdGlvbiBtZXRob2RzLCBzY29wZXMgZXRjLg0KDQpJdCBzaG91bGQgYmUg cG9zYWJsZSB0byBoYXZlIHRoZW0gYXMgb25lIGRvY3VtZW50LCBidXQgZm9yY2luZyB0aGVtIHRv IHVzZSBvbmUgZG9jdW1lbnQgaXMgZ29pbmcgdG8gY2F1c2UgYSBleHBsb3Npb24gb2YgY2xhaW0g cmVnaXN0cmF0aW9uIGZvciBkaXNjb3ZlcnkuDQoNCkkgdGhpbmsgaXQgaXMgYmV0dGVyIGZvciBT Q0lNIHRvIHJlZ2lzdGVyIG9uZSB3ZWxsIGtub3duIHRoYW4gdG8gaGF2ZSB0byByZWdpc3RlciAy MCBjbGFpbXMgd2l0aCBzY2ltIHByZWZpeGVzIG9yIHNvbWV0aGluZyBzaWxseSBsaWtlIHRoYXQu DQoNCk5hbWUtc3BhY2luZyB0aGUgY2xhaW1zIGJ5IGFsbG93aW5nIHRoZW0gdG8gYmUgaW4gZGlm ZmVyZW50IHdlbGwga25vd24gZmlsZXMgaXMgbm90IHVucmVhc29uYWJsZS4NCg0KUmVtZW1iZXIg c29tZSBvZiB0aGVzZSBwcm90b2NvbHMgbWF5IGJlIGhvc3RlZCBvbiBTYWFTIHNvIHRoZXJlIGlz IG5vIGd1YXJhbnRlZSB0aGF0IGFsbCBwcm90b2NvbHMgd2lsbCBoYXZlIHRoZSBzYW1lIE9BdXRo IENvbmZpZy4NCg0KTm90aGluZyBzdG9wcyBhIHByb3RvY29sIGZyb20gZG9pbmcgd2hhdCBpdCBs aWtlcyB3aXRoIHdlYmZpbmdlciBpZiBpdCB3YW50cyB0byB1c2UgdGhhdCBmb3IgZGlzY292ZXJ5 Lg0KDQpJbiBwcmluY2lwYWwgSSBsaWtlIHRoZSBpZGVhIG9mIGhhdmluZyBhbm90aGVyIHByb3Rv Y29sIGFzIGFuIGV4YW1wbGUuDQoNCk15IG9ubHkgY29uY2VybiBpcyB0aGF0IEkgaGF2ZW7igJl0 IHNlZW4gYW55IGRpc2N1c3Npb24gb2YgeW91ciBTQ0lNIGRpc2NvdmVyeSBkb2N1bWVudCBpbiB0 aGUgU0NJTSBXRy4NCkkgcGVyc29uYWxseSB0aGluayBzb3J0aW5nIG91dCBkaXNjb3ZlcnkgZm9y IFNDSU0gaXMgYSBnb29kIGlkZWEsICBidXQgT0FVVGggaXMgYnV0IG9uZSBvZiBzZXZlcmFsIGF1 dGhlbnRpY2F0aW9uIG1ldGhvZHMgZm9yIFNDSU0sIGFuZCB0aGVyZSBhcmUgcHJvYmFibHkgb3Ro ZXIgbm9uIE9BdXRoIHRoaW5ncyB0aGF0IHdhbnQgdG8gYmUgZGVzY3JpYmVkLg0KDQpJIHdvdWxk IGZlZWwgYmV0dGVyIGFib3V0IHVzaW5nIGl0IGFzIGFuIGV4YW1wbGUgaWYgaXQgd2VyZSBhZG9w dGVkIGJ5IHRoZSBXRyBhbmQgc29tZSBnZW5lcmFsIGludGVyZXN0IHNob3duLg0KDQpJIGVuY291 cmFnZSB5b3UgdG8gZG8gdGhhdCBzbyB3ZSBjYW4gdXNlIGl0IGFzIGEgZXhhbXBsZS4NCg0KSm9o biBCLg0KDQpPbiBGZWIgMTgsIDIwMTYsIGF0IDg6MzUgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkkgc3Rp bGwgZmluZCB0aGUgZm9sbG93aW5nIHRleHQgb2JqZWN0aW9uYWJsZSBhbmQgY29uZnVzaW5n4oCm DQoNCiAgIEJ5IGRlZmF1bHQsIGZvciBoaXN0b3JpY2FsIHJlYXNvbnMsIHVubGVzcyBhbiBhcHBs aWNhdGlvbi1zcGVjaWZpYw0KDQogICB3ZWxsLWtub3duIFVSSSBwYXRoIHN1ZmZpeCBpcyByZWdp c3RlcmVkIGFuZCB1c2VkIGZvciBhbiBhcHBsaWNhdGlvbiwNCg0KICAgdGhlIGNsaWVudCBmb3Ig dGhhdCBhcHBsaWNhdGlvbiBTSE9VTEQgdXNlIHRoZSB3ZWxsLWtub3duIFVSSSBwYXRoDQoNCiAg IHN1ZmZpeCAib3BlbmlkLWNvbmZpZ3VyYXRpb24iIGFuZCBwdWJsaXNoIHRoZSBtZXRhZGF0YSBk b2N1bWVudCBhdA0KDQogICB0aGUgcGF0aCBmb3JtZWQgYnkgY29uY2F0ZW5hdGluZyAiLy53ZWxs LWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIg0KDQogICB0byB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIncyBpc3N1ZXIgaWRlbnRpZmllci4gIEFzIGRlc2NyaWJlZCBpbg0KDQogICBTZWN0aW9u IDU8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zlcnkt MDEjc2VjdGlvbi01PiwgZGVzcGl0ZSB0aGUgaWRlbnRpZmllcg0KDQogICAiLy53ZWxsLWtub3du L29wZW5pZC1jb25maWd1cmF0aW9uIiwgYXBwZWFyaW5nIHRvIGJlIE9wZW5JRC1zcGVjaWZpYywN Cg0KICAgaXRzIHVzYWdlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJp bmcgdG8gYSBnZW5lcmFsDQoNCiAgIE9BdXRoIDIuMCBmZWF0dXJlIHRoYXQgaXMgbm90IHNwZWNp ZmljIHRvIE9wZW5JRCBDb25uZWN0Lg0KDQpGdXJ0aGVyLCBhcyBhIGRlZmF1bHQg4oCcb3Blbmlk LWNvbmZpZ3VyYXRpb27igJ0gYXMgdGhlIGRlZmF1bHQgZnVydGhlciBnaXZlcyBwZW9wbGUgdGhl IGltcHJlc3Npb24gdGhhdCBhIHBsYWluIE9BdXRoIHNlcnZlciAqaXMqIGFuIGF1dGhlbnRpY2F0 aW9uIHNlcnZlciBhbmQgdGhhdCB0aGUgbm9ybWFsIGFjY2VzcyB0b2tlbiByZWNlaXZlZCBpcyBl dmlkZW5jZSBvZiBhIHN1Y2Nlc3NmdWwgYXV0aGVudGljYXRpb24uDQoNCkl0IHdvdWxkIGJlIGJl dHRlciB0byBwb2ludCBvdXQgdGhhdCBhcHBsaWNhdGlvbiBtYXkgaW5jbHVkZSBvYXV0aCBkaXNj b3ZlcnkgaW4gdGhlaXIgZGlzY292ZXJ5IFVSSSBhbmQgdGhhdCBPQXV0aCBpcyBhbiBleGFtcGxl IG9mIHRoaXMuIEl0IG1pZ2h0IGJlIGdvb2QgdG8gaW5jbHVkZSB0d28gZXhhbXBsZXMuICBFLmcu IE9JREMgYW5kIFNDSU0gKGFzIGFub3RoZXIgcmVmZXJlbmNlYWJsZSBleGFtcGxlKS4NCg0KDQog R0VUIC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbg0KYW5kDQoNCiBHRVQgLy53ZWxs LWtub3duL3NjaW0NClJldHJpZXZlIHRoZSBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGUgYXBw bGljYXRpb24gb3BlbmlkIGFuZCBzY2ltIHJlc3BlY3RpdmVseS4NCg0KVGhlIHVzZSBvZjoNCg0K IEdFVCAvLndlbGwta25vd24vb2F1dGgyLw0KU2hvdWxkIGJlIHRoZSBkZWZhdWx0IHVzZWQgd2hl biB0aGVyZSBpcyBubyBrbm93biBhcHBsaWNhdGlvbiBiYXNlZCB3ZWxsLWtub3duIGFwcGxpY2F0 aW9uIGJhc2VkIFVSSSBkaXNjb3ZlcnkuDQoNCk9mIGNvdXJzZSwgdGhlIGNvbmNlcm4gSSByYWlz ZWQgZWFybGllciBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggb2YgYXBwbGljYXRpb24gc3BlY2lmaWMg VVJJcyBlbmRzIHVwIHJlcXVpcmluZyBldmVyeSBhcHBsaWNhdGlvbiB0byBtYWtlIGFuIElBTkEg cmVnaXN0cmF0aW9uIGlmIHRoZXkgZG9u4oCZdCB3YW50IHRvIHVzZSB0aGUgZGVmYXVsdCBvZiDi gJxvYXV0aDLigJ0gKG9yIOKAnG9wZW5pZC1jb25maWd1cmF0aW9u4oCdKS4gIElzIHRoYXQgd2hh dCB0aGUgYXV0aG9ycyBleHBlY3Q/DQoNCkl0IHNlZW1lZCBiZXR0ZXIgdG8gbWUgdG8gdXNlIHRo ZSB3ZWJmaW5nZXIgc3ludGF4IHRvIGFsbG93IHRoZSBjbGllbnQgdG8gc2F5IOKAnEkgd2FudCB0 aGUgZGVzaWduYXRlZCBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGUgcmVzb3VyY2Ugc2Vydmlj ZSBY4oCdIHdvdWxkIGJlIGEgYmV0dGVyIGRlc2lnbiB0aGF0IGF2b2lkcyBleHRlbnNpdmUgSUFO QSByZWdpc3RyYXRpb24uDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVu dGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gRmViIDE3LCAyMDE2 LCBhdCAxMTo0OCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSW4gcmVzcG9uc2Ug dG8gd29ya2luZyBncm91cCBpbnB1dCwgdGhpcyB2ZXJzaW9uIG9mIHRoZSBPQXV0aCBEaXNjb3Zl cnkgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlIOKAkyBs ZWF2aW5nIG9ubHkgdGhlIGZlYXR1cmVzIHRoYXQgYXJlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVk LiAgU3BlY2lmaWNhbGx5LCBhbGwgdGhhdCByZW1haW5zIGlzIHRoZSBkZWZpbml0aW9uIG9mIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgYW5kIHRo ZSBtZXRhZGF0YSB2YWx1ZXMgdXNlZCBpbiBpdC4gIFRoZSBXZWJGaW5nZXIgZGlzY292ZXJ5IGxv Z2ljIGhhcyBiZWVuIHJlbW92ZWQuICBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGlzc3Vl ciBpZGVudGlmaWVyIFVSTCBhbmQgdGhlIHdlbGwta25vd24gVVJJIHBhdGggcmVsYXRpdmUgdG8g aXQgYXQgd2hpY2ggdGhlIGRpc2NvdmVyeSBtZXRhZGF0YSBkb2N1bWVudCBpcyBsb2NhdGVkIGhh cyBhbHNvIGJlZW4gY2xhcmlmaWVkLg0KDQpHaXZlbiB0aGF0IHRoaXMgbm93IGRlc2NyaWJlcyBv bmx5IGZlYXR1cmVzIHRoYXQgYXJlIGluIHdpZGVzcHJlYWQgZGVwbG95bWVudCwgdGhlIGVkaXRv cnMgYmVsaWV2ZSB0aGF0IHRoaXMgdmVyc2lvbiBpcyByZWFkeSBmb3Igd29ya2luZyBncm91cCBs YXN0IGNhbGwuDQoNClRoZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDoNCuKAoiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0w MQ0KDQpBbiBIVE1MLWZvcm1hdHRlZCB2ZXJzaW9uIGlzIGFsc28gYXZhaWxhYmxlIGF0Og0K4oCi ICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1kaXNj b3ZlcnktMDEuaHRtbA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZSAmIE5hdCAmIEpvaG4NCg0KUC5TLiAgVGhpcyBub3Rp Y2Ugd2FzIGFsc28gcG9zdGVkIGF0IGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE1NDQgYW5k IGFzIEBzZWxmaXNzdWVkPGh0dHBzOi8vdHdpdHRlci5jb20vc2VsZmlzc3VlZD4uDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KDQo= --_000_BY2PR03MB4425DF67B0BB624401EE7A0F5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bh bjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo3MTcyNDA1NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjc1OTUzODAwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ TGV0IG1lIHNlY29uZCBKb2hu4oCZcyBwb2ludCB0aGF0IE9BdXRoIGNvbmZpZ3VyYXRpb24gaW5m b3JtYXRpb24gYW5kIGFwcGxpY2F0aW9uIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbmVlZCBu b3QgYmUgaW50ZXJzcGVyc2VkLiZuYnNwOyBGb3IgaW5zdGFuY2UsIGlmIHRoZSBzZXJ2aWNlDQog aXMgYXQgPGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbSI+aHR0cHM6Ly9leGFtcGxlLmNvbTwv YT4gYW5kIHRoZSBYWVogYXBwbGljYXRpb24gaXMgYmVpbmcgdXNlZCwgdGhlbiB0aGVzZSBjb25m aWd1cmF0aW9uIG1ldGFkYXRhIGRvY3VtZW50cyBjb3VsZCBib3RoIGJlIHVzZWQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjoj MDAyMDYwIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vLndlbGwt a25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24iPmh0dHBzOi8vZXhhbXBsZS5jb20vLndlbGwta25v d24vb3BlbmlkLWNvbmZpZ3VyYXRpb248L2E+IC0gT0F1dGggY29uZmlndXJhdGlvbiBtZXRhZGF0 YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1i b2w7Y29sb3I6IzAwMjA2MCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48YSBocmVmPSJodHRwczovL2V4YW1wbGUu Y29tLy53ZWxsLWtub3duL3h5ei1jb25maWd1cmF0aW9uIj5odHRwczovL2V4YW1wbGUuY29tLy53 ZWxsLWtub3duL3h5ei1jb25maWd1cmF0aW9uPC9hPiAtIFhZWiBjb25maWd1cmF0aW9uIG1ldGFk YXRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGVyZeKAmXMg bm90IG11Y2ggcG9pbnQgaW4gZGVmaW5pbmcgYSBuZXcgLy53ZWxsLWtub3duL29hdXRoMi4wIHZh bHVlLCBzaW5jZSB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGdlbmVyaWMgT0F1dGggMi4wLiZu YnNwOyBCeSBkZWZpbml0aW9uLCBpdCBtdXN0IGFsd2F5cyBiZSB1c2VkDQogaW4gYW4gYXBwbGlj YXRpb24gY29udGV4dCB0aGF0IHByb2ZpbGVzIE9BdXRoIDIuMCB0byBlbmFibGUgaW50ZXJvcGVy YWJpbGl0eS4mbmJzcDsgVGhlIGV4aXN0aW5nIC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJh dGlvbiB2YWx1ZSB3b3JrcyBmaW5lIGZvciB0aGlzIHB1cnBvc2UuJm5ic3A7IFllcywgdGhlIG9w dGljcyBvZiBoYXZpbmcgYSBkaWZmZXJlbnQgdmFsdWUgbWlnaHQgc2VlbSBiZXR0ZXIgYnV0IGl0 IGNvbWVzIGF0IHRoZSBjb3N0IG9mIGludGVyb3BlcmFiaWxpdHkNCiBwcm9ibGVtcy4mbmJzcDsg SW4gbXkgdmlldywgaW50ZXJvcCB0cnVtcHMgb3B0aWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMjA2MCI+VG8gYSBwb2ludCB0aGF0IEdlb3JnZSBGbGV0Y2hlciBtYWRl LCBXZWJGaW5nZXIgY291bGQgc3RpbGwgYmUgdXNlZCB0byBsZWFybiB0aGUgbG9jYXRpb25zIG9m IHRoZXNlIGNvbmZpZ3VyYXRpb24gbWV0YWRhdGEgZG9jdW1lbnRzIGlmIHRoYXQgbWFrZXMgc2Vu c2UgaW4gdGhlDQogYXBwbGljYXRpb24gY29udGV4dC4mbmJzcDsgVGhlIGVkaXRvcnMgdG9vayBX ZWJGaW5nZXIgb3V0IG9mIHRoZSBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgc2luY2UgaXQgaXNu 4oCZdCBhbHdheXMgYXBwbGljYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3Nw YW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g Sm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDc6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFBo aWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtl IEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBEaXNjb3Zlcnkgc3Bl YyBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24gd2VsbC1r bm93bnMgYXJlIGdvaW5nIHRvIGJlIG9uIHRoZSByb290IGRvbWFpbi4gJm5ic3A7IFlvdSBjb3Vs ZCB0cnkgYW5kIGdldCBhIHVzZXIgdG8gcHV0IGluDQo8YSBocmVmPSJodHRwOi8vY3JtLmV4YW1w bGUuY29tIj5jcm0uZXhhbXBsZS5jb208L2E+LCBidXQgSSBzdXNwZWN0IHRoYXQgaXMgbm90IGdv aW5nIHRvIHdvcmsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB0aGUgYXBwIGRvZXNu4oCZdCBoYXZlIGEgc3BlY2lmaWMgcHJvdG9jb2wgaWRlbnRpZmll ciB0aGVuIGl0IHdvdWxkIHVzZSB0aGUgZGVmYXVsdC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IGlmIHlv dSBjYW4gZ2V0IGFyb3VuZCBoYXZpbmcgc29tZSBzb3J0IG9mIGFwcC9wcm90b2NvbCBpZGVudGlm aWVyIGNvbmZpZ3VyZWQgaW4gdGhlIGFwcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDE4LCAyMDE2LCBhdCA5OjQ5IEFNLCBQaGls IEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50 QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJlc291cmNlIHNlcnZpY2UgWCBjb3VsZCBiZSBhbnkgaHR0cCBhY2Nl c3NpYmxlIHNlcnZpY2U6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4qIENSTTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KiBGaW5hbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qIFBheXJvbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiogRVJQPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qIGFueSBhcHBsaWNhdGlvbiBvbiB0aGUgd2ViLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3BlYyBzZWVt cyB0byBzdWdnZXN0IHRoYXQgd2UgdXNlIC8ud2VsbC1rbm93bi9jcm0gdG8gZGlzY292ZXIgT0F1 dGggY29uZmlnIGZvciBjcm0uICZuYnNwO0J1dCB0aGF0IG1heSBjYXVzZSBjb25mbGljdCBpZiBj cm0gaGFzIGl0cyBvd24gZGlzY292ZXJ5LiBXaGljaCBsZWFkcyB1cyBkb3duIHRoZSBwYXRoIG9m IGRvaW5nIHNvbWV0aGluZyBsaWtlIOKAnGNybS1vYXV0aOKAnS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiB0aGVyZSBpcyBjb25mdXNp b24gYWJvdXQgd2hhdCBob3N0IHRoZSBkaXNjb3ZlcnkgaXMgZG9uZSBvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGh5 cG90aGV0aWNhbGx5IGRvIEkgZG86PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdFVCAvLndlbGwta25vd24vY3JtPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3N0OiA8YSBocmVmPSJodHRwOi8v ZXhhbXBsZS5jb20vIj5leGFtcGxlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHdoYXQgYWJvdXQgdGhlIENSTeKAmXMgY29u ZmlndXJhdGlvbiBpbmZvcm1hdGlvbi4gSXMgdGhpcyBzdG9tcGluZyBvbiBpdD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IsIHdoYXQgSWYg d2UgcHV0IHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGF0IHRoZSBob3N0IGZvciB0aGUgY3JtIHNl cnZpY2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+R0VUIC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG9zdDogPGEgaHJlZj0i aHR0cDovL2NybS5leGFtcGxlLmNvbS8iPmNybS5leGFtcGxlLmNvbTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IHRoZSBwb2ludCBpcyB0aGF0IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBwcm90 ZWN0ZWQgcmVzb3VyY2UgYW5kIGl0cyBkZXNpZ25hdGVkIE9BdXRoIHNlcnZpY2UuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBj bGllbnQgbmVlZHMgdG8gZGlzY292ZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFdoZXJlIGlzIGl0cyBkZXNpZ25hdGVkIHJlc291cmNlIHNl cnZpY2UgYW5kIHdoYXQgc2VjdXJpdHkgZG9lcyBpdCB1c2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogSWYgaXQgaXMgT0F1dGgsIHdoZXJlIGlz IHRoZSBpbnRlbmRlZCBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGF0IHJlc291cmNlIHNlcnZp Y2UgaW5zdGFuY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bS8iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGZWIgMTgsIDIwMTYsIGF0IDc6MTkgQU0sIEpvaG4gQnJhZGxleSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2FuIHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4gYnkg4oCccmVzb3VyY2Ugc2VydmljZSB44oCd PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhhdCB0 aGUgUlMgYmFzZSBVUkkgZm9yIHRoZSByZXNvdXJjZSwgJm5ic3A7YSBzcGVjaWZpYyBVUkkgdGhh dCB0aGUgY2xpZW50IGlzIHJlcXVlc3Rpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgZ2V0dGluZyBVTUEgaXNoLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg Y29uY2VwdCBvZiBhIGJhc2UgUlMgVVJJIGlzIGEgcmF0IGhvbGUgdGhhdCBJIHByZWZlciBub3Qg dG8gZ28gZG93biwgYXMgaXQgaXMgc29tZXRoaW5nIGV2ZXJ5b25lIHRoaW5rcyBleGlzdHMgYnV0 IGxpa2UgU0NJTSBpZiBpdCBleGlzdHMgaXQgaXMgcHJvdG9jb2wgb3IgZGVwbG95bWVudCBzcGVj aWZpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIG5vdGlvbiB0aGF0IHlvdSB3b3VsZCBzZW5kIHRoZSBVUkkgeW91IGFyZSBwbGFubmlu ZyBvbiByZXF1ZXN0aW5nIHRvIGEgV2ViZmluZ2VyIHNlcnZlciB0byBmaW5kIHRoZSBPQXV0aCBz ZXJ2ZXIsIGlzIHByb2JhYmx5IGdvaW5nIHRvIGhhdmUgcHJpdmFjeSBpc3N1ZXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VzcGVjdCB0 aGF0IHlvdSBuZWVkIHRvIGhhbmQgYmFjayBhIGVycm9yIGZyb20gdGhlIHJlc291cmNlIHRvIHNh eSB3aGVyZSB0aGUgQVMgaXMsIG9yIGhhdmUgYSAud2VsbC1rbm93biBmb3IgdGhlIFJTLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SUyBkaXNj b3ZlcnkgcHJvYmFibHkgd2FudHMgdG8gYmUgc2VwYXJhdGUgZnJvbSBBUyBkaXNjb3ZlcnkuICZu YnNwOyhZZXMgSSBkbyB0aGluayB3ZSBuZWVkIHNvbWV0aGluZywgJm5ic3A7VU1BIHJwdCBvciBz b21ldGhpbmcgbGlrZSBpdCBtaWdodCBiZSBhIHdheSB0byBnbyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRmViIDE4LCAyMDE2LCBhdCA5OjA2IEFNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIFND SU0gd2FzIGEgYmFkIGV4YW1wbGUuICZuYnNwO0l0IGZ1bmN0aW9ucyBhcyBhIFJFU1RmdWwgcmVz b3VyY2UgaW4gdGhlIGNvbnRleHQgb2YgT0F1dGguPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZpbmQgdGhlIHVzZSBvZiBPSURDIHRvIGJlIGNvbmZ1c2lu ZyBhcyBhbiBleGFtcGxlIChhbmQgdGhlIGRlZmF1bHQpIGJlY2F1c2UgaXQgaXMgYm90aCBhbiBP QXV0aCByZXNvdXJjZSBhbmQgYSBzZWN1cml0eSBzZXJ2aWNlLiAmbmJzcDtJdCBpcyBhIG1vZGlm aWNhdGlvbiBvZiBPQXV0aC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlN0YXJ0IHRoaW5raW5nIGFib3V0IGV2ZXJ5IGFwcGxpY2F0aW9uIGV2ZXIgd3JpdHRl biB0aGF0IHVzZXMgT0F1dGguIEFyZSB3ZSBleHBlY3RpbmcgMTAwcyBvZiB0aG91c2FuZHMgb2Yg dGhlc2UgdG8gZWFjaCByZWdpc3Rlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbWUsIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhIGZpbmUg c3BlY2lmaWNhdGlvbiBmb3IgT0lEQyBhbmQgaXQgc2hvdWxkIGJlIHB1Ymxpc2hlZCB0aGVyZSBi ZWNhdXNlIHRoZSBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGRpc2NvdmVyeSBPQXV0aCBh bmQgT3BlbklEIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5MaWtld2lzZSB5b3Ugc3VnZ2VzdCBpdCBpcyBvayBmb3IgU0NJ TSB0byBkbyB0aGUgc2FtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkbyB3ZSBleHBlY3Qgbm9ybWFsIGFwcGxp Y2F0aW9ucyB0byBzZXQgdXAgYW5kIGRvIGRpc2NvdmVyeT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0 aGF0IGFuIOKAnE9BVVRI4oCdIGRpc2NvdmVyeSBzcGVjIHNob3VsZCBoYXZlIGEgcGFyYW1ldGVy IHRvIGFzaywgSSB3YW50IHRvIGRpc2NvdmVyIE9BdXRoIGNvbmZpZ3VyYXRpb24gZm9yIHJlc291 cmNlIHNlcnZpY2UgWC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCBzdGlsbCBhbGxvd3MgbWUgdG8gaGF2ZSBhIHNlcGFyYXRlIGRpc2Nv dmVyeSBzZXJ2aWNlIHRoYXQgc2F5cywgdGVsbCBtZSBhYm91dCByZXNvdXJjZSBzZXJ2aWNlIFgg aXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CVFcuIEkgdGhpbmsgd2UgYXJlIEZBUiBmcm9tIExhc3QgQ2FsbCBvbiB0aGlzIHRvcGlj LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBo aWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRmViIDE4LCAyMDE2LCBhdCA2OjU1IEFNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZmZyZW50IHBy b3RvY29scyBsaWtlIENvbm5lY3QgYW5kIFNDSU0gbWF5IGhhdmUgZGlmZmVyZW50IGNvbmZpZ3Vy YXRpb25zLCBlbmRwb2ludHMgLCBrZXlzICwgYXV0aGVudGljYXRpb24gbWV0aG9kcywgc2NvcGVz IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNo b3VsZCBiZSBwb3NhYmxlIHRvIGhhdmUgdGhlbSBhcyBvbmUgZG9jdW1lbnQsIGJ1dCBmb3JjaW5n IHRoZW0gdG8gdXNlIG9uZSBkb2N1bWVudCBpcyBnb2luZyB0byBjYXVzZSBhIGV4cGxvc2lvbiBv ZiBjbGFpbSByZWdpc3RyYXRpb24gZm9yIGRpc2NvdmVyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyBiZXR0ZXIgZm9y IFNDSU0gdG8gcmVnaXN0ZXIgb25lIHdlbGwga25vd24gdGhhbiB0byBoYXZlIHRvIHJlZ2lzdGVy IDIwIGNsYWltcyB3aXRoIHNjaW0gcHJlZml4ZXMgb3Igc29tZXRoaW5nIHNpbGx5IGxpa2UgdGhh dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TmFtZS1zcGFjaW5nIHRoZSBjbGFpbXMgYnkgYWxsb3dpbmcgdGhlbSB0byBiZSBpbiBkaWZmZXJl bnQgd2VsbCBrbm93biBmaWxlcyBpcyBub3QgdW5yZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZW1lbWJlciBzb21lIG9mIHRo ZXNlIHByb3RvY29scyBtYXkgYmUgaG9zdGVkIG9uIFNhYVMgc28gdGhlcmUgaXMgbm8gZ3VhcmFu dGVlIHRoYXQgYWxsIHByb3RvY29scyB3aWxsIGhhdmUgdGhlIHNhbWUgT0F1dGggQ29uZmlnLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Ro aW5nIHN0b3BzIGEgcHJvdG9jb2wgZnJvbSBkb2luZyB3aGF0IGl0IGxpa2VzIHdpdGggd2ViZmlu Z2VyIGlmIGl0IHdhbnRzIHRvIHVzZSB0aGF0IGZvciBkaXNjb3ZlcnkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHByaW5jaXBhbCBJIGxp a2UgdGhlIGlkZWEgb2YgaGF2aW5nIGFub3RoZXIgcHJvdG9jb2wgYXMgYW4gZXhhbXBsZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgb25s eSBjb25jZXJuIGlzIHRoYXQgSSBoYXZlbuKAmXQgc2VlbiBhbnkgZGlzY3Vzc2lvbiBvZiB5b3Vy IFNDSU0gZGlzY292ZXJ5IGRvY3VtZW50IGluIHRoZSBTQ0lNIFdHLiAmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxseSB0 aGluayBzb3J0aW5nIG91dCBkaXNjb3ZlcnkgZm9yIFNDSU0gaXMgYSBnb29kIGlkZWEsICZuYnNw O2J1dCBPQVVUaCBpcyBidXQgb25lIG9mIHNldmVyYWwgYXV0aGVudGljYXRpb24gbWV0aG9kcyBm b3IgU0NJTSwgYW5kIHRoZXJlIGFyZSBwcm9iYWJseSBvdGhlciBub24gT0F1dGggdGhpbmdzIHRo YXQgd2FudCB0byBiZSBkZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgZmVlbCBiZXR0ZXIgYWJvdXQgdXNpbmcgaXQg YXMgYW4gZXhhbXBsZSBpZiBpdCB3ZXJlIGFkb3B0ZWQgYnkgdGhlIFdHIGFuZCBzb21lIGdlbmVy YWwgaW50ZXJlc3Qgc2hvd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgZW5jb3VyYWdlIHlvdSB0byBkbyB0aGF0IHNvIHdlIGNhbiB1c2Ug aXQgYXMgYSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTgsIDIwMTYsIGF0IDg6MzUgQU0sIFBoaWwgSHVu dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgc3RpbGwgZmluZCB0aGUgZm9sbG93aW5nIHRleHQgb2JqZWN0 aW9uYWJsZSBhbmQgY29uZnVzaW5n4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBCeSBkZWZh dWx0LCBmb3IgaGlzdG9yaWNhbCByZWFzb25zLCB1bmxlc3MgYW4gYXBwbGljYXRpb24tc3BlY2lm aWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij4mbmJzcDsmbmJzcDsgd2VsbC1rbm93biBVUkkgcGF0aCBzdWZmaXggaXMgcmVnaXN0ZXJlZCBh bmQgdXNlZCBmb3IgYW4gYXBwbGljYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IHRoZSBjbGllbnQgZm9yIHRo YXQgYXBwbGljYXRpb24gU0hPVUxEIHVzZSB0aGUgd2VsbC1rbm93biBVUkkgcGF0aDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZu YnNwOyBzdWZmaXggJnF1b3Q7b3BlbmlkLWNvbmZpZ3VyYXRpb24mcXVvdDsgYW5kIHB1Ymxpc2gg dGhlIG1ldGFkYXRhIGRvY3VtZW50IGF0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IHRoZSBwYXRoIGZvcm1lZCBieSBj b25jYXRlbmF0aW5nICZxdW90Oy8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PiZuYnNwOyZuYnNwOyB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBpc3N1ZXIgaWRlbnRp Zmllci4mbmJzcDsgQXMgZGVzY3JpYmVkIGluPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxI3NlY3Rpb24t NSI+U2VjdGlvbiA1PC9hPiwgZGVzcGl0ZSB0aGUgaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyAmcXVv dDsvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24mcXVvdDssIGFwcGVhcmluZyB0byBi ZSBPcGVuSUQtc3BlY2lmaWMsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IGl0cyB1c2FnZSBpbiB0aGlzIHNwZWNpZmlj YXRpb24gaXMgYWN0dWFsbHkgcmVmZXJyaW5nIHRvIGEgZ2VuZXJhbDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBPQXV0 aCAyLjAgZmVhdHVyZSB0aGF0IGlzIG5vdCBzcGVjaWZpYyB0byBPcGVuSUQgQ29ubmVjdC48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GdXJ0 aGVyLCBhcyBhIGRlZmF1bHQg4oCcb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0gYXMgdGhlIGRlZmF1 bHQgZnVydGhlciBnaXZlcyBwZW9wbGUgdGhlIGltcHJlc3Npb24gdGhhdCBhIHBsYWluIE9BdXRo IHNlcnZlciAqaXMqIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBhbmQgdGhhdCB0aGUgbm9ybWFs IGFjY2VzcyB0b2tlbiByZWNlaXZlZCBpcyBldmlkZW5jZSBvZiBhIHN1Y2Nlc3NmdWwgYXV0aGVu dGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IHdvdWxkIGJlIGJldHRlciB0byBwb2ludCBvdXQgdGhhdCBhcHBsaWNhdGlvbiBt YXkgaW5jbHVkZSBvYXV0aCBkaXNjb3ZlcnkgaW4gdGhlaXIgZGlzY292ZXJ5IFVSSSBhbmQgdGhh dCBPQXV0aCBpcyBhbiBleGFtcGxlIG9mIHRoaXMuIEl0IG1pZ2h0IGJlIGdvb2QgdG8gaW5jbHVk ZSB0d28gZXhhbXBsZXMuICZuYnNwO0UuZy4gT0lEQyBhbmQgU0NJTSAoYXMgYW5vdGhlciByZWZl cmVuY2VhYmxlIGV4YW1wbGUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiBHRVQgLy53ZWxsLWtub3duL29wZW5p ZC1jb25maWd1cmF0aW9uPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4gR0VUIC8ud2VsbC1rbm93bi9zY2ltPG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZXRyaWV2ZSB0aGUgT0F1dGggY29uZmlndXJhdGlvbiBmb3IgdGhlIGFwcGxpY2F0aW9uIG9wZW5p ZCBhbmQgc2NpbSByZXNwZWN0aXZlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHVzZSBvZjo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+IEdF VCAvLndlbGwta25vd24vb2F1dGgyLzxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2hvdWxkIGJlIHRoZSBkZWZhdWx0IHVzZWQgd2hlbiB0aGVyZSBpcyBubyBr bm93biBhcHBsaWNhdGlvbiBiYXNlZCB3ZWxsLWtub3duIGFwcGxpY2F0aW9uIGJhc2VkIFVSSSBk aXNjb3ZlcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T2YgY291cnNlLCB0aGUgY29uY2VybiBJIHJhaXNlZCBlYXJsaWVyIGlz IHRoYXQgdGhpcyBhcHByb2FjaCBvZiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBVUklzIGVuZHMgdXAg cmVxdWlyaW5nIGV2ZXJ5IGFwcGxpY2F0aW9uIHRvIG1ha2UgYW4gSUFOQSByZWdpc3RyYXRpb24g aWYgdGhleSBkb27igJl0IHdhbnQgdG8gdXNlIHRoZSBkZWZhdWx0IG9mIOKAnG9hdXRoMuKAnSAo b3Ig4oCcb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0pLiAmbmJzcDtJcw0KIHRoYXQgd2hhdCB0aGUg YXV0aG9ycyBleHBlY3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0IHNlZW1lZCBiZXR0ZXIgdG8gbWUgdG8gdXNlIHRoZSB3ZWJmaW5nZXIg c3ludGF4IHRvIGFsbG93IHRoZSBjbGllbnQgdG8gc2F5IOKAnEkgd2FudCB0aGUgZGVzaWduYXRl ZCBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGUgcmVzb3VyY2Ugc2VydmljZSBY4oCdIHdvdWxk IGJlIGEgYmV0dGVyIGRlc2lnbiB0aGF0IGF2b2lkcyBleHRlbnNpdmUgSUFOQSByZWdpc3RyYXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iPnd3dy5p bmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGZWIgMTcsIDIwMTYsIGF0IDExOjQ4IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gcmVzcG9uc2UgdG8gd29ya2luZyBncm91cCBp bnB1dCwgdGhpcyB2ZXJzaW9uIG9mIHRoZSBPQXV0aCBEaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbiBo YXMgYmVlbiBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlIOKAkyBsZWF2aW5nIG9ubHkgdGhlIGZl YXR1cmVzIHRoYXQgYXJlIGFscmVhZHkgd2lkZWx5DQogZGVwbG95ZWQuJm5ic3A7IFNwZWNpZmlj YWxseSwgYWxsIHRoYXQgcmVtYWlucyBpcyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZGlzY292ZXJ5IG1ldGFkYXRhIGRvY3VtZW50IGFuZCB0aGUgbWV0YWRhdGEg dmFsdWVzIHVzZWQgaW4gaXQuICZuYnNwO1RoZSBXZWJGaW5nZXIgZGlzY292ZXJ5IGxvZ2ljIGhh cyBiZWVuIHJlbW92ZWQuJm5ic3A7IFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgaXNzdWVy IGlkZW50aWZpZXIgVVJMIGFuZA0KIHRoZSB3ZWxsLWtub3duIFVSSSBwYXRoIHJlbGF0aXZlIHRv IGl0IGF0IHdoaWNoIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgaXMgbG9jYXRlZCBo YXMgYWxzbyBiZWVuIGNsYXJpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+R2l2ZW4gdGhhdCB0aGlzIG5vdyBkZXNjcmliZXMgb25seSBmZWF0dXJlcyB0 aGF0IGFyZSBpbiB3aWRlc3ByZWFkIGRlcGxveW1lbnQsIHRoZSBlZGl0b3JzIGJlbGlldmUgdGhh dCB0aGlzIHZlcnNpb24gaXMgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgc3BlY2lmaWNhdGlv biBpcyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wMSI+PHNw YW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW4gSFRNTC1m b3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1v YXV0aC1kaXNjb3ZlcnktMDEuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHA6 Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEuaHRt bDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlICZhbXA7IE5hdCAmYW1wOyBKb2huPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlAuUy4mbmJzcDsgVGhp cyBub3RpY2Ugd2FzIGFsc28gcG9zdGVkIGF0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE1 NDQiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/ cD0xNTQ0PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+YW5kDQogYXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIj48c3BhbiBz dHlsZT0iY29sb3I6Izk1NEY3MiI+QHNlbGZpc3N1ZWQ8L3NwYW4+PC9hPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1 NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1 dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB4425DF67B0BB624401EE7A0F5AF0BY2PR03MB442namprd_-- From nobody Thu Feb 18 08:51:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CFD1B29B5 for ; Thu, 18 Feb 2016 08:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 0qd0R-UCwJ8c for ; Thu, 18 Feb 2016 08:51:49 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6434A1B29B3 for ; Thu, 18 Feb 2016 08:51:49 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id 5so17209536igt.0 for ; Thu, 18 Feb 2016 08:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bBgCQvfZAnSNNuONl8GWBkWFLFgxUB5If2WdI6Db4NI=; b=xuAnAUqfD5X/8Gc/R58R4WkK6bZm7zJ8fkfzobwJu44I5l3x2anP7Xzsa23gHqccoe ZKmKAfdjov/SEf/o3QOJzqkPVHriqDQ/EaQicO/+kwChVJBSDaSJhZDGvDSwwuDaloSo 8k/Qbjc7aiUbaJH4ARVJ0mS6M2Q8WIfhEYYtfe/PtL9QUUapx8sJF/x+hVJ4vFb7Kgr3 h4xtwFZeqIlvFC5/IOynLNX5XbNWBSGxpE9UcTRSC4L6p0yU6VpNJCenSHrl6fQ+DbDf KlofHVGma2ivRQuDaBfkbFUGR6U1ZDrQOv76WV8h/Mrb3qNkvmPmaWc6e/I5ZRH3ai5G tszA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=bBgCQvfZAnSNNuONl8GWBkWFLFgxUB5If2WdI6Db4NI=; b=eG40kVScUtbvOf7i55Dj/PVWdXTP5h+qu+IA7eVXH1WQATHELsrQMKWZ1A7AKCj3tQ ayR433LVRbE3eEbF/0rZ6/9GxJGvpFWfsiGyXjlJ2WR68d7k0Drx0t4+mL7F2ULxEnRR Y1jrPY2RUf/mf0p9iOD0OiUR9mdQgNF/SFpngFb1Sx2nOf5Gcolviq7WWm1SQc+WmbpO Os4WNaIGCwYEzaGgT6x2p8s1DTWgweQz43ITYV5rKTs1fCsRozfakQJ8eSXzeIMmM85A KuVjljzaeI7aI4fHpvBWZNdS0nb3pGvLeRfExlseQRKl04bmUXarmSYLPNCFKLkZyyd2 RZMQ== X-Gm-Message-State: AG10YOSX1aY2U0R2RcuZCx9oGUx1YcCPNBb5zfny7pQIrmQvrmYF5JJy280coFO1Er5mQA== X-Received: by 10.50.150.69 with SMTP id ug5mr4449237igb.8.1455814308750; Thu, 18 Feb 2016 08:51:48 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id o7sm1690157igv.0.2016.02.18.08.51.47 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 08:51:47 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id z135so80363273iof.0 for ; Thu, 18 Feb 2016 08:51:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.129.228 with SMTP id l97mr10130378ioi.76.1455814307061; Thu, 18 Feb 2016 08:51:47 -0800 (PST) Received: by 10.36.6.85 with HTTP; Thu, 18 Feb 2016 08:51:47 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 08:51:47 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: Mike Jones , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113f9124a1d385052c0e2e8b Archived-At: Subject: Re: [OAUTH-WG] Initial OAuth working group Device Flow specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:51:51 -0000 --001a113f9124a1d385052c0e2e8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had previously made some comments on this back in November, but never heard any response. These were things I ran into while implementing the device flow on one of my servers. https://mailarchive.ietf.org/arch/msg/oauth/JzH-isRij9kCpbEJpXVqwZ6XjjU https://mailarchive.ietf.org/arch/msg/oauth/XQJ4e_kgBOfn3tkTBXf6bYVNGJE ---- Aaron Parecki aaronparecki.com @aaronpk On Thu, Feb 18, 2016 at 12:34 AM, Mike Jones wrote: > Thanks to William Denniss for creating the initial working group version > of the OAuth 2.0 Device Flow specification. The abstract of the > specification is: > > > > The device flow is suitable for OAuth 2.0 clients executing on devices > which do not have an easy data-entry method (e.g., game consoles, TVs, > picture frames, and media hubs), but where the end-user has separate acce= ss > to a user-agent on another computer or device (e.g., desktop computer, a > laptop, a smart phone, or a tablet). > > > > Note: This version of the document is a continuation of an earlier, long > expired draft. The content of the expired draft has been copied almost > unmodified. The goal of the work on this document is to capture deployme= nt > experience. > > > > If you=E2=80=99re using an OAuth device flow, please let us know whether = this > specification matches your usage, and if not, how yours differs. > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-device-flow-00 > > > > An HTML-formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-device-flow-00= .html > > > > -- Mike > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1546 an= d > as @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113f9124a1d385052c0e2e8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had previously made some comments on this back in Novemb= er, but never heard any response. These were things I ran into while implem= enting the device flow on one of my servers.



----
<= div>Aaron Parecki



--001a113f9124a1d385052c0e2e8b-- From nobody Thu Feb 18 09:09:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62B71B30CB for ; Thu, 18 Feb 2016 09:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D71D16bTblpj for ; Thu, 18 Feb 2016 09:09:29 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298FC1B30D0 for ; Thu, 18 Feb 2016 09:09:29 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1IH9RUV012623 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Feb 2016 17:09:28 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1IH9QPk022567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Feb 2016 17:09:27 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1IH9P3k017993; Thu, 18 Feb 2016 17:09:26 GMT Received: from [10.5.50.253] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 09:09:25 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-5C717CF1-B194-4F90-A788-E88E8D47A3C0 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Thu, 18 Feb 2016 10:09:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:09:34 -0000 --Apple-Mail-5C717CF1-B194-4F90-A788-E88E8D47A3C0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How does the client request the oauth configuration assigned to xyz? The example you give appears to presume a single oauth infrastructure for al= l apps.=20 The only way right now to have apps specific oauth is to infer the relation b= y the domain "xyz.example.com". =20 That makes discovery more complex because there arw many more discovery loca= tions and many more configurations to maintain.=20 If example.com had separate oauth servers for services xyz and abc, how woul= d discovery work from a single /.well-know endpoint? Phil > On Feb 18, 2016, at 09:41, Mike Jones wrote:= >=20 > Let me second John=E2=80=99s point that OAuth configuration information an= d application configuration information need not be interspersed. For insta= nce, if the service is at https://example.com and the XYZ application is bei= ng used, then these configuration metadata documents could both be used: > =C2=B7 https://example.com/.well-known/openid-configuration - OAuth c= onfiguration metadata > =C2=B7 https://example.com/.well-known/xyz-configuration - XYZ confi= guration metadata > =20 > There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 val= ue, since there is no such thing as generic OAuth 2.0. By definition, it mu= st always be used in an application context that profiles OAuth 2.0 to enabl= e interoperability. The existing /.well-known/openid-configuration value wo= rks fine for this purpose. Yes, the optics of having a different value migh= t seem better but it comes at the cost of interoperability problems. In my v= iew, interop trumps optics. > =20 > To a point that George Fletcher made, WebFinger could still be used to lea= rn the locations of these configuration metadata documents if that makes sen= se in the application context. The editors took WebFinger out of the OAuth D= iscovery document since it isn=E2=80=99t always applicable. > =20 > Cheers, > -- Mike > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, February 18, 2016 7:41 AM > To: Phil Hunt > Cc: Mike Jones ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > =20 > I suspect that the configuration well-knowns are going to be on the root d= omain. You could try and get a user to put in crm.example.com, but I suspe= ct that is not going to work. > =20 > If the app doesn=E2=80=99t have a specific protocol identifier then it wou= ld use the default. =20 > =20 > I don=E2=80=99t know if you can get around having some sort of app/protoco= l identifier configured in the app. > =20 > John B. > =20 > =20 > =20 > =20 > =20 > =20 > On Feb 18, 2016, at 9:49 AM, Phil Hunt wrote: > =20 > resource service X could be any http accessible service: > =20 > * CRM > * Finance > * Payroll > * ERP > * any application on the web. > =20 > The spec seems to suggest that we use /.well-known/crm to discover OAuth c= onfig for crm. But that may cause conflict if crm has its own discovery. Wh= ich leads us down the path of doing something like =E2=80=9Ccrm-oauth=E2=80=9D= . > =20 > Then there is confusion about what host the discovery is done on. > =20 > For example, hypothetically do I do: > =20 > GET /.well-known/crm > Host: example.com > =20 > But what about the CRM=E2=80=99s configuration information. Is this stompi= ng on it? > =20 > Or, what If we put the oauth configuration at the host for the crm service= : > GET /.well-known/openid-configuration > Host: crm.example.com > =20 > I think the point is that there is a relationship between a protected reso= urce and its designated OAuth service.=20 > =20 > The client needs to discover: > * Where is its designated resource service and what security does it use > * If it is OAuth, where is the intended OAuth configuration for that resou= rce service instance? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 18, 2016, at 7:19 AM, John Bradley wrote: > =20 > Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? > =20 > Is that the RS base URI for the resource, a specific URI that the client i= s requesting? > =20 > That is getting UMA ish.=20 > =20 > The concept of a base RS URI is a rat hole that I prefer not to go down, a= s it is something everyone thinks exists but like SCIM if it exists it is pr= otocol or deployment specific. > =20 > The notion that you would send the URI you are planning on requesting to a= Webfinger server to find the OAuth server, is probably going to have privac= y issues. > =20 > I suspect that you need to hand back a error from the resource to say wher= e the AS is, or have a .well-known for the RS. > =20 > RS discovery probably wants to be separate from AS discovery. (Yes I do t= hink we need something, UMA rpt or something like it might be a way to go) > =20 > John B. > =20 > On Feb 18, 2016, at 9:06 AM, Phil Hunt wrote: > =20 > Maybe SCIM was a bad example. It functions as a RESTful resource in the c= ontext of OAuth. > =20 > I find the use of OIDC to be confusing as an example (and the default) bec= ause it is both an OAuth resource and a security service. It is a modificat= ion of OAuth. > =20 > Start thinking about every application ever written that uses OAuth. Are w= e expecting 100s of thousands of these to each register? > =20 > To me, this specification is a fine specification for OIDC and it should b= e published there because the specification defines how to discovery OAuth a= nd OpenID information. > =20 > Likewise you suggest it is ok for SCIM to do the same.=20 > =20 > How do we expect normal applications to set up and do discovery? > =20 > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should have a= parameter to ask, I want to discover OAuth configuration for resource servi= ce X. > =20 > That still allows me to have a separate discovery service that says, tell m= e about resource service X itself. > =20 > BTW. I think we are FAR from Last Call on this topic. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 18, 2016, at 6:55 AM, John Bradley wrote: > =20 > Diffrent protocols like Connect and SCIM may have different configurations= , endpoints , keys , authentication methods, scopes etc. > =20 > It should be posable to have them as one document, but forcing them to use= one document is going to cause a explosion of claim registration for discov= ery. > =20 > I think it is better for SCIM to register one well known than to have to r= egister 20 claims with scim prefixes or something silly like that. > =20 > Name-spacing the claims by allowing them to be in different well known fil= es is not unreasonable. > =20 > Remember some of these protocols may be hosted on SaaS so there is no guar= antee that all protocols will have the same OAuth Config. > =20 > Nothing stops a protocol from doing what it likes with webfinger if it wan= ts to use that for discovery. > =20 > In principal I like the idea of having another protocol as an example. > =20 > My only concern is that I haven=E2=80=99t seen any discussion of your SCIM= discovery document in the SCIM WG. =20 > I personally think sorting out discovery for SCIM is a good idea, but OAU= Th is but one of several authentication methods for SCIM, and there are prob= ably other non OAuth things that want to be described. > =20 > I would feel better about using it as an example if it were adopted by the= WG and some general interest shown. > =20 > I encourage you to do that so we can use it as a example. > =20 > John B. > =20 > On Feb 18, 2016, at 8:35 AM, Phil Hunt wrote: > =20 > I still find the following text objectionable and confusing=E2=80=A6 > By default, for historical reasons, unless an application-specific > well-known URI path suffix is registered and used for an application, > the client for that application SHOULD use the well-known URI path > suffix "openid-configuration" and publish the metadata document at > the path formed by concatenating "/.well-known/openid-configuration" > to the authorization server's issuer identifier. As described in > Section 5, despite the identifier > "/.well-known/openid-configuration", appearing to be OpenID-specific, > its usage in this specification is actually referring to a general > OAuth 2.0 feature that is not specific to OpenID Connect. > =20 > Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the defaul= t further gives people the impression that a plain OAuth server *is* an auth= entication server and that the normal access token received is evidence of a= successful authentication. > =20 > It would be better to point out that application may include oauth discove= ry in their discovery URI and that OAuth is an example of this. It might be g= ood to include two examples. E.g. OIDC and SCIM (as another referenceable e= xample). > =20 > GET /.well-known/openid-configuration > and > GET /.well-known/scim > Retrieve the OAuth configuration for the application openid and scim respe= ctively. > =20 > The use of: > GET /.well-known/oauth2/ > Should be the default used when there is no known application based well-k= nown application based URI discovery. > =20 > Of course, the concern I raised earlier is that this approach of applicati= on specific URIs ends up requiring every application to make an IANA registr= ation if they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80= =9D (or =E2=80=9Copenid-configuration=E2=80=9D). Is that what the authors e= xpect? > =20 > It seemed better to me to use the webfinger syntax to allow the client to s= ay =E2=80=9CI want the designated OAuth configuration for the resource servi= ce X=E2=80=9D would be a better design that avoids extensive IANA registrati= on. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 17, 2016, at 11:48 PM, Mike Jones wro= te: > =20 > In response to working group input, this version of the OAuth Discovery sp= ecification has been pared down to its essence =E2=80=93 leaving only the fe= atures that are already widely deployed. Specifically, all that remains is t= he definition of the authorization server discovery metadata document and th= e metadata values used in it. The WebFinger discovery logic has been remove= d. The relationship between the issuer identifier URL and the well-known UR= I path relative to it at which the discovery metadata document is located ha= s also been clarified. > =20 > Given that this now describes only features that are in widespread deploym= ent, the editors believe that this version is ready for working group last c= all. > =20 > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > =20 > An HTML-formatted version is also available at: > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-01.ht= ml > =20 > -- Mike & Nat & J= ohn > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1544 and= as @selfissued. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 > =20 > =20 --Apple-Mail-5C717CF1-B194-4F90-A788-E88E8D47A3C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How does the client request the oauth c= onfiguration assigned to xyz?

=
The example you give appears to presume a sin= gle oauth infrastructure for all apps. 

The only way right now to have= apps specific oauth is to infer the relation by the domain "xyz.example.com".  

That makes discovery more c= omplex because there arw many more discovery locations and many more configu= rations to maintain. 

If example.com had separate oauth servers for services xyz and abc, how would discovery w= ork from a single /.well-know endpoint?
=
Phil

Let me second John=E2=80=99s point that= OAuth configuration information and application configuration information n= eed not be interspersed.  For instance, if the service is at https://example.com and the XYZ a= pplication is being used, then these configuration metadata documents could b= oth be used:

=C2=B7       https://example.com/.well-known/openid= -configuration - OAuth configuration metadata

=C2=B7       https://example.com/.well-known/xyz-confi= guration - XYZ configuration metadata

 

There=E2=80=99s not much point in defin= ing a new /.well-known/oauth2.0 value, since there is no such thing as gener= ic OAuth 2.0.  By definition, it must always be used in an application context that profiles OAuth 2.0 to enable interoperabilit= y.  The existing /.well-known/openid-configuration value works fine for= this purpose.  Yes, the optics of having a different value might seem b= etter but it comes at the cost of interoperability problems.  In my view, interop trumps optics.

 

To a point that George Fletcher made, W= ebFinger could still be used to learn the locations of these configuration m= etadata documents if that makes sense in the application context.  The editors took WebFinger out of the OAuth Disc= overy document since it isn=E2=80=99t always applicable.

 

      &nb= sp;            &= nbsp;            = ;            &nb= sp;             C= heers,

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

 =

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil Hunt <phil.hunt@o= racle.com>
Cc: Mike Jones <Mic= hael.Jones@microsoft.com>; oauth@ie= tf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essenc= e

 

I suspect that the configuration well-knowns are goin= g to be on the root domain.   You could try and get a user to put in crm.example.com, but I suspect that i= s not going to work.

 

If the app doesn=E2=80=99t have a specific protocol i= dentifier then it would use the default.  

 

I don=E2=80=99t know if you can get around having som= e sort of app/protocol identifier configured in the app.

 

John B.

 

 

 

 

 

 

On Feb 18, 2016, at 9:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=

 

resource service X could be any http accessible servi= ce:

 

* CRM

* Finance

* Payroll

* ERP

* any application on the web.

 

The spec seems to suggest that we use /.well-known/cr= m to discover OAuth config for crm.  But that may cause conflict if crm= has its own discovery. Which leads us down the path of doing something like= =E2=80=9Ccrm-oauth=E2=80=9D.

 

Then there is confusion about what host the discovery= is done on.

 

For example, hypothetically do I do:

 

GET /.well-known/crm

Host: example.com=

 

But what about the CRM=E2=80=99s configuration inform= ation. Is this stomping on it?

 

Or, what If we put the oauth configuration at the hos= t for the crm service:

GET /.well-known/openid-configuration

 

I think the point is that there is a relationship bet= ween a protected resource and its designated OAuth service. =

 

The client needs to discover:

* Where is its designated resource service and what s= ecurity does it use

* If it is OAuth, where is the intended OAuth configu= ration for that resource service instance?

 

 

 

 

On Feb 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

 

Can you clarify what you mean by =E2=80=9Cresource se= rvice x=E2=80=9D?

 

Is that the RS base URI for the resource,  a spe= cific URI that the client is requesting?

 

That is getting UMA ish. 

 

The concept of a base RS URI is a rat hole that I pre= fer not to go down, as it is something everyone thinks exists but like SCIM i= f it exists it is protocol or deployment specific.

 

The notion that you would send the URI you are planni= ng on requesting to a Webfinger server to find the OAuth server, is probably= going to have privacy issues.

 

I suspect that you need to hand back a error from the= resource to say where the AS is, or have a .well-known for the RS.

 

RS discovery probably wants to be separate from AS di= scovery.  (Yes I do think we need something,  UMA rpt or something= like it might be a way to go)

 

John B.

 

On Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=

 

Maybe SCIM was a bad example.  It functions as a= RESTful resource in the context of OAuth.

 

I find the use of OIDC to be confusing as an example (= and the default) because it is both an OAuth resource and a security service= .  It is a modification of OAuth.

 

Start thinking about every application ever written t= hat uses OAuth. Are we expecting 100s of thousands of these to each register= ?

 

To me, this specification is a fine specification for= OIDC and it should be published there because the specification defines how= to discovery OAuth and OpenID information.

 

Likewise you suggest it is ok for SCIM to do the same= . 

 

How do we expect normal applications to set up and do= discovery?

 

It seems to me that an =E2=80=9COAUTH=E2=80=9D discov= ery spec should have a parameter to ask, I want to discover OAuth configurat= ion for resource service X.

 

That still allows me to have a separate discovery ser= vice that says, tell me about resource service X itself.

 

BTW. I think we are FAR from Last Call on this topic.=

 

 

 

 

On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

 

Diffrent protocols like Connect and SCIM may have dif= ferent configurations, endpoints , keys , authentication methods, scopes etc= .

 

It should be posable to have them as one document, bu= t forcing them to use one document is going to cause a explosion of claim re= gistration for discovery.

 

I think it is better for SCIM to register one well kn= own than to have to register 20 claims with scim prefixes or something silly= like that.

 

Name-spacing the claims by allowing them to be in dif= ferent well known files is not unreasonable.

 

Remember some of these protocols may be hosted on Saa= S so there is no guarantee that all protocols will have the same OAuth Confi= g.

 

Nothing stops a protocol from doing what it likes wit= h webfinger if it wants to use that for discovery.

 

In principal I like the idea of having another protoc= ol as an example.

 

My only concern is that I haven=E2=80=99t seen any di= scussion of your SCIM discovery document in the SCIM WG.  

I personally think sorting out discovery for SCIM is a= good idea,  but OAUTh is but one of several authentication methods for= SCIM, and there are probably other non OAuth things that want to be describ= ed.

 

I would feel better about using it as an example if i= t were adopted by the WG and some general interest shown.

 

I encourage you to do that so we can use it as a exam= ple.

 

John B.

 

On Feb 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=

 

I still find the following text objectionable and con= fusing=E2=80=A6

   By default, for histori=
cal reasons, unless an application-specific
   well-known URI path suf=
fix is registered and used for an application,
   the client for that app=
lication SHOULD use the well-known URI path
   suffix "openid-configur=
ation" and publish the metadata document at
   the path formed by conc=
atenating "/.well-known/openid-configuration"
   to the authorization se=
rver's issuer identifier.  As described in
   Section 5, despi=
te the identifier
   "/.well-known/openid-co=
nfiguration", appearing to be OpenID-specific,
   its usage in this speci=
fication is actually referring to a general
   OAuth 2.0 feature that i=
s not specific to OpenID Connect.

 

Further, as a default =E2=80=9Copenid-configuration=E2= =80=9D as the default further gives people the impression that a plain OAuth= server *is* an authentication server and that the normal access token recei= ved is evidence of a successful authentication.

 

It would be better to point out that application may i= nclude oauth discovery in their discovery URI and that OAuth is an example o= f this. It might be good to include two examples.  E.g. OIDC and SCIM (= as another referenceable example).

 

 GET /.well-known/openid-configurati=
on

and

 GET /.well-known/scim

Retrieve the OAuth configuration for the application o= penid and scim respectively.

 

The use of:

 GET /.well-known/oauth2/=

Should be the default used when there is no known app= lication based well-known application based URI discovery.

 

Of course, the concern I raised earlier is that this a= pproach of application specific URIs ends up requiring every application to m= ake an IANA registration if they don=E2=80=99t want to use the default of =E2= =80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors expect?

 

It seemed better to me to use the webfinger syntax to= allow the client to say =E2=80=9CI want the designated OAuth configuration f= or the resource service X=E2=80=9D would be a better design that avoids exte= nsive IANA registration.

 

 

 

 

On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wro= te:

 

In response to working group input, this version of t= he OAuth Discovery specification has been pared down to its essence =E2=80=93= leaving only the features that are already widely deployed.  Specifically, all that remains is the definition of the aut= horization server discovery metadata document and the metadata values used i= n it.  The WebFinger discovery logic has been removed.  The relati= onship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata docu= ment is located has also been clarified.

 

Given that this now describes only features that are i= n widespread deployment, the editors believe that this version is ready for w= orking group last call.

 

The specification is available at:<= /p>

 

An HTML-formatted version is also available at:<= /o:p>

 

         = ;            &nb= sp;            &= nbsp;            = ;           -- Mike & N= at & John

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1544=  and as @selfissued.

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

 

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

 

 

 

 

 

= --Apple-Mail-5C717CF1-B194-4F90-A788-E88E8D47A3C0-- From nobody Thu Feb 18 09:12:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5487E1A3BA4 for ; Thu, 18 Feb 2016 09:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPWU3gMiAUpq for ; Thu, 18 Feb 2016 09:11:54 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABB71ACDD8 for ; Thu, 18 Feb 2016 09:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JEFLEF98AEJircBasHmQrXFNZjFLzgQDBnauChz57lM=; b=PHkIPDf/K6OD9DVMCwJobZoXBt91zobLm/guhadGIbdUMae9SaU65rNYmdNm+xv4gG0PQZC56oK+PstJbjcBRVQ7A1/hOzTnQJL84IybPnlZ8Q/0qeN6WrGUArMkmb8Okh/MtfZOIYyAxW3mB1HNMh1rzboYEAiyw/ZlpLW8lXw= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 17:11:52 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 17:11:53 +0000 From: Mike Jones To: "Phil Hunt (IDM)" Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAAAcFuAAAELoIAAAdOZgAABqOPwAAFp5YAAAApxAA== Date: Thu, 18 Feb 2016 17:11:52 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> In-Reply-To: <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 9b0d6b48-566f-45d0-c59d-08d3388698e4 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:4fFPRpY5Ddv5rG46dDmJORtTIUoytmPnQL+q+uCvboa8ahA+6xk5r3Q7jg5/bpCWJ7tGpaJEZ0ALwJexIDToDPli2Fl2rwCrdIb9DuPQgcnXeUkmrcAeiOze5KVOtg0cQnH6WwY1hG/LxjWQ1PresQ==; 24:g8dJV5t145qMdhddHzUNZJPMOuOrqSyT9qeOHhG4I0ECGwGwHMe8u76wX6tE4ku2ukTiMqZ/2zL9xZ+d9sU7aPTEWI9HZehsVc3P5Vx5Fro= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(377454003)(24454002)(189998001)(19580395003)(19617315012)(5008740100001)(15395725005)(86612001)(19300405004)(19625215002)(110136002)(87936001)(86362001)(5004730100002)(99286002)(19580405001)(74316001)(76576001)(16236675004)(5001960100002)(5002640100001)(33656002)(10400500002)(5005710100001)(3660700001)(92566002)(2950100001)(3846002)(1680700002)(3280700002)(1220700001)(2906002)(10090500001)(1096002)(66066001)(16601075003)(102836003)(586003)(4326007)(40100003)(10290500002)(5003600100002)(122556002)(2900100001)(15975445007)(93886004)(54356999)(50986999)(76176999)(77096005)(6116002)(790700001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A2C32028C2B46192FF65F5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 17:11:52.8618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:12:05 -0000 --_000_BY2PR03MB442A2C32028C2B46192FF65F5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlcmUgd2VyZSBkaWZmZXJlbnQgT0F1dGggc2VydmljZXMsIHRoZXkgd291bGQgYmUgbG9j YXRlZCBhdCBkaWZmZXJlbnQgVVJMcywgd2l0aCBkaWZmZXJlbnQgLndlbGwta25vd24gZG9jdW1l bnRzIGF0IHRob3NlIFVSTHMuDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDk6MDkg QU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzogSm9o biBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBPQXV0aCBEaXNjb3Zlcnkgc3BlYyBwYXJlZCBkb3duIHRvIGl0cyBlc3Nl bmNlDQoNCkhvdyBkb2VzIHRoZSBjbGllbnQgcmVxdWVzdCB0aGUgb2F1dGggY29uZmlndXJhdGlv biBhc3NpZ25lZCB0byB4eXo/DQoNClRoZSBleGFtcGxlIHlvdSBnaXZlIGFwcGVhcnMgdG8gcHJl c3VtZSBhIHNpbmdsZSBvYXV0aCBpbmZyYXN0cnVjdHVyZSBmb3IgYWxsIGFwcHMuDQoNClRoZSBv bmx5IHdheSByaWdodCBub3cgdG8gaGF2ZSBhcHBzIHNwZWNpZmljIG9hdXRoIGlzIHRvIGluZmVy IHRoZSByZWxhdGlvbiBieSB0aGUgZG9tYWluICJ4eXouZXhhbXBsZS5jb208aHR0cDovL3h5ei5l eGFtcGxlLmNvbT4iLg0KDQpUaGF0IG1ha2VzIGRpc2NvdmVyeSBtb3JlIGNvbXBsZXggYmVjYXVz ZSB0aGVyZSBhcncgbWFueSBtb3JlIGRpc2NvdmVyeSBsb2NhdGlvbnMgYW5kIG1hbnkgbW9yZSBj b25maWd1cmF0aW9ucyB0byBtYWludGFpbi4NCg0KSWYgZXhhbXBsZS5jb208aHR0cDovL2V4YW1w bGUuY29tPiBoYWQgc2VwYXJhdGUgb2F1dGggc2VydmVycyBmb3Igc2VydmljZXMgeHl6IGFuZCBh YmMsIGhvdyB3b3VsZCBkaXNjb3Zlcnkgd29yayBmcm9tIGEgc2luZ2xlIC8ud2VsbC1rbm93IGVu ZHBvaW50Pw0KDQpQaGlsDQoNCk9uIEZlYiAxOCwgMjAxNiwgYXQgMDk6NDEsIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj4gd3JvdGU6DQpMZXQgbWUgc2Vjb25kIEpvaG7igJlzIHBvaW50IHRoYXQgT0F1dGgg Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBhbmQgYXBwbGljYXRpb24gY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbiBuZWVkIG5vdCBiZSBpbnRlcnNwZXJzZWQuICBGb3IgaW5zdGFuY2UsIGlmIHRo ZSBzZXJ2aWNlIGlzIGF0IGh0dHBzOi8vZXhhbXBsZS5jb20gYW5kIHRoZSBYWVogYXBwbGljYXRp b24gaXMgYmVpbmcgdXNlZCwgdGhlbiB0aGVzZSBjb25maWd1cmF0aW9uIG1ldGFkYXRhIGRvY3Vt ZW50cyBjb3VsZCBib3RoIGJlIHVzZWQ6DQoNCsK3ICAgICAgIGh0dHBzOi8vZXhhbXBsZS5jb20v LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24gLSBPQXV0aCBjb25maWd1cmF0aW9uIG1l dGFkYXRhDQoNCsK3ICAgICAgIGh0dHBzOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24veHl6LWNv bmZpZ3VyYXRpb24gLSBYWVogY29uZmlndXJhdGlvbiBtZXRhZGF0YQ0KDQpUaGVyZeKAmXMgbm90 IG11Y2ggcG9pbnQgaW4gZGVmaW5pbmcgYSBuZXcgLy53ZWxsLWtub3duL29hdXRoMi4wIHZhbHVl LCBzaW5jZSB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGdlbmVyaWMgT0F1dGggMi4wLiAgQnkg ZGVmaW5pdGlvbiwgaXQgbXVzdCBhbHdheXMgYmUgdXNlZCBpbiBhbiBhcHBsaWNhdGlvbiBjb250 ZXh0IHRoYXQgcHJvZmlsZXMgT0F1dGggMi4wIHRvIGVuYWJsZSBpbnRlcm9wZXJhYmlsaXR5LiAg VGhlIGV4aXN0aW5nIC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiB2YWx1ZSB3b3Jr cyBmaW5lIGZvciB0aGlzIHB1cnBvc2UuICBZZXMsIHRoZSBvcHRpY3Mgb2YgaGF2aW5nIGEgZGlm ZmVyZW50IHZhbHVlIG1pZ2h0IHNlZW0gYmV0dGVyIGJ1dCBpdCBjb21lcyBhdCB0aGUgY29zdCBv ZiBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLiAgSW4gbXkgdmlldywgaW50ZXJvcCB0cnVtcHMg b3B0aWNzLg0KDQpUbyBhIHBvaW50IHRoYXQgR2VvcmdlIEZsZXRjaGVyIG1hZGUsIFdlYkZpbmdl ciBjb3VsZCBzdGlsbCBiZSB1c2VkIHRvIGxlYXJuIHRoZSBsb2NhdGlvbnMgb2YgdGhlc2UgY29u ZmlndXJhdGlvbiBtZXRhZGF0YSBkb2N1bWVudHMgaWYgdGhhdCBtYWtlcyBzZW5zZSBpbiB0aGUg YXBwbGljYXRpb24gY29udGV4dC4gIFRoZSBlZGl0b3JzIHRvb2sgV2ViRmluZ2VyIG91dCBvZiB0 aGUgT0F1dGggRGlzY292ZXJ5IGRvY3VtZW50IHNpbmNlIGl0IGlzbuKAmXQgYWx3YXlzIGFwcGxp Y2FibGUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDaGVlcnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBKb2huIEJyYWRsZXkgW21haWx0 bzp2ZTdqdGJAdmU3anRiLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxOCwgMjAxNiA3 OjQxIEFNDQpUbzogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIERp c2NvdmVyeSBzcGVjIHBhcmVkIGRvd24gdG8gaXRzIGVzc2VuY2UNCg0KSSBzdXNwZWN0IHRoYXQg dGhlIGNvbmZpZ3VyYXRpb24gd2VsbC1rbm93bnMgYXJlIGdvaW5nIHRvIGJlIG9uIHRoZSByb290 IGRvbWFpbi4gICBZb3UgY291bGQgdHJ5IGFuZCBnZXQgYSB1c2VyIHRvIHB1dCBpbiBjcm0uZXhh bXBsZS5jb208aHR0cDovL2NybS5leGFtcGxlLmNvbT4sIGJ1dCBJIHN1c3BlY3QgdGhhdCBpcyBu b3QgZ29pbmcgdG8gd29yay4NCg0KSWYgdGhlIGFwcCBkb2VzbuKAmXQgaGF2ZSBhIHNwZWNpZmlj IHByb3RvY29sIGlkZW50aWZpZXIgdGhlbiBpdCB3b3VsZCB1c2UgdGhlIGRlZmF1bHQuDQoNCkkg ZG9u4oCZdCBrbm93IGlmIHlvdSBjYW4gZ2V0IGFyb3VuZCBoYXZpbmcgc29tZSBzb3J0IG9mIGFw cC9wcm90b2NvbCBpZGVudGlmaWVyIGNvbmZpZ3VyZWQgaW4gdGhlIGFwcC4NCg0KSm9obiBCLg0K DQoNCg0KDQoNCg0KT24gRmViIDE4LCAyMDE2LCBhdCA5OjQ5IEFNLCBQaGlsIEh1bnQgPHBoaWwu aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpy ZXNvdXJjZSBzZXJ2aWNlIFggY291bGQgYmUgYW55IGh0dHAgYWNjZXNzaWJsZSBzZXJ2aWNlOg0K DQoqIENSTQ0KKiBGaW5hbmNlDQoqIFBheXJvbGwNCiogRVJQDQoqIGFueSBhcHBsaWNhdGlvbiBv biB0aGUgd2ViLg0KDQpUaGUgc3BlYyBzZWVtcyB0byBzdWdnZXN0IHRoYXQgd2UgdXNlIC8ud2Vs bC1rbm93bi9jcm0gdG8gZGlzY292ZXIgT0F1dGggY29uZmlnIGZvciBjcm0uICBCdXQgdGhhdCBt YXkgY2F1c2UgY29uZmxpY3QgaWYgY3JtIGhhcyBpdHMgb3duIGRpc2NvdmVyeS4gV2hpY2ggbGVh ZHMgdXMgZG93biB0aGUgcGF0aCBvZiBkb2luZyBzb21ldGhpbmcgbGlrZSDigJxjcm0tb2F1dGji gJ0uDQoNClRoZW4gdGhlcmUgaXMgY29uZnVzaW9uIGFib3V0IHdoYXQgaG9zdCB0aGUgZGlzY292 ZXJ5IGlzIGRvbmUgb24uDQoNCkZvciBleGFtcGxlLCBoeXBvdGhldGljYWxseSBkbyBJIGRvOg0K DQpHRVQgLy53ZWxsLWtub3duL2NybQ0KSG9zdDogZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUu Y29tLz4NCg0KQnV0IHdoYXQgYWJvdXQgdGhlIENSTeKAmXMgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbi4gSXMgdGhpcyBzdG9tcGluZyBvbiBpdD8NCg0KT3IsIHdoYXQgSWYgd2UgcHV0IHRoZSBv YXV0aCBjb25maWd1cmF0aW9uIGF0IHRoZSBob3N0IGZvciB0aGUgY3JtIHNlcnZpY2U6DQpHRVQg Ly53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uDQpIb3N0OiBjcm0uZXhhbXBsZS5jb208 aHR0cDovL2NybS5leGFtcGxlLmNvbS8+DQoNCkkgdGhpbmsgdGhlIHBvaW50IGlzIHRoYXQgdGhl cmUgaXMgYSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHByb3RlY3RlZCByZXNvdXJjZSBhbmQgaXRz IGRlc2lnbmF0ZWQgT0F1dGggc2VydmljZS4NCg0KVGhlIGNsaWVudCBuZWVkcyB0byBkaXNjb3Zl cjoNCiogV2hlcmUgaXMgaXRzIGRlc2lnbmF0ZWQgcmVzb3VyY2Ugc2VydmljZSBhbmQgd2hhdCBz ZWN1cml0eSBkb2VzIGl0IHVzZQ0KKiBJZiBpdCBpcyBPQXV0aCwgd2hlcmUgaXMgdGhlIGludGVu ZGVkIE9BdXRoIGNvbmZpZ3VyYXRpb24gZm9yIHRoYXQgcmVzb3VyY2Ugc2VydmljZSBpbnN0YW5j ZT8NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6 Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpPbiBGZWIgMTgsIDIwMTYsIGF0IDc6MTkgQU0s IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t Pj4gd3JvdGU6DQoNCkNhbiB5b3UgY2xhcmlmeSB3aGF0IHlvdSBtZWFuIGJ5IOKAnHJlc291cmNl IHNlcnZpY2UgeOKAnT8NCg0KSXMgdGhhdCB0aGUgUlMgYmFzZSBVUkkgZm9yIHRoZSByZXNvdXJj ZSwgIGEgc3BlY2lmaWMgVVJJIHRoYXQgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nPw0KDQpUaGF0 IGlzIGdldHRpbmcgVU1BIGlzaC4NCg0KVGhlIGNvbmNlcHQgb2YgYSBiYXNlIFJTIFVSSSBpcyBh IHJhdCBob2xlIHRoYXQgSSBwcmVmZXIgbm90IHRvIGdvIGRvd24sIGFzIGl0IGlzIHNvbWV0aGlu ZyBldmVyeW9uZSB0aGlua3MgZXhpc3RzIGJ1dCBsaWtlIFNDSU0gaWYgaXQgZXhpc3RzIGl0IGlz IHByb3RvY29sIG9yIGRlcGxveW1lbnQgc3BlY2lmaWMuDQoNClRoZSBub3Rpb24gdGhhdCB5b3Ug d291bGQgc2VuZCB0aGUgVVJJIHlvdSBhcmUgcGxhbm5pbmcgb24gcmVxdWVzdGluZyB0byBhIFdl YmZpbmdlciBzZXJ2ZXIgdG8gZmluZCB0aGUgT0F1dGggc2VydmVyLCBpcyBwcm9iYWJseSBnb2lu ZyB0byBoYXZlIHByaXZhY3kgaXNzdWVzLg0KDQpJIHN1c3BlY3QgdGhhdCB5b3UgbmVlZCB0byBo YW5kIGJhY2sgYSBlcnJvciBmcm9tIHRoZSByZXNvdXJjZSB0byBzYXkgd2hlcmUgdGhlIEFTIGlz LCBvciBoYXZlIGEgLndlbGwta25vd24gZm9yIHRoZSBSUy4NCg0KUlMgZGlzY292ZXJ5IHByb2Jh Ymx5IHdhbnRzIHRvIGJlIHNlcGFyYXRlIGZyb20gQVMgZGlzY292ZXJ5LiAgKFllcyBJIGRvIHRo aW5rIHdlIG5lZWQgc29tZXRoaW5nLCAgVU1BIHJwdCBvciBzb21ldGhpbmcgbGlrZSBpdCBtaWdo dCBiZSBhIHdheSB0byBnbykNCg0KSm9obiBCLg0KDQpPbiBGZWIgMTgsIDIwMTYsIGF0IDk6MDYg QU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPj4gd3JvdGU6DQoNCk1heWJlIFNDSU0gd2FzIGEgYmFkIGV4YW1wbGUuICBJdCBmdW5j dGlvbnMgYXMgYSBSRVNUZnVsIHJlc291cmNlIGluIHRoZSBjb250ZXh0IG9mIE9BdXRoLg0KDQpJ IGZpbmQgdGhlIHVzZSBvZiBPSURDIHRvIGJlIGNvbmZ1c2luZyBhcyBhbiBleGFtcGxlIChhbmQg dGhlIGRlZmF1bHQpIGJlY2F1c2UgaXQgaXMgYm90aCBhbiBPQXV0aCByZXNvdXJjZSBhbmQgYSBz ZWN1cml0eSBzZXJ2aWNlLiAgSXQgaXMgYSBtb2RpZmljYXRpb24gb2YgT0F1dGguDQoNClN0YXJ0 IHRoaW5raW5nIGFib3V0IGV2ZXJ5IGFwcGxpY2F0aW9uIGV2ZXIgd3JpdHRlbiB0aGF0IHVzZXMg T0F1dGguIEFyZSB3ZSBleHBlY3RpbmcgMTAwcyBvZiB0aG91c2FuZHMgb2YgdGhlc2UgdG8gZWFj aCByZWdpc3Rlcj8NCg0KVG8gbWUsIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhIGZpbmUgc3BlY2lm aWNhdGlvbiBmb3IgT0lEQyBhbmQgaXQgc2hvdWxkIGJlIHB1Ymxpc2hlZCB0aGVyZSBiZWNhdXNl IHRoZSBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGRpc2NvdmVyeSBPQXV0aCBhbmQgT3Bl bklEIGluZm9ybWF0aW9uLg0KDQpMaWtld2lzZSB5b3Ugc3VnZ2VzdCBpdCBpcyBvayBmb3IgU0NJ TSB0byBkbyB0aGUgc2FtZS4NCg0KSG93IGRvIHdlIGV4cGVjdCBub3JtYWwgYXBwbGljYXRpb25z IHRvIHNldCB1cCBhbmQgZG8gZGlzY292ZXJ5Pw0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IGFuIOKA nE9BVVRI4oCdIGRpc2NvdmVyeSBzcGVjIHNob3VsZCBoYXZlIGEgcGFyYW1ldGVyIHRvIGFzaywg SSB3YW50IHRvIGRpc2NvdmVyIE9BdXRoIGNvbmZpZ3VyYXRpb24gZm9yIHJlc291cmNlIHNlcnZp Y2UgWC4NCg0KVGhhdCBzdGlsbCBhbGxvd3MgbWUgdG8gaGF2ZSBhIHNlcGFyYXRlIGRpc2NvdmVy eSBzZXJ2aWNlIHRoYXQgc2F5cywgdGVsbCBtZSBhYm91dCByZXNvdXJjZSBzZXJ2aWNlIFggaXRz ZWxmLg0KDQpCVFcuIEkgdGhpbmsgd2UgYXJlIEZBUiBmcm9tIExhc3QgQ2FsbCBvbiB0aGlzIHRv cGljLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0 cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIEZlYiAxOCwgMjAxNiwgYXQgNjo1NSBB TSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5j b20+PiB3cm90ZToNCg0KRGlmZnJlbnQgcHJvdG9jb2xzIGxpa2UgQ29ubmVjdCBhbmQgU0NJTSBt YXkgaGF2ZSBkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMsIGVuZHBvaW50cyAsIGtleXMgLCBhdXRo ZW50aWNhdGlvbiBtZXRob2RzLCBzY29wZXMgZXRjLg0KDQpJdCBzaG91bGQgYmUgcG9zYWJsZSB0 byBoYXZlIHRoZW0gYXMgb25lIGRvY3VtZW50LCBidXQgZm9yY2luZyB0aGVtIHRvIHVzZSBvbmUg ZG9jdW1lbnQgaXMgZ29pbmcgdG8gY2F1c2UgYSBleHBsb3Npb24gb2YgY2xhaW0gcmVnaXN0cmF0 aW9uIGZvciBkaXNjb3ZlcnkuDQoNCkkgdGhpbmsgaXQgaXMgYmV0dGVyIGZvciBTQ0lNIHRvIHJl Z2lzdGVyIG9uZSB3ZWxsIGtub3duIHRoYW4gdG8gaGF2ZSB0byByZWdpc3RlciAyMCBjbGFpbXMg d2l0aCBzY2ltIHByZWZpeGVzIG9yIHNvbWV0aGluZyBzaWxseSBsaWtlIHRoYXQuDQoNCk5hbWUt c3BhY2luZyB0aGUgY2xhaW1zIGJ5IGFsbG93aW5nIHRoZW0gdG8gYmUgaW4gZGlmZmVyZW50IHdl bGwga25vd24gZmlsZXMgaXMgbm90IHVucmVhc29uYWJsZS4NCg0KUmVtZW1iZXIgc29tZSBvZiB0 aGVzZSBwcm90b2NvbHMgbWF5IGJlIGhvc3RlZCBvbiBTYWFTIHNvIHRoZXJlIGlzIG5vIGd1YXJh bnRlZSB0aGF0IGFsbCBwcm90b2NvbHMgd2lsbCBoYXZlIHRoZSBzYW1lIE9BdXRoIENvbmZpZy4N Cg0KTm90aGluZyBzdG9wcyBhIHByb3RvY29sIGZyb20gZG9pbmcgd2hhdCBpdCBsaWtlcyB3aXRo IHdlYmZpbmdlciBpZiBpdCB3YW50cyB0byB1c2UgdGhhdCBmb3IgZGlzY292ZXJ5Lg0KDQpJbiBw cmluY2lwYWwgSSBsaWtlIHRoZSBpZGVhIG9mIGhhdmluZyBhbm90aGVyIHByb3RvY29sIGFzIGFu IGV4YW1wbGUuDQoNCk15IG9ubHkgY29uY2VybiBpcyB0aGF0IEkgaGF2ZW7igJl0IHNlZW4gYW55 IGRpc2N1c3Npb24gb2YgeW91ciBTQ0lNIGRpc2NvdmVyeSBkb2N1bWVudCBpbiB0aGUgU0NJTSBX Ry4NCkkgcGVyc29uYWxseSB0aGluayBzb3J0aW5nIG91dCBkaXNjb3ZlcnkgZm9yIFNDSU0gaXMg YSBnb29kIGlkZWEsICBidXQgT0FVVGggaXMgYnV0IG9uZSBvZiBzZXZlcmFsIGF1dGhlbnRpY2F0 aW9uIG1ldGhvZHMgZm9yIFNDSU0sIGFuZCB0aGVyZSBhcmUgcHJvYmFibHkgb3RoZXIgbm9uIE9B dXRoIHRoaW5ncyB0aGF0IHdhbnQgdG8gYmUgZGVzY3JpYmVkLg0KDQpJIHdvdWxkIGZlZWwgYmV0 dGVyIGFib3V0IHVzaW5nIGl0IGFzIGFuIGV4YW1wbGUgaWYgaXQgd2VyZSBhZG9wdGVkIGJ5IHRo ZSBXRyBhbmQgc29tZSBnZW5lcmFsIGludGVyZXN0IHNob3duLg0KDQpJIGVuY291cmFnZSB5b3Ug dG8gZG8gdGhhdCBzbyB3ZSBjYW4gdXNlIGl0IGFzIGEgZXhhbXBsZS4NCg0KSm9obiBCLg0KDQpP biBGZWIgMTgsIDIwMTYsIGF0IDg6MzUgQU0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkkgc3RpbGwgZmluZCB0 aGUgZm9sbG93aW5nIHRleHQgb2JqZWN0aW9uYWJsZSBhbmQgY29uZnVzaW5n4oCmDQoNCiAgIEJ5 IGRlZmF1bHQsIGZvciBoaXN0b3JpY2FsIHJlYXNvbnMsIHVubGVzcyBhbiBhcHBsaWNhdGlvbi1z cGVjaWZpYw0KDQogICB3ZWxsLWtub3duIFVSSSBwYXRoIHN1ZmZpeCBpcyByZWdpc3RlcmVkIGFu ZCB1c2VkIGZvciBhbiBhcHBsaWNhdGlvbiwNCg0KICAgdGhlIGNsaWVudCBmb3IgdGhhdCBhcHBs aWNhdGlvbiBTSE9VTEQgdXNlIHRoZSB3ZWxsLWtub3duIFVSSSBwYXRoDQoNCiAgIHN1ZmZpeCAi b3BlbmlkLWNvbmZpZ3VyYXRpb24iIGFuZCBwdWJsaXNoIHRoZSBtZXRhZGF0YSBkb2N1bWVudCBh dA0KDQogICB0aGUgcGF0aCBmb3JtZWQgYnkgY29uY2F0ZW5hdGluZyAiLy53ZWxsLWtub3duL29w ZW5pZC1jb25maWd1cmF0aW9uIg0KDQogICB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBp c3N1ZXIgaWRlbnRpZmllci4gIEFzIGRlc2NyaWJlZCBpbg0KDQogICBTZWN0aW9uIDU8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEjc2VjdGlv bi01PiwgZGVzcGl0ZSB0aGUgaWRlbnRpZmllcg0KDQogICAiLy53ZWxsLWtub3duL29wZW5pZC1j b25maWd1cmF0aW9uIiwgYXBwZWFyaW5nIHRvIGJlIE9wZW5JRC1zcGVjaWZpYywNCg0KICAgaXRz IHVzYWdlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhY3R1YWxseSByZWZlcnJpbmcgdG8gYSBn ZW5lcmFsDQoNCiAgIE9BdXRoIDIuMCBmZWF0dXJlIHRoYXQgaXMgbm90IHNwZWNpZmljIHRvIE9w ZW5JRCBDb25uZWN0Lg0KDQpGdXJ0aGVyLCBhcyBhIGRlZmF1bHQg4oCcb3BlbmlkLWNvbmZpZ3Vy YXRpb27igJ0gYXMgdGhlIGRlZmF1bHQgZnVydGhlciBnaXZlcyBwZW9wbGUgdGhlIGltcHJlc3Np b24gdGhhdCBhIHBsYWluIE9BdXRoIHNlcnZlciAqaXMqIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZl ciBhbmQgdGhhdCB0aGUgbm9ybWFsIGFjY2VzcyB0b2tlbiByZWNlaXZlZCBpcyBldmlkZW5jZSBv ZiBhIHN1Y2Nlc3NmdWwgYXV0aGVudGljYXRpb24uDQoNCkl0IHdvdWxkIGJlIGJldHRlciB0byBw b2ludCBvdXQgdGhhdCBhcHBsaWNhdGlvbiBtYXkgaW5jbHVkZSBvYXV0aCBkaXNjb3ZlcnkgaW4g dGhlaXIgZGlzY292ZXJ5IFVSSSBhbmQgdGhhdCBPQXV0aCBpcyBhbiBleGFtcGxlIG9mIHRoaXMu IEl0IG1pZ2h0IGJlIGdvb2QgdG8gaW5jbHVkZSB0d28gZXhhbXBsZXMuICBFLmcuIE9JREMgYW5k IFNDSU0gKGFzIGFub3RoZXIgcmVmZXJlbmNlYWJsZSBleGFtcGxlKS4NCg0KDQogR0VUIC8ud2Vs bC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbg0KYW5kDQoNCiBHRVQgLy53ZWxsLWtub3duL3Nj aW0NClJldHJpZXZlIHRoZSBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGUgYXBwbGljYXRpb24g b3BlbmlkIGFuZCBzY2ltIHJlc3BlY3RpdmVseS4NCg0KVGhlIHVzZSBvZjoNCg0KIEdFVCAvLndl bGwta25vd24vb2F1dGgyLw0KU2hvdWxkIGJlIHRoZSBkZWZhdWx0IHVzZWQgd2hlbiB0aGVyZSBp cyBubyBrbm93biBhcHBsaWNhdGlvbiBiYXNlZCB3ZWxsLWtub3duIGFwcGxpY2F0aW9uIGJhc2Vk IFVSSSBkaXNjb3ZlcnkuDQoNCk9mIGNvdXJzZSwgdGhlIGNvbmNlcm4gSSByYWlzZWQgZWFybGll ciBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggb2YgYXBwbGljYXRpb24gc3BlY2lmaWMgVVJJcyBlbmRz IHVwIHJlcXVpcmluZyBldmVyeSBhcHBsaWNhdGlvbiB0byBtYWtlIGFuIElBTkEgcmVnaXN0cmF0 aW9uIGlmIHRoZXkgZG9u4oCZdCB3YW50IHRvIHVzZSB0aGUgZGVmYXVsdCBvZiDigJxvYXV0aDLi gJ0gKG9yIOKAnG9wZW5pZC1jb25maWd1cmF0aW9u4oCdKS4gIElzIHRoYXQgd2hhdCB0aGUgYXV0 aG9ycyBleHBlY3Q/DQoNCkl0IHNlZW1lZCBiZXR0ZXIgdG8gbWUgdG8gdXNlIHRoZSB3ZWJmaW5n ZXIgc3ludGF4IHRvIGFsbG93IHRoZSBjbGllbnQgdG8gc2F5IOKAnEkgd2FudCB0aGUgZGVzaWdu YXRlZCBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGUgcmVzb3VyY2Ugc2VydmljZSBY4oCdIHdv dWxkIGJlIGEgYmV0dGVyIGRlc2lnbiB0aGF0IGF2b2lkcyBleHRlbnNpdmUgSUFOQSByZWdpc3Ry YXRpb24uDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxo dHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gRmViIDE3LCAyMDE2LCBhdCAxMTo0 OCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSW4gcmVzcG9uc2UgdG8gd29ya2lu ZyBncm91cCBpbnB1dCwgdGhpcyB2ZXJzaW9uIG9mIHRoZSBPQXV0aCBEaXNjb3Zlcnkgc3BlY2lm aWNhdGlvbiBoYXMgYmVlbiBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlIOKAkyBsZWF2aW5nIG9u bHkgdGhlIGZlYXR1cmVzIHRoYXQgYXJlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLiAgU3BlY2lm aWNhbGx5LCBhbGwgdGhhdCByZW1haW5zIGlzIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgYW5kIHRoZSBtZXRhZGF0 YSB2YWx1ZXMgdXNlZCBpbiBpdC4gIFRoZSBXZWJGaW5nZXIgZGlzY292ZXJ5IGxvZ2ljIGhhcyBi ZWVuIHJlbW92ZWQuICBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGlzc3VlciBpZGVudGlm aWVyIFVSTCBhbmQgdGhlIHdlbGwta25vd24gVVJJIHBhdGggcmVsYXRpdmUgdG8gaXQgYXQgd2hp Y2ggdGhlIGRpc2NvdmVyeSBtZXRhZGF0YSBkb2N1bWVudCBpcyBsb2NhdGVkIGhhcyBhbHNvIGJl ZW4gY2xhcmlmaWVkLg0KDQpHaXZlbiB0aGF0IHRoaXMgbm93IGRlc2NyaWJlcyBvbmx5IGZlYXR1 cmVzIHRoYXQgYXJlIGluIHdpZGVzcHJlYWQgZGVwbG95bWVudCwgdGhlIGVkaXRvcnMgYmVsaWV2 ZSB0aGF0IHRoaXMgdmVyc2lvbiBpcyByZWFkeSBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwu DQoNClRoZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDoNCuKAoiAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wMQ0KDQpBbiBI VE1MLWZvcm1hdHRlZCB2ZXJzaW9uIGlzIGFsc28gYXZhaWxhYmxlIGF0Og0K4oCiICAgICAgIGh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEu aHRtbA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZSAmIE5hdCAmIEpvaG4NCg0KUC5TLiAgVGhpcyBub3RpY2Ugd2FzIGFs c28gcG9zdGVkIGF0IGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE1NDQgYW5kIGFzIEBzZWxm aXNzdWVkPGh0dHBzOi8vdHdpdHRlci5jb20vc2VsZmlzc3VlZD4uDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQoNCg0KDQo= --_000_BY2PR03MB442A2C32028C2B46192FF65F5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmFwcGxl LXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVt YWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcxNzI0MDU0 NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzU5NTM4 MDAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JZiB0aGVyZSB3ZXJl IGRpZmZlcmVudCBPQXV0aCBzZXJ2aWNlcywgdGhleSB3b3VsZCBiZSBsb2NhdGVkIGF0IGRpZmZl cmVudCBVUkxzLCB3aXRoIGRpZmZlcmVudCAud2VsbC1rbm93biBkb2N1bWVudHMgYXQgdGhvc2Ug VVJMcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBQaGlsIEh1bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgOTow OSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRi LmNvbSZndDs7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt V0ddIE9BdXRoIERpc2NvdmVyeSBzcGVjIHBhcmVkIGRvd24gdG8gaXRzIGVzc2VuY2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGRvZXMg dGhlIGNsaWVudCByZXF1ZXN0IHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGFzc2lnbmVkIHRvIHh5 ej88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGV4YW1w bGUgeW91IGdpdmUgYXBwZWFycyB0byBwcmVzdW1lIGEgc2luZ2xlIG9hdXRoIGluZnJhc3RydWN0 dXJlIGZvciBhbGwgYXBwcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIG9ubHkgd2F5IHJpZ2h0IG5vdyB0byBoYXZlIGFwcHMgc3BlY2lmaWMg b2F1dGggaXMgdG8gaW5mZXIgdGhlIHJlbGF0aW9uIGJ5IHRoZSBkb21haW4gJnF1b3Q7PGEgaHJl Zj0iaHR0cDovL3h5ei5leGFtcGxlLmNvbSI+eHl6LmV4YW1wbGUuY29tPC9hPiZxdW90Oy4gJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgbWFr ZXMgZGlzY292ZXJ5IG1vcmUgY29tcGxleCBiZWNhdXNlIHRoZXJlIGFydyBtYW55IG1vcmUgZGlz Y292ZXJ5IGxvY2F0aW9ucyBhbmQgbWFueSBtb3JlIGNvbmZpZ3VyYXRpb25zIHRvIG1haW50YWlu LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1 cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiA8 YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iPmV4YW1wbGUuY29tPC9hPiBoYWQgc2VwYXJhdGUg b2F1dGggc2VydmVycyBmb3Igc2VydmljZXMgeHl6IGFuZCBhYmMsIGhvdyB3b3VsZCBkaXNjb3Zl cnkgd29yayBmcm9tIGEgc2luZ2xlIC8ud2VsbC1rbm93IGVuZHBvaW50PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMTgs IDIwMTYsIGF0IDA5OjQxLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkxldCBtZSBzZWNvbmQgSm9obuKAmXMg cG9pbnQgdGhhdCBPQXV0aCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGFuZCBhcHBsaWNhdGlv biBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIG5lZWQgbm90IGJlIGludGVyc3BlcnNlZC4mbmJz cDsgRm9yIGluc3RhbmNlLCBpZiB0aGUgc2VydmljZQ0KIGlzIGF0IDxhIGhyZWY9Imh0dHBzOi8v ZXhhbXBsZS5jb20iPmh0dHBzOi8vZXhhbXBsZS5jb208L2E+IGFuZCB0aGUgWFlaIGFwcGxpY2F0 aW9uIGlzIGJlaW5nIHVzZWQsIHRoZW4gdGhlc2UgY29uZmlndXJhdGlvbiBtZXRhZGF0YSBkb2N1 bWVudHMgY291bGQgYm90aCBiZSB1c2VkOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vLndl bGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24iPmh0dHBzOi8vZXhhbXBsZS5jb20vLndlbGwt a25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb248L2E+IC0gT0F1dGggY29uZmlndXJhdGlvbiBtZXRh ZGF0YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPjxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24veHl6LWNvbmZpZ3Vy YXRpb24iPmh0dHBzOi8vZXhhbXBsZS5jb20vLndlbGwta25vd24veHl6LWNvbmZpZ3VyYXRpb248 L2E+IC0gWFlaIGNvbmZpZ3VyYXRpb24gbWV0YWRhdGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPlRoZXJl4oCZcyBub3QgbXVjaCBwb2ludCBpbiBkZWZpbmluZyBh IG5ldyAvLndlbGwta25vd24vb2F1dGgyLjAgdmFsdWUsIHNpbmNlIHRoZXJlIGlzIG5vIHN1Y2gg dGhpbmcgYXMgZ2VuZXJpYyBPQXV0aCAyLjAuJm5ic3A7IEJ5IGRlZmluaXRpb24sIGl0IG11c3Qg YWx3YXlzIGJlIHVzZWQNCiBpbiBhbiBhcHBsaWNhdGlvbiBjb250ZXh0IHRoYXQgcHJvZmlsZXMg T0F1dGggMi4wIHRvIGVuYWJsZSBpbnRlcm9wZXJhYmlsaXR5LiZuYnNwOyBUaGUgZXhpc3Rpbmcg Ly53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIHZhbHVlIHdvcmtzIGZpbmUgZm9yIHRo aXMgcHVycG9zZS4mbmJzcDsgWWVzLCB0aGUgb3B0aWNzIG9mIGhhdmluZyBhIGRpZmZlcmVudCB2 YWx1ZSBtaWdodCBzZWVtIGJldHRlciBidXQgaXQgY29tZXMgYXQgdGhlIGNvc3Qgb2YgaW50ZXJv cGVyYWJpbGl0eQ0KIHByb2JsZW1zLiZuYnNwOyBJbiBteSB2aWV3LCBpbnRlcm9wIHRydW1wcyBv cHRpY3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UbyBhIHBv aW50IHRoYXQgR2VvcmdlIEZsZXRjaGVyIG1hZGUsIFdlYkZpbmdlciBjb3VsZCBzdGlsbCBiZSB1 c2VkIHRvIGxlYXJuIHRoZSBsb2NhdGlvbnMgb2YgdGhlc2UgY29uZmlndXJhdGlvbiBtZXRhZGF0 YSBkb2N1bWVudHMgaWYgdGhhdCBtYWtlcyBzZW5zZSBpbiB0aGUNCiBhcHBsaWNhdGlvbiBjb250 ZXh0LiZuYnNwOyBUaGUgZWRpdG9ycyB0b29rIFdlYkZpbmdlciBvdXQgb2YgdGhlIE9BdXRoIERp c2NvdmVyeSBkb2N1bWVudCBzaW5jZSBpdCBpc27igJl0IGFsd2F5cyBhcHBsaWNhYmxlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoZWVycyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IEpvaG4gQnJhZGxleSBbPGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj5tYWls dG86dmU3anRiQHZlN2p0Yi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBG ZWJydWFyeSAxOCwgMjAxNiA3OjQxIEFNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgJmx0Ozxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBEaXNjb3Zlcnkgc3Bl YyBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24gd2VsbC1r bm93bnMgYXJlIGdvaW5nIHRvIGJlIG9uIHRoZSByb290IGRvbWFpbi4gJm5ic3A7IFlvdSBjb3Vs ZCB0cnkgYW5kIGdldCBhIHVzZXIgdG8gcHV0IGluDQo8YSBocmVmPSJodHRwOi8vY3JtLmV4YW1w bGUuY29tIj5jcm0uZXhhbXBsZS5jb208L2E+LCBidXQgSSBzdXNwZWN0IHRoYXQgaXMgbm90IGdv aW5nIHRvIHdvcmsuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB0aGUgYXBwIGRvZXNu4oCZdCBoYXZlIGEgc3BlY2lmaWMgcHJvdG9jb2wgaWRlbnRpZmll ciB0aGVuIGl0IHdvdWxkIHVzZSB0aGUgZGVmYXVsdC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IGlmIHlv dSBjYW4gZ2V0IGFyb3VuZCBoYXZpbmcgc29tZSBzb3J0IG9mIGFwcC9wcm90b2NvbCBpZGVudGlm aWVyIGNvbmZpZ3VyZWQgaW4gdGhlIGFwcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDE4LCAyMDE2LCBhdCA5OjQ5IEFNLCBQaGls IEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50 QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJlc291cmNlIHNlcnZpY2UgWCBjb3VsZCBiZSBhbnkgaHR0cCBhY2Nl c3NpYmxlIHNlcnZpY2U6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4qIENSTTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KiBGaW5hbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qIFBheXJvbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiogRVJQPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qIGFueSBhcHBsaWNhdGlvbiBvbiB0aGUgd2ViLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3BlYyBzZWVt cyB0byBzdWdnZXN0IHRoYXQgd2UgdXNlIC8ud2VsbC1rbm93bi9jcm0gdG8gZGlzY292ZXIgT0F1 dGggY29uZmlnIGZvciBjcm0uICZuYnNwO0J1dCB0aGF0IG1heSBjYXVzZSBjb25mbGljdCBpZiBj cm0gaGFzIGl0cyBvd24gZGlzY292ZXJ5LiBXaGljaCBsZWFkcyB1cyBkb3duIHRoZSBwYXRoIG9m IGRvaW5nIHNvbWV0aGluZyBsaWtlIOKAnGNybS1vYXV0aOKAnS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiB0aGVyZSBpcyBjb25mdXNp b24gYWJvdXQgd2hhdCBob3N0IHRoZSBkaXNjb3ZlcnkgaXMgZG9uZSBvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGh5 cG90aGV0aWNhbGx5IGRvIEkgZG86PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdFVCAvLndlbGwta25vd24vY3JtPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3N0OiA8YSBocmVmPSJodHRwOi8v ZXhhbXBsZS5jb20vIj5leGFtcGxlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHdoYXQgYWJvdXQgdGhlIENSTeKAmXMgY29u ZmlndXJhdGlvbiBpbmZvcm1hdGlvbi4gSXMgdGhpcyBzdG9tcGluZyBvbiBpdD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IsIHdoYXQgSWYg d2UgcHV0IHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGF0IHRoZSBob3N0IGZvciB0aGUgY3JtIHNl cnZpY2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+R0VUIC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG9zdDogPGEgaHJlZj0i aHR0cDovL2NybS5leGFtcGxlLmNvbS8iPmNybS5leGFtcGxlLmNvbTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IHRoZSBwb2ludCBpcyB0aGF0IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBwcm90 ZWN0ZWQgcmVzb3VyY2UgYW5kIGl0cyBkZXNpZ25hdGVkIE9BdXRoIHNlcnZpY2UuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBj bGllbnQgbmVlZHMgdG8gZGlzY292ZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFdoZXJlIGlzIGl0cyBkZXNpZ25hdGVkIHJlc291cmNlIHNl cnZpY2UgYW5kIHdoYXQgc2VjdXJpdHkgZG9lcyBpdCB1c2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogSWYgaXQgaXMgT0F1dGgsIHdoZXJlIGlz IHRoZSBpbnRlbmRlZCBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGF0IHJlc291cmNlIHNlcnZp Y2UgaW5zdGFuY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bS8iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGZWIgMTgsIDIwMTYsIGF0IDc6MTkgQU0sIEpvaG4gQnJhZGxleSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2FuIHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4gYnkg4oCccmVzb3VyY2Ugc2VydmljZSB44oCd PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhhdCB0 aGUgUlMgYmFzZSBVUkkgZm9yIHRoZSByZXNvdXJjZSwgJm5ic3A7YSBzcGVjaWZpYyBVUkkgdGhh dCB0aGUgY2xpZW50IGlzIHJlcXVlc3Rpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgZ2V0dGluZyBVTUEgaXNoLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg Y29uY2VwdCBvZiBhIGJhc2UgUlMgVVJJIGlzIGEgcmF0IGhvbGUgdGhhdCBJIHByZWZlciBub3Qg dG8gZ28gZG93biwgYXMgaXQgaXMgc29tZXRoaW5nIGV2ZXJ5b25lIHRoaW5rcyBleGlzdHMgYnV0 IGxpa2UgU0NJTSBpZiBpdCBleGlzdHMgaXQgaXMgcHJvdG9jb2wgb3IgZGVwbG95bWVudCBzcGVj aWZpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIG5vdGlvbiB0aGF0IHlvdSB3b3VsZCBzZW5kIHRoZSBVUkkgeW91IGFyZSBwbGFubmlu ZyBvbiByZXF1ZXN0aW5nIHRvIGEgV2ViZmluZ2VyIHNlcnZlciB0byBmaW5kIHRoZSBPQXV0aCBz ZXJ2ZXIsIGlzIHByb2JhYmx5IGdvaW5nIHRvIGhhdmUgcHJpdmFjeSBpc3N1ZXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VzcGVjdCB0 aGF0IHlvdSBuZWVkIHRvIGhhbmQgYmFjayBhIGVycm9yIGZyb20gdGhlIHJlc291cmNlIHRvIHNh eSB3aGVyZSB0aGUgQVMgaXMsIG9yIGhhdmUgYSAud2VsbC1rbm93biBmb3IgdGhlIFJTLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SUyBkaXNj b3ZlcnkgcHJvYmFibHkgd2FudHMgdG8gYmUgc2VwYXJhdGUgZnJvbSBBUyBkaXNjb3ZlcnkuICZu YnNwOyhZZXMgSSBkbyB0aGluayB3ZSBuZWVkIHNvbWV0aGluZywgJm5ic3A7VU1BIHJwdCBvciBz b21ldGhpbmcgbGlrZSBpdCBtaWdodCBiZSBhIHdheSB0byBnbyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRmViIDE4LCAyMDE2LCBhdCA5OjA2IEFNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIFND SU0gd2FzIGEgYmFkIGV4YW1wbGUuICZuYnNwO0l0IGZ1bmN0aW9ucyBhcyBhIFJFU1RmdWwgcmVz b3VyY2UgaW4gdGhlIGNvbnRleHQgb2YgT0F1dGguPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZpbmQgdGhlIHVzZSBvZiBPSURDIHRvIGJlIGNvbmZ1c2lu ZyBhcyBhbiBleGFtcGxlIChhbmQgdGhlIGRlZmF1bHQpIGJlY2F1c2UgaXQgaXMgYm90aCBhbiBP QXV0aCByZXNvdXJjZSBhbmQgYSBzZWN1cml0eSBzZXJ2aWNlLiAmbmJzcDtJdCBpcyBhIG1vZGlm aWNhdGlvbiBvZiBPQXV0aC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlN0YXJ0IHRoaW5raW5nIGFib3V0IGV2ZXJ5IGFwcGxpY2F0aW9uIGV2ZXIgd3JpdHRl biB0aGF0IHVzZXMgT0F1dGguIEFyZSB3ZSBleHBlY3RpbmcgMTAwcyBvZiB0aG91c2FuZHMgb2Yg dGhlc2UgdG8gZWFjaCByZWdpc3Rlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbWUsIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBhIGZpbmUg c3BlY2lmaWNhdGlvbiBmb3IgT0lEQyBhbmQgaXQgc2hvdWxkIGJlIHB1Ymxpc2hlZCB0aGVyZSBi ZWNhdXNlIHRoZSBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaG93IHRvIGRpc2NvdmVyeSBPQXV0aCBh bmQgT3BlbklEIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5MaWtld2lzZSB5b3Ugc3VnZ2VzdCBpdCBpcyBvayBmb3IgU0NJ TSB0byBkbyB0aGUgc2FtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkbyB3ZSBleHBlY3Qgbm9ybWFsIGFwcGxp Y2F0aW9ucyB0byBzZXQgdXAgYW5kIGRvIGRpc2NvdmVyeT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0 aGF0IGFuIOKAnE9BVVRI4oCdIGRpc2NvdmVyeSBzcGVjIHNob3VsZCBoYXZlIGEgcGFyYW1ldGVy IHRvIGFzaywgSSB3YW50IHRvIGRpc2NvdmVyIE9BdXRoIGNvbmZpZ3VyYXRpb24gZm9yIHJlc291 cmNlIHNlcnZpY2UgWC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCBzdGlsbCBhbGxvd3MgbWUgdG8gaGF2ZSBhIHNlcGFyYXRlIGRpc2Nv dmVyeSBzZXJ2aWNlIHRoYXQgc2F5cywgdGVsbCBtZSBhYm91dCByZXNvdXJjZSBzZXJ2aWNlIFgg aXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CVFcuIEkgdGhpbmsgd2UgYXJlIEZBUiBmcm9tIExhc3QgQ2FsbCBvbiB0aGlzIHRvcGlj LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBo aWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRmViIDE4LCAyMDE2LCBhdCA2OjU1IEFNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZmZyZW50IHBy b3RvY29scyBsaWtlIENvbm5lY3QgYW5kIFNDSU0gbWF5IGhhdmUgZGlmZmVyZW50IGNvbmZpZ3Vy YXRpb25zLCBlbmRwb2ludHMgLCBrZXlzICwgYXV0aGVudGljYXRpb24gbWV0aG9kcywgc2NvcGVz IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNo b3VsZCBiZSBwb3NhYmxlIHRvIGhhdmUgdGhlbSBhcyBvbmUgZG9jdW1lbnQsIGJ1dCBmb3JjaW5n IHRoZW0gdG8gdXNlIG9uZSBkb2N1bWVudCBpcyBnb2luZyB0byBjYXVzZSBhIGV4cGxvc2lvbiBv ZiBjbGFpbSByZWdpc3RyYXRpb24gZm9yIGRpc2NvdmVyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyBiZXR0ZXIgZm9y IFNDSU0gdG8gcmVnaXN0ZXIgb25lIHdlbGwga25vd24gdGhhbiB0byBoYXZlIHRvIHJlZ2lzdGVy IDIwIGNsYWltcyB3aXRoIHNjaW0gcHJlZml4ZXMgb3Igc29tZXRoaW5nIHNpbGx5IGxpa2UgdGhh dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TmFtZS1zcGFjaW5nIHRoZSBjbGFpbXMgYnkgYWxsb3dpbmcgdGhlbSB0byBiZSBpbiBkaWZmZXJl bnQgd2VsbCBrbm93biBmaWxlcyBpcyBub3QgdW5yZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZW1lbWJlciBzb21lIG9mIHRo ZXNlIHByb3RvY29scyBtYXkgYmUgaG9zdGVkIG9uIFNhYVMgc28gdGhlcmUgaXMgbm8gZ3VhcmFu dGVlIHRoYXQgYWxsIHByb3RvY29scyB3aWxsIGhhdmUgdGhlIHNhbWUgT0F1dGggQ29uZmlnLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Ro aW5nIHN0b3BzIGEgcHJvdG9jb2wgZnJvbSBkb2luZyB3aGF0IGl0IGxpa2VzIHdpdGggd2ViZmlu Z2VyIGlmIGl0IHdhbnRzIHRvIHVzZSB0aGF0IGZvciBkaXNjb3ZlcnkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHByaW5jaXBhbCBJIGxp a2UgdGhlIGlkZWEgb2YgaGF2aW5nIGFub3RoZXIgcHJvdG9jb2wgYXMgYW4gZXhhbXBsZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgb25s eSBjb25jZXJuIGlzIHRoYXQgSSBoYXZlbuKAmXQgc2VlbiBhbnkgZGlzY3Vzc2lvbiBvZiB5b3Vy IFNDSU0gZGlzY292ZXJ5IGRvY3VtZW50IGluIHRoZSBTQ0lNIFdHLiAmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxseSB0 aGluayBzb3J0aW5nIG91dCBkaXNjb3ZlcnkgZm9yIFNDSU0gaXMgYSBnb29kIGlkZWEsICZuYnNw O2J1dCBPQVVUaCBpcyBidXQgb25lIG9mIHNldmVyYWwgYXV0aGVudGljYXRpb24gbWV0aG9kcyBm b3IgU0NJTSwgYW5kIHRoZXJlIGFyZSBwcm9iYWJseSBvdGhlciBub24gT0F1dGggdGhpbmdzIHRo YXQgd2FudCB0byBiZSBkZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgZmVlbCBiZXR0ZXIgYWJvdXQgdXNpbmcgaXQg YXMgYW4gZXhhbXBsZSBpZiBpdCB3ZXJlIGFkb3B0ZWQgYnkgdGhlIFdHIGFuZCBzb21lIGdlbmVy YWwgaW50ZXJlc3Qgc2hvd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgZW5jb3VyYWdlIHlvdSB0byBkbyB0aGF0IHNvIHdlIGNhbiB1c2Ug aXQgYXMgYSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTgsIDIwMTYsIGF0IDg6MzUgQU0sIFBoaWwgSHVu dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgc3RpbGwgZmluZCB0aGUgZm9sbG93aW5nIHRleHQgb2JqZWN0 aW9uYWJsZSBhbmQgY29uZnVzaW5n4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBCeSBkZWZh dWx0LCBmb3IgaGlzdG9yaWNhbCByZWFzb25zLCB1bmxlc3MgYW4gYXBwbGljYXRpb24tc3BlY2lm aWM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij4mbmJzcDsmbmJzcDsgd2VsbC1rbm93biBVUkkgcGF0aCBzdWZmaXggaXMgcmVnaXN0ZXJlZCBh bmQgdXNlZCBmb3IgYW4gYXBwbGljYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IHRoZSBjbGllbnQgZm9yIHRo YXQgYXBwbGljYXRpb24gU0hPVUxEIHVzZSB0aGUgd2VsbC1rbm93biBVUkkgcGF0aDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZu YnNwOyBzdWZmaXggJnF1b3Q7b3BlbmlkLWNvbmZpZ3VyYXRpb24mcXVvdDsgYW5kIHB1Ymxpc2gg dGhlIG1ldGFkYXRhIGRvY3VtZW50IGF0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IHRoZSBwYXRoIGZvcm1lZCBieSBj b25jYXRlbmF0aW5nICZxdW90Oy8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PiZuYnNwOyZuYnNwOyB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBpc3N1ZXIgaWRlbnRp Zmllci4mbmJzcDsgQXMgZGVzY3JpYmVkIGluPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxI3NlY3Rpb24t NSI+U2VjdGlvbiA1PC9hPiwgZGVzcGl0ZSB0aGUgaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyAmcXVv dDsvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24mcXVvdDssIGFwcGVhcmluZyB0byBi ZSBPcGVuSUQtc3BlY2lmaWMsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IGl0cyB1c2FnZSBpbiB0aGlzIHNwZWNpZmlj YXRpb24gaXMgYWN0dWFsbHkgcmVmZXJyaW5nIHRvIGEgZ2VuZXJhbDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyBPQXV0 aCAyLjAgZmVhdHVyZSB0aGF0IGlzIG5vdCBzcGVjaWZpYyB0byBPcGVuSUQgQ29ubmVjdC48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GdXJ0 aGVyLCBhcyBhIGRlZmF1bHQg4oCcb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0gYXMgdGhlIGRlZmF1 bHQgZnVydGhlciBnaXZlcyBwZW9wbGUgdGhlIGltcHJlc3Npb24gdGhhdCBhIHBsYWluIE9BdXRo IHNlcnZlciAqaXMqIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBhbmQgdGhhdCB0aGUgbm9ybWFs IGFjY2VzcyB0b2tlbiByZWNlaXZlZCBpcyBldmlkZW5jZSBvZiBhIHN1Y2Nlc3NmdWwgYXV0aGVu dGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IHdvdWxkIGJlIGJldHRlciB0byBwb2ludCBvdXQgdGhhdCBhcHBsaWNhdGlvbiBt YXkgaW5jbHVkZSBvYXV0aCBkaXNjb3ZlcnkgaW4gdGhlaXIgZGlzY292ZXJ5IFVSSSBhbmQgdGhh dCBPQXV0aCBpcyBhbiBleGFtcGxlIG9mIHRoaXMuIEl0IG1pZ2h0IGJlIGdvb2QgdG8gaW5jbHVk ZSB0d28gZXhhbXBsZXMuICZuYnNwO0UuZy4gT0lEQyBhbmQgU0NJTSAoYXMgYW5vdGhlciByZWZl cmVuY2VhYmxlIGV4YW1wbGUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiBHRVQgLy53ZWxsLWtub3duL29wZW5p ZC1jb25maWd1cmF0aW9uPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4gR0VUIC8ud2VsbC1rbm93bi9zY2ltPG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZXRyaWV2ZSB0aGUgT0F1dGggY29uZmlndXJhdGlvbiBmb3IgdGhlIGFwcGxpY2F0aW9uIG9wZW5p ZCBhbmQgc2NpbSByZXNwZWN0aXZlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHVzZSBvZjo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+IEdF VCAvLndlbGwta25vd24vb2F1dGgyLzxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2hvdWxkIGJlIHRoZSBkZWZhdWx0IHVzZWQgd2hlbiB0aGVyZSBpcyBubyBr bm93biBhcHBsaWNhdGlvbiBiYXNlZCB3ZWxsLWtub3duIGFwcGxpY2F0aW9uIGJhc2VkIFVSSSBk aXNjb3ZlcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T2YgY291cnNlLCB0aGUgY29uY2VybiBJIHJhaXNlZCBlYXJsaWVyIGlz IHRoYXQgdGhpcyBhcHByb2FjaCBvZiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBVUklzIGVuZHMgdXAg cmVxdWlyaW5nIGV2ZXJ5IGFwcGxpY2F0aW9uIHRvIG1ha2UgYW4gSUFOQSByZWdpc3RyYXRpb24g aWYgdGhleSBkb27igJl0IHdhbnQgdG8gdXNlIHRoZSBkZWZhdWx0IG9mIOKAnG9hdXRoMuKAnSAo b3Ig4oCcb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0pLiAmbmJzcDtJcw0KIHRoYXQgd2hhdCB0aGUg YXV0aG9ycyBleHBlY3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0IHNlZW1lZCBiZXR0ZXIgdG8gbWUgdG8gdXNlIHRoZSB3ZWJmaW5nZXIg c3ludGF4IHRvIGFsbG93IHRoZSBjbGllbnQgdG8gc2F5IOKAnEkgd2FudCB0aGUgZGVzaWduYXRl ZCBPQXV0aCBjb25maWd1cmF0aW9uIGZvciB0aGUgcmVzb3VyY2Ugc2VydmljZSBY4oCdIHdvdWxk IGJlIGEgYmV0dGVyIGRlc2lnbiB0aGF0IGF2b2lkcyBleHRlbnNpdmUgSUFOQSByZWdpc3RyYXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iPnd3dy5p bmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGZWIgMTcsIDIwMTYsIGF0IDExOjQ4IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gcmVzcG9uc2UgdG8gd29ya2luZyBncm91cCBp bnB1dCwgdGhpcyB2ZXJzaW9uIG9mIHRoZSBPQXV0aCBEaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbiBo YXMgYmVlbiBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlIOKAkyBsZWF2aW5nIG9ubHkgdGhlIGZl YXR1cmVzIHRoYXQgYXJlIGFscmVhZHkgd2lkZWx5DQogZGVwbG95ZWQuJm5ic3A7IFNwZWNpZmlj YWxseSwgYWxsIHRoYXQgcmVtYWlucyBpcyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZGlzY292ZXJ5IG1ldGFkYXRhIGRvY3VtZW50IGFuZCB0aGUgbWV0YWRhdGEg dmFsdWVzIHVzZWQgaW4gaXQuICZuYnNwO1RoZSBXZWJGaW5nZXIgZGlzY292ZXJ5IGxvZ2ljIGhh cyBiZWVuIHJlbW92ZWQuJm5ic3A7IFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgaXNzdWVy IGlkZW50aWZpZXIgVVJMIGFuZA0KIHRoZSB3ZWxsLWtub3duIFVSSSBwYXRoIHJlbGF0aXZlIHRv IGl0IGF0IHdoaWNoIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgaXMgbG9jYXRlZCBo YXMgYWxzbyBiZWVuIGNsYXJpZmllZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+R2l2ZW4gdGhhdCB0aGlzIG5vdyBkZXNjcmliZXMgb25seSBmZWF0dXJlcyB0 aGF0IGFyZSBpbiB3aWRlc3ByZWFkIGRlcGxveW1lbnQsIHRoZSBlZGl0b3JzIGJlbGlldmUgdGhh dCB0aGlzIHZlcnNpb24gaXMgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgc3BlY2lmaWNhdGlv biBpcyBhdmFpbGFibGUgYXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wMSI+PHNw YW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW4gSFRNTC1mb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNv IGF2YWlsYWJsZSBhdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly9z ZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEuaHRtbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3Mv ZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEuaHRtbDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlICZhbXA7IE5hdCAmYW1w OyBKb2huPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlAuUy4m bmJzcDsgVGhpcyBub3RpY2Ugd2FzIGFsc28gcG9zdGVkIGF0PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5p bmZvLz9wPTE1NDQiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby8/cD0xNTQ0PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+YW5kDQogYXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVk Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+QHNlbGZpc3N1ZWQ8L3NwYW4+PC9hPi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj5PQXV0aEBpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442A2C32028C2B46192FF65F5AF0BY2PR03MB442namprd_-- From nobody Thu Feb 18 09:22:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE181ACDD8 for ; Thu, 18 Feb 2016 09:22:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6glDyxX6eYM for ; Thu, 18 Feb 2016 09:22:00 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 78DA71ACAD4 for ; Thu, 18 Feb 2016 09:22:00 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id e185so50823021vkb.1 for ; Thu, 18 Feb 2016 09:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Z90KeViVOHpfrQqimxDubnbJUGcboZn2q9VKzdnSRlA=; b=pstLGZXdLQqStJjfL2M0Stw1e4SxzL07Se7EmtExQe/QyavgRfTikHcqqCbVLOeacl H97YhhR8Xv2oY7/DFyo7tzlGmMCgljumjvXOTgfWorrnfqK0WYUhaC1lZLLdiwmldXHK WiUCwuzRXEhPPH/wYfU8pS0SaHEaX78bvVPpRMRx2U7hIgYueaAoPaZB48S5tigddtus IoqNdnZTRlsTeS6Dlvw6Z4I9SR1h+mZJ/j7WRQSCYep1xLBMdOSetSu3gFX42+RqcRee i2b2hA0REd1QReGyNRSt1b7vpJJy1sjw7KSwaM9/5//gtrf2K1f9Ix+C2+bekMt5ajVh ncyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Z90KeViVOHpfrQqimxDubnbJUGcboZn2q9VKzdnSRlA=; b=GgjWe6nAKY3sq9MQMGJsYsM8UI0Fzz1k+qPLhCobmVB0u2pNqzAmAkO8NKxToD2+zM 0KhTnRDedocVmuNUi4RqpkExUjnGs+tGB/vaPsUpOSRUY1+6yAzLq2MybsN3sdnUJp5p HkZxRHkUh/XqRajmg/v7USZujWvnzeNStNaGNa4/eBAodNXUMAnVmdMkkK0VdDEFrgaq bu3VIq3cC4Lx3WIIp+pt3f5tuuTw4sZ+wdzlz7/iG0hU55ioHF+4FkrHESTO0HTnDBb3 pBf8VBkCWQNjRnTnrxGuvRZ2GFY32DqCpKgdPPjJHRVIpuIyJoUUneHIM1YulcVyfhWW 5jqQ== X-Gm-Message-State: AG10YOSUfcL9pXMjaPmrjUnDmXi5PdIn1YP6fZr1A5zfwrsXOarQP2pNdeHV7mjBsRtRMQ== X-Received: by 10.31.173.8 with SMTP id w8mr7236242vke.42.1455816119414; Thu, 18 Feb 2016 09:21:59 -0800 (PST) Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id w144sm850818vkd.2.2016.02.18.09.21.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 09:21:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3A280F6A-FA7F-49A4-835C-4817D00CFBD1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> Date: Thu, 18 Feb 2016 12:21:56 -0500 Message-Id: <6FEF11D0-C150-4DDA-9152-A71FBC28564C@ve7jtb.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> To: "Phil Hunt (IDM)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:22:06 -0000 --Apple-Mail=_3A280F6A-FA7F-49A4-835C-4817D00CFBD1 Content-Type: multipart/alternative; boundary="Apple-Mail=_8FE79537-7EF4-4152-A8A1-55A33DD52DB2" --Apple-Mail=_8FE79537-7EF4-4152-A8A1-55A33DD52DB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The protocol would need to have a .well-known location registered or use = the default well-known for OAuth. Apps would look for there specific configuration and fall back to the = generic one if that is not available. To save apps making multiple request the server can just link the app = specific well-knowns to the OAuth well-known. I don=E2=80=99t know of a OAuth app that doesn=E2=80=99t have = preconfigured logic about the API it is using. =20 Part of that pre configuration should be what well-known file to look = for if required. Also nothing stops enterprises from making up there own well-known = locations for specific apps. Also it would be up to app /api developers to register a well known for = oauth and one for whatever else they need to configure, or if it is a = small amount of info they could extend the OAuth discovery registry with = a resource URI location for the protocol etc. John B. > On Feb 18, 2016, at 12:09 PM, Phil Hunt (IDM) = wrote: >=20 > How does the client request the oauth configuration assigned to xyz? >=20 > The example you give appears to presume a single oauth infrastructure = for all apps.=20 >=20 > The only way right now to have apps specific oauth is to infer the = relation by the domain "xyz.example.com ". =20 >=20 > That makes discovery more complex because there arw many more = discovery locations and many more configurations to maintain.=20 >=20 > If example.com had separate oauth servers for = services xyz and abc, how would discovery work from a single /.well-know = endpoint? >=20 > Phil >=20 > On Feb 18, 2016, at 09:41, Mike Jones > wrote: >=20 >> Let me second John=E2=80=99s point that OAuth configuration = information and application configuration information need not be = interspersed. For instance, if the service is at https://example.com = and the XYZ application is being used, then these = configuration metadata documents could both be used: >> =C2=B7 https://example.com/.well-known/openid-configuration = - OAuth = configuration metadata >> =C2=B7 https://example.com/.well-known/xyz-configuration = - XYZ configuration = metadata >> =20 >> There=E2=80=99s not much point in defining a new = /.well-known/oauth2.0 value, since there is no such thing as generic = OAuth 2.0. By definition, it must always be used in an application = context that profiles OAuth 2.0 to enable interoperability. The = existing /.well-known/openid-configuration value works fine for this = purpose. Yes, the optics of having a different value might seem better = but it comes at the cost of interoperability problems. In my view, = interop trumps optics. >> =20 >> To a point that George Fletcher made, WebFinger could still be used = to learn the locations of these configuration metadata documents if that = makes sense in the application context. The editors took WebFinger out = of the OAuth Discovery document since it isn=E2=80=99t always = applicable. >> =20 >> Cheers, >> -- Mike >> =C2=A0 <> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com = ]=20 >> Sent: Thursday, February 18, 2016 7:41 AM >> To: Phil Hunt > >> Cc: Mike Jones >; oauth@ietf.org = >> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its = essence >> =20 >> I suspect that the configuration well-knowns are going to be on the = root domain. You could try and get a user to put in crm.example.com = , but I suspect that is not going to work. >> =20 >> If the app doesn=E2=80=99t have a specific protocol identifier then = it would use the default. =20 >> =20 >> I don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app. >> =20 >> John B. >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> On Feb 18, 2016, at 9:49 AM, Phil Hunt > wrote: >> =20 >> resource service X could be any http accessible service: >> =20 >> * CRM >> * Finance >> * Payroll >> * ERP >> * any application on the web. >> =20 >> The spec seems to suggest that we use /.well-known/crm to discover = OAuth config for crm. But that may cause conflict if crm has its own = discovery. Which leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. >> =20 >> Then there is confusion about what host the discovery is done on. >> =20 >> For example, hypothetically do I do: >> =20 >> GET /.well-known/crm >> Host: example.com >> =20 >> But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? >> =20 >> Or, what If we put the oauth configuration at the host for the crm = service: >> GET /.well-known/openid-configuration >> Host: crm.example.com >> =20 >> I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 >> =20 >> The client needs to discover: >> * Where is its designated resource service and what security does it = use >> * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Feb 18, 2016, at 7:19 AM, John Bradley > wrote: >> =20 >> Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? >> =20 >> Is that the RS base URI for the resource, a specific URI that the = client is requesting? >> =20 >> That is getting UMA ish.=20 >> =20 >> The concept of a base RS URI is a rat hole that I prefer not to go = down, as it is something everyone thinks exists but like SCIM if it = exists it is protocol or deployment specific. >> =20 >> The notion that you would send the URI you are planning on requesting = to a Webfinger server to find the OAuth server, is probably going to = have privacy issues. >> =20 >> I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. >> =20 >> RS discovery probably wants to be separate from AS discovery. (Yes I = do think we need something, UMA rpt or something like it might be a way = to go) >> =20 >> John B. >> =20 >> On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: >> =20 >> Maybe SCIM was a bad example. It functions as a RESTful resource in = the context of OAuth. >> =20 >> I find the use of OIDC to be confusing as an example (and the = default) because it is both an OAuth resource and a security service. = It is a modification of OAuth. >> =20 >> Start thinking about every application ever written that uses OAuth. = Are we expecting 100s of thousands of these to each register? >> =20 >> To me, this specification is a fine specification for OIDC and it = should be published there because the specification defines how to = discovery OAuth and OpenID information. >> =20 >> Likewise you suggest it is ok for SCIM to do the same.=20 >> =20 >> How do we expect normal applications to set up and do discovery? >> =20 >> It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. >> =20 >> That still allows me to have a separate discovery service that says, = tell me about resource service X itself. >> =20 >> BTW. I think we are FAR from Last Call on this topic. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: >> =20 >> Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >> =20 >> It should be posable to have them as one document, but forcing them = to use one document is going to cause a explosion of claim registration = for discovery. >> =20 >> I think it is better for SCIM to register one well known than to have = to register 20 claims with scim prefixes or something silly like that. >> =20 >> Name-spacing the claims by allowing them to be in different well = known files is not unreasonable. >> =20 >> Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. >> =20 >> Nothing stops a protocol from doing what it likes with webfinger if = it wants to use that for discovery. >> =20 >> In principal I like the idea of having another protocol as an = example. >> =20 >> My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 >> I personally think sorting out discovery for SCIM is a good idea, = but OAUTh is but one of several authentication methods for SCIM, and = there are probably other non OAuth things that want to be described. >> =20 >> I would feel better about using it as an example if it were adopted = by the WG and some general interest shown. >> =20 >> I encourage you to do that so we can use it as a example. >> =20 >> John B. >> =20 >> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >> =20 >> I still find the following text objectionable and confusing=E2=80=A6 >> By default, for historical reasons, unless an application-specific >> well-known URI path suffix is registered and used for an = application, >> the client for that application SHOULD use the well-known URI path >> suffix "openid-configuration" and publish the metadata document at >> the path formed by concatenating = "/.well-known/openid-configuration" >> to the authorization server's issuer identifier. As described in >> Section 5 = , = despite the identifier >> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >> its usage in this specification is actually referring to a general >> OAuth 2.0 feature that is not specific to OpenID Connect. >> =20 >> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >> =20 >> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >> =20 >> GET /.well-known/openid-configuration >> and >> GET /.well-known/scim >> Retrieve the OAuth configuration for the application openid and scim = respectively. >> =20 >> The use of: >> GET /.well-known/oauth2/ >> Should be the default used when there is no known application based = well-known application based URI discovery. >> =20 >> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >> =20 >> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> =20 >> =20 >> =20 >>=20 >> =20 >> On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: >> =20 >> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship = between the issuer identifier URL and the well-known URI path relative = to it at which the discovery metadata document is located has also been = clarified. >> =20 >> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >> =20 >> The specification is available at: >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >> =20 >> An HTML-formatted version is also available at: >> =C2=B7 = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >> =20 >> -- Mike & = Nat & John >> =20 >> P.S. This notice was also posted at http://self-issued.info/?p=3D1544 = and as @selfissued = . >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_8FE79537-7EF4-4152-A8A1-55A33DD52DB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The protocol would need to have a .well-known location = registered or use the default well-known for OAuth.

Apps would look for there specific = configuration and fall back to the generic one if that is not = available.

To = save apps making multiple request the server can just link the  app = specific well-knowns  to the OAuth well-known.

I don=E2=80=99t know of = a OAuth app that doesn=E2=80=99t have preconfigured logic about the API = it is using.  
Part of that pre configuration = should be what well-known file to look for if required.

Also nothing stops = enterprises from making up there own well-known locations for specific = apps.

Also it = would be up to app /api developers to register a well known for oauth = and one for whatever else they need to configure, or if it is a small = amount of info they could extend the OAuth discovery registry with a = resource URI location for the protocol etc.

John B.

On Feb 18, 2016, at 12:09 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

How does the client request = the oauth configuration assigned to xyz?

The = example you give appears to presume a single oauth infrastructure for = all apps. 

The only = way right now to have apps specific oauth is to infer the relation by = the domain "xyz.example.com". =  

That = makes discovery more complex because there arw many more discovery = locations and many more configurations to maintain. 

If example.com had separate oauth servers = for services xyz and abc, how would discovery work from a single = /.well-know endpoint?

Phil

On Feb 18, 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com> wrote:

Let me second John=E2=80=99s point that = OAuth configuration information and application configuration = information need not be interspersed.  For instance, if the service = is at https://example.com and the XYZ application is = being used, then these configuration metadata documents could both be = used:
=C2=B7       https://example.com/.well-known/openid-configuration - OAuth configuration = metadata
=C2=B7       https://example.com/.well-known/xyz-configuration - XYZ configuration = metadata
 
There=E2=80=99s not much = point in defining a new /.well-known/oauth2.0 value, since there is no = such thing as generic OAuth 2.0.  By definition, it must always be = used in an application context that profiles OAuth 2.0 to enable = interoperability.  The existing /.well-known/openid-configuration = value works fine for this purpose.  Yes, the optics of having a = different value might seem better but it comes at the cost of = interoperability problems.  In my view, interop trumps optics.
 
To = a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context.  The editors took WebFinger = out of the OAuth Discovery document since it isn=E2=80=99t always = applicable.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Cheers,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, February 18, 2016 = 7:41 AM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth = Discovery spec pared down to its essence
 
I suspect that the configuration well-knowns are going to be = on the root domain.   You could try and get a user to put in crm.example.com, but I = suspect that is not going to work.
 
If the app doesn=E2=80=99t have a specific protocol = identifier then it would use the default.  
 
I don=E2=80=99t know if you can get = around having some sort of app/protocol identifier configured in the = app.
 
John B.
 
 
 
 
 
 
On = Feb 18, 2016, at 9:49 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
 
resource service X = could be any http accessible service:
 
* CRM
* Finance
* Payroll
* ERP
* any application on = the web.
 
The spec seems to suggest that we use = /.well-known/crm to discover OAuth config for crm.  But that may = cause conflict if crm has its own discovery. Which leads us down the = path of doing something like =E2=80=9Ccrm-oauth=E2=80=9D.
 
Then there is confusion about what host = the discovery is done on.
 
For example, hypothetically do I do:
 
GET /.well-known/crm
 
But what about the CRM=E2=80=99s = configuration information. Is this stomping on it?
 
Or, what If we put the oauth = configuration at the host for the crm service:
GET /.well-known/openid-configuration
 
I think the point is = that there is a relationship between a protected resource and its = designated OAuth service. 
 
The client needs to discover:
* Where is its designated resource service and what security = does it use
* If it is OAuth, where is the intended = OAuth configuration for that resource service instance?
 
Phil
 
@independentid
www.independentid.com
 
 

 

 
On = Feb 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
 
Can you clarify what = you mean by =E2=80=9Cresource service x=E2=80=9D?
 
Is that the RS base URI for the resource, =  a specific URI that the client is requesting?
 
That is getting UMA ish. 
 
The concept of a base RS URI is a rat = hole that I prefer not to go down, as it is something everyone thinks = exists but like SCIM if it exists it is protocol or deployment = specific.
 
The notion that you would send the URI you are = planning on requesting to a Webfinger server to find the OAuth server, = is probably going to have privacy issues.
 
I suspect that you need to hand back a = error from the resource to say where the AS is, or have a .well-known = for the RS.
 
RS discovery probably wants to be separate from AS = discovery.  (Yes I do think we need something,  UMA rpt or = something like it might be a way to go)
 
John B.
 
On = Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
 
Maybe SCIM was a bad = example.  It functions as a RESTful resource in the context of = OAuth.
 
I find the use of = OIDC to be confusing as an example (and the default) because it is both = an OAuth resource and a security service.  It is a modification of = OAuth.
 
Start thinking about = every application ever written that uses OAuth. Are we expecting 100s of = thousands of these to each register?
 
To me, this specification is a fine specification for = OIDC and it should be published there because the specification defines = how to discovery OAuth and OpenID information.
 
Likewise you suggest it is ok for SCIM to = do the same. 
 
How do we expect normal applications to = set up and do discovery?
 
It seems to me that an =E2=80=9COAUTH=E2=80= =9D discovery spec should have a parameter to ask, I want to discover = OAuth configuration for resource service X.
 
That still allows me to have a separate = discovery service that says, tell me about resource service X = itself.
 
BTW. I think we are FAR from Last Call on this = topic.
 
Phil
 
@independentid
www.independentid.com
 
 

 

 
On = Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
 
Diffrent protocols = like Connect and SCIM may have different configurations, endpoints , = keys , authentication methods, scopes etc.
 
It should be posable to have them as one document, = but forcing them to use one document is going to cause a explosion of = claim registration for discovery.
 
I think it is better for SCIM to register one well = known than to have to register 20 claims with scim prefixes or something = silly like that.
 
Name-spacing the claims by allowing them to be in = different well known files is not unreasonable.
 
Remember some of these protocols may be = hosted on SaaS so there is no guarantee that all protocols will have the = same OAuth Config.
 
Nothing stops a protocol from doing what it likes = with webfinger if it wants to use that for discovery.
 
In principal I like the idea of having = another protocol as an example.
 
My only concern is that I haven=E2=80=99t seen any = discussion of your SCIM discovery document in the SCIM WG.  
I personally think sorting out discovery for SCIM is a good = idea,  but OAUTh is but one of several authentication methods for = SCIM, and there are probably other non OAuth things that want to be = described.
 
I would feel better about using it as an example if = it were adopted by the WG and some general interest shown.
 
I encourage you to do that so we can use = it as a example.
 
John B.
 
On Feb 18, 2016, at = 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
 
I still find the = following text objectionable and confusing=E2=80=A6
   By default, for =
historical reasons, unless an application-specific
   well-known URI path suffix is registered and =
used for an application,
   the client for that =
application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the =
metadata document at
   the path formed by =
concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer =
identifier.  As described in
   Section =
5, despite the identifier
   =
"/.well-known/openid-configuration", appearing to be =
OpenID-specific,
   its usage in this =
specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID =
Connect.
 
Further, as a default =E2=80=9Copenid-configuration=E2=80= =9D as the default further gives people the impression that a plain = OAuth server *is* an authentication server and that the normal access = token received is evidence of a successful authentication.
 
It would be better to point out that = application may include oauth discovery in their discovery URI and that = OAuth is an example of this. It might be good to include two examples. =  E.g. OIDC and SCIM (as another referenceable example).
 
 GET =
/.well-known/openid-configuration
and
 GET /.well-known/scim
Retrieve the OAuth configuration for the = application openid and scim respectively.
 
The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application = based well-known application based URI discovery.
 
Of course, the = concern I raised earlier is that this approach of application specific = URIs ends up requiring every application to make an IANA registration if = they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D = (or =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the = authors expect?
 
It seemed better to me to use the webfinger syntax to = allow the client to say =E2=80=9CI want the designated OAuth = configuration for the resource service X=E2=80=9D would be a better = design that avoids extensive IANA registration.
 
Phil
 
@independentid
www.independentid.com
 
 

 

 
On = Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
In response to working = group input, this version of the OAuth Discovery specification has been = pared down to its essence =E2=80=93 leaving only the features that are = already widely deployed.  Specifically, all that remains is the = definition of the authorization server discovery metadata document and = the metadata values used in it.  The WebFinger discovery logic has = been removed.  The relationship between the issuer identifier URL = and the well-known URI path relative to it at which the discovery = metadata document is located has also been clarified.
 
Given that this now describes only features that = are in widespread deployment, the editors believe that this version is = ready for working group last call.
 
The specification is available at:
 
An= HTML-formatted version is also available at:
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike & = Nat & John
 
P.S.  This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.
_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_8FE79537-7EF4-4152-A8A1-55A33DD52DB2-- --Apple-Mail=_3A280F6A-FA7F-49A4-835C-4817D00CFBD1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTgxNzIxNTZaMCMGCSqGSIb3DQEJBDEWBBS192m6Q952rJ4sY0b3zxJ1 v8RF/TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBvPV3OYXsx4cPHmJFq8S9YYhEPQskO8ecQz+m48fq90iF5uuI0fmFH plirZ4qvOAWN2t9ATFPm7pw9Sh4N7ktnmfPS6wPlonD2s/v3vIdq+1U+98ea5DdDkizm7lnPl1rv Byrzbb6JjzMdonVoUsZ2Nq0q2klJtWj6kPvNu0QbubF7W3Aj4/0XlS4yYpoRomyFDpLs4oqTRxmf NGTBUlpPXBFEnAhHeBbX2zUXlLnQtYd6OncQxOu54r/gxVuGMxPiwaEJvUsBjKyRBqKPSJdB6FtA n48r2C6PpYBS2hlpfb4MB1ZViDdr+f10wrq4YZHNSr9nuGBNT0bmjdycyM4xAAAAAAAA --Apple-Mail=_3A280F6A-FA7F-49A4-835C-4817D00CFBD1-- From nobody Thu Feb 18 09:29:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F376A1B3082 for ; Thu, 18 Feb 2016 09:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 J06GSZ3SE1i9 for ; Thu, 18 Feb 2016 09:29:13 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 21E481B3074 for ; Thu, 18 Feb 2016 09:29:13 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id xk3so78172776obc.2 for ; Thu, 18 Feb 2016 09:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=krV1WC2lhwBXoatRuMn34sVUUTCvmw/odvSoz3dz/Wg=; b=VQcO49UnjQ8GtMW0F3Ke5AF1LScgUgEB4TNiBN2RDBT3Yxlk8U9ePJcVtMVyu6XQRq IT7WI6l1kT9z4nEeOkJpuooP9wVPXDWRlCSZaLrgAbhq8M2HYG9btw5XbQRW91sW2HIE 2XdV0e6RWk0diyX/l89hq0eKuhu0elL+UelZGEyYpSGJyoXKrOy7TRofKMFaJ53b9jYf puQ/v4X8BMbKOQLL6BLHGjvzxAAgVcIHW/S0wbeI9wD5VcIqlPIl34HBCc0gnX023/xd zDVOAOUwmTz0xzItc/brTX/Ld1XR8mlOUcdyPY480SLcV2cz4UxRo1++RFiripoZCfoW DZtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=krV1WC2lhwBXoatRuMn34sVUUTCvmw/odvSoz3dz/Wg=; b=S1EkllR5Kf43wzO/nLY3+9m73YLSByQcFGBQxao17bmtGw280kbJIhrL+/SGHfJ+Qx w9Zdrw0fsz2LqMpRJRvKZrySgOkW1UPYW8DUJQpp30+4GR/rzup/kXP6aPJhCwtOpVtD p1eSG5erKMk8CQBpIHgcvLlAIwnpRJmHYLnIrb+SVKT2NX9W/CNdc6kBG6yHe6OG320t M902IOAmj7023nQm3G3x5vWtLFf+IpnYid5hhwDZj7SvbY2/5yY3LQa8Rnl5/xX8MHXu rKSXoNDcn/7iUhYvcoZRH6xsHMMHAN0/tUSM7Wm1HnVxNOSXLWrvEpj5t3UvgwtK9OPJ QqdA== X-Gm-Message-State: AG10YOQs1Dop9HU3cKPhHcnWVija2rSY9hutoqDV65azIZt3xZUJEIF3rUJrb1Wn3w4O2k4xyYo7Ey51tkSDUzES X-Received: by 10.182.97.2 with SMTP id dw2mr407765obb.20.1455816552122; Thu, 18 Feb 2016 09:29:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Thu, 18 Feb 2016 09:28:52 -0800 (PST) In-Reply-To: References: From: William Denniss Date: Thu, 18 Feb 2016 09:28:52 -0800 Message-ID: To: Aaron Parecki Content-Type: multipart/alternative; boundary=047d7b2e501a72ed36052c0eb43b Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Initial OAuth working group Device Flow specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:29:15 -0000 --047d7b2e501a72ed36052c0eb43b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your feedback, you make some very good points. Currently this draft was just resurrecting the previous draft and we've yet to do a pass on it yet based on our actual implementation experience. I'll make sure to address your points when we do. I agree that entering the code is NOT equivalent to granting authorization! That's not how we implemented it. On Thu, Feb 18, 2016 at 8:51 AM, Aaron Parecki wrote: > I had previously made some comments on this back in November, but never > heard any response. These were things I ran into while implementing the > device flow on one of my servers. > > https://mailarchive.ietf.org/arch/msg/oauth/JzH-isRij9kCpbEJpXVqwZ6XjjU > > https://mailarchive.ietf.org/arch/msg/oauth/XQJ4e_kgBOfn3tkTBXf6bYVNGJE > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Thu, Feb 18, 2016 at 12:34 AM, Mike Jones > wrote: > >> Thanks to William Denniss for creating the initial working group version >> of the OAuth 2.0 Device Flow specification. The abstract of the >> specification is: >> >> >> >> The device flow is suitable for OAuth 2.0 clients executing on devices >> which do not have an easy data-entry method (e.g., game consoles, TVs, >> picture frames, and media hubs), but where the end-user has separate acc= ess >> to a user-agent on another computer or device (e.g., desktop computer, a >> laptop, a smart phone, or a tablet). >> >> >> >> Note: This version of the document is a continuation of an earlier, long >> expired draft. The content of the expired draft has been copied almost >> unmodified. The goal of the work on this document is to capture deploym= ent >> experience. >> >> >> >> If you=E2=80=99re using an OAuth device flow, please let us know whether= this >> specification matches your usage, and if not, how yours differs. >> >> >> >> The specification is available at: >> >> =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-device-flow-00 >> >> >> >> An HTML-formatted version is also available at: >> >> =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-device-flow-0= 0.html >> >> >> >> -- Mike >> >> >> >> P.S. This notice was also posted at http://self-issued.info/?p=3D1546 a= nd >> as @selfissued . >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7b2e501a72ed36052c0eb43b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your feedback, you make some very good points.<= div>
Currently this draft was just resurrecting the previous = draft and we've yet to do a pass on it yet based on our actual implemen= tation experience.=C2=A0 I'll make sure to address your points when we = do.

I agree that entering the code is NOT equivale= nt to granting authorization! That's not how we implemented it.

On Thu, Feb 1= 8, 2016 at 8:51 AM, Aaron Parecki <aaron@parecki.com> wrote:=
I had previously made s= ome comments on this back in November, but never heard any response. These = were things I ran into while implementing the device flow on one of my serv= ers.


----
Aaron Parecki
aaronparecki.com


Thanks to William Denniss for creating the initial w= orking group version of the OAuth 2.0 Device Flow specification.=C2=A0 The = abstract of the specification is:

=C2=A0

The device flow is suitab= le for OAuth 2.0 clients executing on devices which do not have an easy dat= a-entry method (e.g., game consoles, TVs, picture frames, and media hubs), = but where the end-user has separate access to a user-agent on another computer or device (e.g., desktop comput= er, a laptop, a smart phone, or a tablet).

=C2=A0

Note: This version of the= document is a continuation of an earlier, long expired draft.=C2=A0 The co= ntent of the expired draft has been copied almost unmodified.=C2=A0 The goa= l of the work on this document is to capture deployment experience.

=C2=A0

If you=E2=80=99re using an OAuth device flow, please= let us know whether this specification matches your usage, and if not, how= yours differs.

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-= ietf-oauth-device-flow-00

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info/do= cs/draft-ietf-oauth-device-flow-00.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This notice was also posted at http://self-issued.info/?p=3D1546 and as @selfissued.


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



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


--047d7b2e501a72ed36052c0eb43b-- From nobody Thu Feb 18 10:13:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0991B2B0D for ; Thu, 18 Feb 2016 10:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E9ftFvDKhaF for ; Thu, 18 Feb 2016 10:13:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943D01B2E7C for ; Thu, 18 Feb 2016 10:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ki5+6LiRR6tzfdupp6COL++IM3ugKcWNCL0ZRLfiMMw=; b=HYERKRBDJ+TJlSMqwrrTbHthLxTXoegi6Ug9UYIZEqVzJOdqBGlhVZs1H4SFnR4BMWZQiWc6t6+OEhlHvZMVA32B24WEp2qUpAk0M9puMW/dUh89OeHNCIj54A3tz0uyL0JkIruYNYe079g/IUx3/fkAgqkdAfJ0vpAYyOU+naE= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 18:12:55 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 18:12:55 +0000 From: Anthony Nadalin To: Hannes Tschofenig , Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAABarKAAAcSQqA= Date: Thu, 18 Feb 2016 18:12:55 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> In-Reply-To: <56C5D96D.7000805@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::18f] x-ms-office365-filtering-correlation-id: 86074f06-9a3f-449c-7d6a-08d3388f1fff x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:CVCUPSVgpuCbndtnc37u+TakisXv3Qhrfll5MfJKwRJtPUhpb1IGCL7Z+X8PJj9FkMxi6FGPn/0Pi9ajyEo9TzKVO4B6gpKXgAOnUPCi21FGFHnWuU6pyX0qVtKLoCMdAHJP/UbXV8e9O4t+XQSY7Q==; 24:Li7c2UoTsBW9sRkawqQTOKBNz6diJAjzhCssxXPrRV/stMyQvGCijeBO1GtoaO6g8HddKhaqpVDxv9rgAWjSpDC30pCKkrAsNwaok52EKVo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(479174004)(86362001)(77096005)(86612001)(2900100001)(2950100001)(93886004)(33656002)(76576001)(5002640100001)(50986999)(54356999)(189998001)(87936001)(5001770100001)(5001960100002)(76176999)(99286002)(92566002)(5003600100002)(10090500001)(10290500002)(10400500002)(5005710100001)(74316001)(6116002)(102836003)(3660700001)(3280700002)(5008740100001)(586003)(1220700001)(1096002)(19580405001)(19580395003)(40100003)(11100500001)(122556002)(4326007)(2906002)(5004730100002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 18:12:55.4986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:13:22 -0000 I also think we are way far from last call (and surprised to see last call = issued) on this document as it is still very complex for something that sho= uld be very simple=20 -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February 18, 2016 6:47 AM To: Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence On 02/18/2016 03:06 PM, Phil Hunt wrote: > BTW. I think we are FAR from Last Call on this topic. Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior = to your message based on the claim from the authors that they believe the d= ocument is finished. We will, of course, take all reviews into account and see where we are with= the discovery spec. I, as the shepherd, will also do my review and I encou= rage many working group members to also take a look at the document and to = provide their input. Ciao Hannes From nobody Thu Feb 18 10:18:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C681B3066 for ; Thu, 18 Feb 2016 10:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXUCLJ2RNNoh for ; Thu, 18 Feb 2016 10:18:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02E91B2F55 for ; Thu, 18 Feb 2016 10:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7YsNt83eYbcuuJDVppZW5BtH+9NuObk/9JQqsryWYhY=; b=kC4AqNxwU0qJ5K0qBjDnHwF3mk64tUW1V/jiT3PmMXXPO/0JRefCl79bmDeeawMI+63BQ/lrp0Ja2dqq5K5MY+7mJgiLExQxSkyZoSxHupY7YgXLR4P9AuCy08bLWcYS1rRgEB6KSLQ+yLkCtF2zgsdKeZp/ycptz6b747NwvV8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 18:17:49 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 18:17:49 +0000 From: Mike Jones To: Anthony Nadalin , Hannes Tschofenig , Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAABarKAAAcSQqAAADTzoA== Date: Thu, 18 Feb 2016 18:17:49 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 4d3c283a-6de6-4d09-9062-08d3388fcf19 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:kpJ5AMnrs9/w8hsCKW7GkCTNI3iJlrG/3ZgbKymR4JF2I5MXFYUkE/b0zmEMVuzzW2oLbvfm8Gd0eb8HBRITJVUKvqXU7GIZ39mR8/tkSs5ylOHbCN9RSltXPtlvaG6mPRK1BYyAtb9lxABJYOpaRw==; 24:TKokq42dV8LKRRt0TNLZpNv4GV4CvGnjxJSWi2eUTBs7QOS7DqfOGxYScFncJs1NQBmHKU6HEILkGi/nawbb1wHNxYogHtgc/MGD6ZtR5FQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(479174004)(2561002)(86362001)(77096005)(86612001)(2900100001)(2950100001)(66066001)(93886004)(1511001)(15975445007)(33656002)(76576001)(5002640100001)(50986999)(54356999)(2421001)(189998001)(87936001)(5001770100001)(5001960100002)(76176999)(99286002)(92566002)(5003600100002)(10090500001)(10290500002)(10400500002)(5005710100001)(74316001)(6116002)(102836003)(3660700001)(3846002)(3280700002)(5008740100001)(586003)(1220700001)(1096002)(19580405001)(19580395003)(40100003)(11100500001)(122556002)(4326007)(2906002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 18:17:49.3222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:18:13 -0000 It's the OAuth-specific subset of what's already widely deployed. Nothing = was invented - just subsetted. I think it's already as simple as possible unless the working group decides= to remove even more functionality (which it can obviously do). -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Thursday, February 18, 2016 10:13 AM To: Hannes Tschofenig ; Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence I also think we are way far from last call (and surprised to see last call = issued) on this document as it is still very complex for something that sho= uld be very simple=20 -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February 18, 2016 6:47 AM To: Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence On 02/18/2016 03:06 PM, Phil Hunt wrote: > BTW. I think we are FAR from Last Call on this topic. Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior = to your message based on the claim from the authors that they believe the d= ocument is finished. We will, of course, take all reviews into account and see where we are with= the discovery spec. I, as the shepherd, will also do my review and I encou= rage many working group members to also take a look at the document and to = provide their input. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Feb 18 10:27:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389331A8F4A for ; Thu, 18 Feb 2016 10:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma2Ykj192ZOo for ; Thu, 18 Feb 2016 10:27:28 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0A31A8A60 for ; Thu, 18 Feb 2016 10:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=actXseVqRwuEXK/89YoZQjGYVrhhc2tBE8sZXhet3Lk=; b=YUTPULirS8JkdIqhlbgKlPRhtBv2PQmUmpYFpxhy+Mz5ptxdypRF96KG71DaFk1qgzngl6vI/jxHCNIxyvEcRvvB9BXYN0hoaE2Kf9XCSQVzIjTlORlTVkPaT2/LyPUyy8wcYGAHACfsja1cpxr9tmRWnYgmV1wJVNsFRNJzpHA= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.403.16; Thu, 18 Feb 2016 18:27:26 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 18:27:23 +0000 From: Anthony Nadalin To: Mike Jones , Hannes Tschofenig , Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAABarKAAAcSQqAAADTzoAAAPiiw Date: Thu, 18 Feb 2016 18:27:23 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::18f] x-ms-office365-filtering-correlation-id: f8973988-113a-43ae-77b0-08d33891256a x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:h8bzAglx8TG8LIiMFuX0bPfk3gYMqu+YKh0z9bOaZkgLyLuWdDQXSXYrRa3ydMglWfoJUSyitkYfI1SswwTfk8Q1m+9Hr30kkDo+7mp7Zjp8nfhr02A6zVVc3TkTBMjnmoJgTCdT3Sj0gOBofBgCrQ==; 24:ZR+ap8oTG6QB1agBkrFNQTXZc2VWeEEyuLd0BliBMP+CdiFQSzme/Qo6fGD3fbOAeuuo+iGMk+Dq5P7fM9Vn8KxPD3rwmk0d01ouYdcBGSs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(479174004)(5001770100001)(5001960100002)(3280700002)(10090500001)(5003600100002)(5002640100001)(15975445007)(1511001)(1096002)(586003)(5005710100001)(2950100001)(189998001)(6116002)(102836003)(4326007)(1220700001)(2900100001)(3660700001)(10400500002)(2906002)(3900700001)(74316001)(33656002)(5008740100001)(76576001)(93886004)(40100003)(54356999)(19580395003)(122556002)(19580405001)(86612001)(50986999)(76176999)(10290500002)(2421001)(99286002)(77096005)(92566002)(5004730100002)(86362001)(87936001)(2561002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 18:27:23.5394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:27:30 -0000 Not sure about that. There are things that are "recommended" like the dynam= ic registration endpoint, I don't understand why this is recommended as a l= ot of folks still don't do this. There are security considerations about al= l the information that is in the discovery that have not been addressed. -----Original Message----- From: Mike Jones=20 Sent: Thursday, February 18, 2016 10:18 AM To: Anthony Nadalin ; Hannes Tschofenig ; Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence It's the OAuth-specific subset of what's already widely deployed. Nothing = was invented - just subsetted. I think it's already as simple as possible unless the working group decides= to remove even more functionality (which it can obviously do). -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Thursday, February 18, 2016 10:13 AM To: Hannes Tschofenig ; Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence I also think we are way far from last call (and surprised to see last call = issued) on this document as it is still very complex for something that sho= uld be very simple=20 -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, February 18, 2016 6:47 AM To: Phil Hunt ; John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence On 02/18/2016 03:06 PM, Phil Hunt wrote: > BTW. I think we are FAR from Last Call on this topic. Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior = to your message based on the claim from the authors that they believe the d= ocument is finished. We will, of course, take all reviews into account and see where we are with= the discovery spec. I, as the shepherd, will also do my review and I encou= rage many working group members to also take a look at the document and to = provide their input. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Feb 18 10:32:59 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6961A898A for ; Thu, 18 Feb 2016 10:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPeR-1PzBnbb for ; Thu, 18 Feb 2016 10:32:56 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 010701A88BA for ; Thu, 18 Feb 2016 10:32:55 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id k196so53269615vka.0 for ; Thu, 18 Feb 2016 10:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IJFCea8Dk5tk351N1hPloKtwUh/l89ayjcfC8vCDEuE=; b=pXwdwiouDDcJiBUwoExR9IE1fIhDJIsTlpwXgjEQ5O+dGR4krsSzzYgv9nHoxnk1T0 8FuTyRY0PsBD3T6bt+sXTZjo1yt43QYGs7R8yUUlel7HL3TIajyEzHL3MiTX5dVtHrGZ /fX/2BXYjMGo7RyLbqmhor71HNvUxSWypS2QMo6D2c+NG96HWhMEieLJWPlZgviN6k4y nhGOrllOjfmF5QJ3GvDLFgo1yQGfMTkbKzycLAGbaNiKKihuJ6FsvwBcl2VZvEd7+SCu 2L7emQR9trGXXtVnoBTAfuZm0fK6C0G0/GCtVUrpONqL40tGjDLFTkaUudM/eesMgLtH dQWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IJFCea8Dk5tk351N1hPloKtwUh/l89ayjcfC8vCDEuE=; b=mFOt1iIUuP/9i7k1bigsHocEADIuxO7CCN7c51J0CY+h0urrt7Kn8qmK983ZWjFNF0 4CsYtFcYfj4g84vuxxD6U+Jqn5DxMHQbdi3/swZZ+8aEfO65FwOzgsazLZsmYUN3Hkwn D0DEJET4AIrNX9eaW38vyq/vB2zTg1QPogyaUhbK75HzIfecLt++M+kzhHxYunfZJbLu 2P8lae3CzAmkt1lmn8PTOrza0nxYXnflVSekfsTtSLAVrydVmkUeMgIgeAXNxdBAF86M 7XV8fEGJtcv0yKNzgQmlH7Aep67jhAT98C7/B3BpZ1bJezAtzViA8qWwmct3tx7lWCN6 N+zw== X-Gm-Message-State: AG10YOR9pIwU0BNBvIL+6SC+jqZqwoGr/rWCVncnVVkzYUQfusFrmHvECcp5tq0WtUMBDQ== X-Received: by 10.31.166.208 with SMTP id p199mr7469765vke.122.1455820374691; Thu, 18 Feb 2016 10:32:54 -0800 (PST) Received: from [192.168.12.59] (ip-64-134-184-168.public.wayport.net. [64.134.184.168]) by smtp.gmail.com with ESMTPSA id v19sm875645vkd.22.2016.02.18.10.32.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 10:32:54 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C28D1E9E-818B-4F4F-A800-8CA19F3153EB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 18 Feb 2016 13:32:52 -0500 Message-Id: <111B18CA-B61D-46C5-99D0-2BCF4673B0D5@ve7jtb.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> To: Anthony Nadalin X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:32:58 -0000 --Apple-Mail=_C28D1E9E-818B-4F4F-A800-8CA19F3153EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are establishing a registry. Some folks do use dynamic client = registration. =20 We can register it in this document or take it out and let others = register it once the registry is established. It will be registered one way or the other. =20 One of the reasons for starting last call is to get people to read the = draft and comment.=20 That seems to be working. If you have specific security considerations, please let us know so they = can be addressed. Text is always appreciated. John B. > On Feb 18, 2016, at 1:27 PM, Anthony Nadalin = wrote: >=20 > Not sure about that. There are things that are "recommended" like the = dynamic registration endpoint, I don't understand why this is = recommended as a lot of folks still don't do this. There are security = considerations about all the information that is in the discovery that = have not been addressed. >=20 > -----Original Message----- > From: Mike Jones=20 > Sent: Thursday, February 18, 2016 10:18 AM > To: Anthony Nadalin ; Hannes Tschofenig = ; Phil Hunt ; John = Bradley > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence >=20 > It's the OAuth-specific subset of what's already widely deployed. = Nothing was invented - just subsetted. >=20 > I think it's already as simple as possible unless the working group = decides to remove even more functionality (which it can obviously do). >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony = Nadalin > Sent: Thursday, February 18, 2016 10:13 AM > To: Hannes Tschofenig ; Phil Hunt = ; John Bradley > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence >=20 > I also think we are way far from last call (and surprised to see last = call issued) on this document as it is still very complex for something = that should be very simple=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Thursday, February 18, 2016 6:47 AM > To: Phil Hunt ; John Bradley > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence >=20 >=20 >=20 > On 02/18/2016 03:06 PM, Phil Hunt wrote: >> BTW. I think we are FAR from Last Call on this topic. >=20 > Thanks for your feedback, Phil. As you have seen I had issued a WGLC = prior to your message based on the claim from the authors that they = believe the document is finished. >=20 > We will, of course, take all reviews into account and see where we are = with the discovery spec. I, as the shepherd, will also do my review and = I encourage many working group members to also take a look at the = document and to provide their input. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C28D1E9E-818B-4F4F-A800-8CA19F3153EB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMTgxODMyNTNaMCMGCSqGSIb3DQEJBDEWBBTfzcVLBWKoUM/zAhvFQf0t CEpSHDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQArDqTK75B+HLdNju1WrsyeyfT7eBzDZFVkQLVchFR21TG6SeA9sW3l bFOBotfGz8EtWU03lKIftxz9yVssCNPVksPcHMlLj2aD4M2jy7eU2+t2Cr7JZLE/aye7RFrnT/iQ P4+qDbySPakSzAjgK1ScWEGEPjmxCZir7MDLLTKfi7q00eLR7PrXpSdcAdV0VgvwPPVrHF76XHh6 VD526FFykC4cnqYXwg/58jNsNi4W6kg3zrSKWiJntFuH5WOK0h2jhmUyQZgoo+jX5qnoDejJ9jNk lMzKTuRtMQtTBOEkNwUYfl/CAA6BMSQ1FZdkm+SaN+BffEY/6ILWM86HuxmmAAAAAAAA --Apple-Mail=_C28D1E9E-818B-4F4F-A800-8CA19F3153EB-- From nobody Thu Feb 18 10:42:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40E91AC3A7 for ; Thu, 18 Feb 2016 10:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5d-0gosqgIf for ; Thu, 18 Feb 2016 10:42:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDE11A9006 for ; Thu, 18 Feb 2016 10:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vCU6k3rqk44F3Ta1m0h6xm4bjTXyEd4EnQYX0nr+zis=; b=m+c5eN8R+d2+jZvqiDkS82vowvJIbkDuaMBkzwBTrVha2f3kulmnmdme5XIEgunLdtA7gtvWhc9+7y/oTeWXmCINBOKUbaZPY+1/RqHAf+HTyv4W5God97jfQn5REkEO09gcFVfWHhQ5I9MRFfeYTMg5CcTpn5FhLB4MShyrzvA= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by CY1PR0301MB1243.namprd03.prod.outlook.com (10.161.212.153) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 18:42:21 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 18:42:21 +0000 From: Mike Jones To: John Bradley , Anthony Nadalin Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAABarKAAAcSQqAAADTzoAAAPiiwAABcswAAACrwwA== Date: Thu, 18 Feb 2016 18:42:20 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> <111B18CA-B61D-46C5-99D0-2BCF4673B0D5@ve7jtb.com> In-Reply-To: <111B18CA-B61D-46C5-99D0-2BCF4673B0D5@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: d361ed7a-3e7c-4792-434b-08d338933c3c x-microsoft-exchange-diagnostics: 1; CY1PR0301MB1243; 5:/F/DNGOEMguMVkBPYILHMtXchnB1IrKmZr1VHQOOuj+uyQwjUCwt9luaDZ6Co8ZVWj5EHGaPCpWLogp5N+m8zcWXSR77U9STZHmPiey2mX4Den4VKeRxPowvoccjlVqFP2YoFfdmtYfye4YoU7QHSg==; 24:+Zr8CqZlDTIzfp/EpDfRTX0CMoFZSllXtbe3Gio48d0ycKZrV1KKk1kMch8BbgmQd5Wcl6nX8caNGp18u1EXAXTd8zSUlcTS937PUqhCRKY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1243; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:CY1PR0301MB1243; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB1243; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(479174004)(24454002)(19580395003)(87936001)(86362001)(11100500001)(86612001)(5008740100001)(93886004)(33656002)(3660700001)(2561002)(19580405001)(189998001)(2421001)(15975445007)(77096005)(5001960100002)(92566002)(5001770100001)(102836003)(1096002)(1220700001)(5005710100001)(99286002)(10400500002)(4326007)(6116002)(2950100001)(3900700001)(74316001)(2900100001)(54356999)(2906002)(122556002)(76176999)(50986999)(3280700002)(40100003)(3846002)(5004730100002)(66066001)(5003600100002)(586003)(5002640100001)(76576001)(10290500002)(1511001)(10090500001)(4001450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1243; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 18:42:20.8489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB1243 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:42:28 -0000 I'm fine with changing dynamic registration from being RECOMMENDED to OPTIO= NAL. That's good actionable feedback. Likewise, looking at again, we also= need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth dep= loyments need keys. I expect more good, actionable feedback to also come from the WGLC as peopl= e carefully read the draft with fresh eyes. -- Mike -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Thursday, February 18, 2016 10:33 AM To: Anthony Nadalin Cc: Mike Jones ; Hannes Tschofenig ; Phil Hunt ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence We are establishing a registry. Some folks do use dynamic client registrat= ion. =20 We can register it in this document or take it out and let others register = it once the registry is established. It will be registered one way or the other. =20 One of the reasons for starting last call is to get people to read the draf= t and comment.=20 That seems to be working. If you have specific security considerations, please let us know so they ca= n be addressed. Text is always appreciated. John B. > On Feb 18, 2016, at 1:27 PM, Anthony Nadalin wrot= e: >=20 > Not sure about that. There are things that are "recommended" like the dyn= amic registration endpoint, I don't understand why this is recommended as a= lot of folks still don't do this. There are security considerations about = all the information that is in the discovery that have not been addressed. >=20 > -----Original Message----- > From: Mike Jones=20 > Sent: Thursday, February 18, 2016 10:18 AM > To: Anthony Nadalin ; Hannes Tschofenig ; Phil Hunt ; John Bradley > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence >=20 > It's the OAuth-specific subset of what's already widely deployed. Nothin= g was invented - just subsetted. >=20 > I think it's already as simple as possible unless the working group decid= es to remove even more functionality (which it can obviously do). >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin > Sent: Thursday, February 18, 2016 10:13 AM > To: Hannes Tschofenig ; Phil Hunt ; John Bradley > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence >=20 > I also think we are way far from last call (and surprised to see last cal= l issued) on this document as it is still very complex for something that s= hould be very simple=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Thursday, February 18, 2016 6:47 AM > To: Phil Hunt ; John Bradley > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence >=20 >=20 >=20 > On 02/18/2016 03:06 PM, Phil Hunt wrote: >> BTW. I think we are FAR from Last Call on this topic. >=20 > Thanks for your feedback, Phil. As you have seen I had issued a WGLC prio= r to your message based on the claim from the authors that they believe the= document is finished. >=20 > We will, of course, take all reviews into account and see where we are wi= th the discovery spec. I, as the shepherd, will also do my review and I enc= ourage many working group members to also take a look at the document and t= o provide their input. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Feb 18 11:28:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFAE1B2F3F for ; Thu, 18 Feb 2016 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 ICkA8YIHNWSw for ; Thu, 18 Feb 2016 11:28:20 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 F07E91B3170 for ; Thu, 18 Feb 2016 11:28:16 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id kf7so1558931obb.1 for ; Thu, 18 Feb 2016 11:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZHbmFhMD0pXWm9jnk/qsXlTNL8rLZu+e7SSp/r4/KvY=; b=bt02dzO5AH2Vb5N7Sig0XJp4qG5TyHrbbVMpp7g9/5rBcMLLxGqpmWwWnDuF0o0GHC uV9nTcu+WR6xoSHPCT4ry2U6jAUQE6jSjtKi6cL7il8e+ym8DF9mf4zk1XcqEHKWKHn2 fNcVLGs6meGzdo/h1bXaEacNWZ3hk5PshWVjD8ThL9BoHP47COOAkemB2OC68q2dsEZb jCjujj6ds6xKQ0eBeHePfaZDovUCToBR7cJnFUvNxbiF/+h+/2Za/d3j+HmMyNduk2qj FihQQNjqZW9m2CsVbfhnE+ec2vyfqcGGNidcpmiIgPNTGeqhkODctxGZXX9hsEqt4uyv C0lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZHbmFhMD0pXWm9jnk/qsXlTNL8rLZu+e7SSp/r4/KvY=; b=VbaH8Oav2Ix3DDPdXBIieiJ4aHH4sCQHghkWrbm8xMzLcLTnoiMTcDWO7TMN/JmsVI elP0kopbbW1Q7ZiL/0bWiu3oYVaqgVWhyzL3yDVDZsXwcsYhZER0pNzDuflrrvjWkJ07 IkENx7oEd1EJIy2NkbGUNcqaKqUDpDrMNF+wR30e9cn9l2sc4X+A8ov7Bjr2E+dsqy1u /lhflpkbBP1jF61oiRkBmpD/doEtaewg2jbSJXC50n8Eboj6v9ZOyfr1AUnNQblBc8wZ /G2Qw/FEUZgDKDAi1Z7f4w5gHOrznMX8MuTtWHBfF8faMVBsJE4zpjBT5eFABWM9pp2f G2Ww== X-Gm-Message-State: AG10YOS2t7DSKV5RWtQzmWkF8CZOw62NChhoXCOmDHtOTNIWJC7yC5e1YJ1a4/VU1T/rFywytlkTs28SUg+77DZq X-Received: by 10.182.241.2 with SMTP id we2mr429678obc.20.1455823696274; Thu, 18 Feb 2016 11:28:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Thu, 18 Feb 2016 11:27:56 -0800 (PST) In-Reply-To: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> <111B18CA-B61D-46C5-99D0-2BCF4673B0D5@ve7jtb.com> From: William Denniss Date: Thu, 18 Feb 2016 11:27:56 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c2ec2046106b052c105eef Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:28:23 -0000 --001a11c2ec2046106b052c105eef Content-Type: text/plain; charset=UTF-8 Two review comments: 1. Can the text in "Section 2. Authorization Server Metadata" near the end regarding additional metadata be expanded? I think we should reference the IANA registry established by this spec in that section (as this will be the reference point for people looking for other registered metadata), and possibly mention something about registered vs unregistered parameters and interoperability. At present if you only read that section it is a little vague. I like the treatment of claims in the JWT spec https://tools.ietf.org/html/rfc7519#section-4.2, splitting into 3 groups: registered, public and private. Not saying we should mirror it exactly, but as an implementer I liked how clearly it was stated in that spec. 2. Since this doc is in WG Last call, do we need to remove the reference to the mix-up I-D (Section 2, "issuer"), or are we expecting them to be finalized together? On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones wrote: > I'm fine with changing dynamic registration from being RECOMMENDED to > OPTIONAL. That's good actionable feedback. Likewise, looking at again, we > also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth > deployments need keys. > > I expect more good, actionable feedback to also come from the WGLC as > people carefully read the draft with fresh eyes. > > -- Mike > > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Thursday, February 18, 2016 10:33 AM > To: Anthony Nadalin > Cc: Mike Jones ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; Phil Hunt ; > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > We are establishing a registry. Some folks do use dynamic client > registration. > > We can register it in this document or take it out and let others register > it once the registry is established. > > It will be registered one way or the other. > > One of the reasons for starting last call is to get people to read the > draft and comment. > That seems to be working. > > If you have specific security considerations, please let us know so they > can be addressed. Text is always appreciated. > > John B. > > > On Feb 18, 2016, at 1:27 PM, Anthony Nadalin > wrote: > > > > Not sure about that. There are things that are "recommended" like the > dynamic registration endpoint, I don't understand why this is recommended > as a lot of folks still don't do this. There are security considerations > about all the information that is in the discovery that have not been > addressed. > > > > -----Original Message----- > > From: Mike Jones > > Sent: Thursday, February 18, 2016 10:18 AM > > To: Anthony Nadalin ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; Phil Hunt ; John > Bradley > > Cc: oauth@ietf.org > > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > It's the OAuth-specific subset of what's already widely deployed. > Nothing was invented - just subsetted. > > > > I think it's already as simple as possible unless the working group > decides to remove even more functionality (which it can obviously do). > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin > > Sent: Thursday, February 18, 2016 10:13 AM > > To: Hannes Tschofenig ; Phil Hunt < > phil.hunt@oracle.com>; John Bradley > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > I also think we are way far from last call (and surprised to see last > call issued) on this document as it is still very complex for something > that should be very simple > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > > Sent: Thursday, February 18, 2016 6:47 AM > > To: Phil Hunt ; John Bradley > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > > > > > On 02/18/2016 03:06 PM, Phil Hunt wrote: > >> BTW. I think we are FAR from Last Call on this topic. > > > > Thanks for your feedback, Phil. As you have seen I had issued a WGLC > prior to your message based on the claim from the authors that they believe > the document is finished. > > > > We will, of course, take all reviews into account and see where we are > with the discovery spec. I, as the shepherd, will also do my review and I > encourage many working group members to also take a look at the document > and to provide their input. > > > > Ciao > > Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c2ec2046106b052c105eef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Two review comments:

1.<= /div>
Can the text in "Section 2.=C2=A0 Authorization Server Metad= ata" near the end regarding additional metadata be expanded? I think w= e should reference the IANA registry established by this spec in that secti= on (as this will be the reference point for people looking for other regist= ered metadata), and possibly mention something about registered vs unregist= ered parameters and interoperability. At present if you only read that sect= ion it is a little vague.

I like the treatment of claims in the JWT spec https://tools.ietf=
.org/html/rfc7519#section-4.2, splitting into 3 groups: registered, pub=
lic and private. Not saying we should mirror it exactly, but as an implemen=
ter I liked how clearly it was stated in that spec.

2.
=
Since this doc is in WG Last call, do we need to remove the reference = to the mix-up I-D (Section 2, "issuer"), or are we expecting them to be finalize= d together?


On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I'm fine with changing dynamic registration from being RE= COMMENDED to OPTIONAL.=C2=A0 That's good actionable feedback.=C2=A0 Lik= ewise, looking at again, we also need to change jwks_uri from REQUIRED to O= PTIONAL, since not all OAuth deployments need keys.

I expect more good, actionable feedback to also come from the WGLC as peopl= e carefully read the draft with fresh eyes.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: John Bradley [mailto:ve7jtb@ve7j= tb.com]
Sent: Thursday, February 18, 2016 10:33 AM
To: Anthony Nadalin <tonynad@mi= crosoft.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>= ; Hannes Tschofenig <hannes= .tschofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com>; oau= th@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

We are establishing a registry.=C2=A0 Some folks do use dynamic client regi= stration.

We can register it in this document or take it out and let others register = it once the registry is established.

It will be registered one way or the other.

One of the reasons for starting last call is to get people to read the draf= t and comment.
That seems to be working.

If you have specific security considerations, please let us know so they ca= n be addressed.=C2=A0 =C2=A0Text is always appreciated.

John B.

> On Feb 18, 2016, at 1:27 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>
> Not sure about that. There are things that are "recommended"= like the dynamic registration endpoint, I don't understand why this is= recommended as a lot of folks still don't do this. There are security = considerations about all the information that is in the discovery that have= not been addressed.
>
> -----Original Message-----
> From: Mike Jones
> Sent: Thursday, February 18, 2016 10:18 AM
> To: Anthony Nadalin <tonyn= ad@microsoft.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com>; John Bradley= <ve7jtb@ve7jtb.com>
> Cc: oauth@ietf.org
> Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence=
>
> It's the OAuth-specific subset of what's already widely deploy= ed.=C2=A0 Nothing was invented - just subsetted.
>
> I think it's already as simple as possible unless the working grou= p decides to remove even more functionality (which it can obviously do). >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Thursday, February 18, 2016 10:13 AM
> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com>; John Bradley <ve7jtb@ve7jtb.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence=
>
> I also think we are way far from last call (and surprised to see last = call issued) on this document as it is still very complex for something tha= t should be very simple
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Thursday, February 18, 2016 6:47 AM
> To: Phil Hunt <phil.hunt@or= acle.com>; John Bradley <ve7= jtb@ve7jtb.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence=
>
>
>
> On 02/18/2016 03:06 PM, Phil Hunt wrote:
>> BTW. I think we are FAR from Last Call on this topic.
>
> Thanks for your feedback, Phil. As you have seen I had issued a WGLC p= rior to your message based on the claim from the authors that they believe = the document is finished.
>
> We will, of course, take all reviews into account and see where we are= with the discovery spec. I, as the shepherd, will also do my review and I = encourage many working group members to also take a look at the document an= d to provide their input.
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--001a11c2ec2046106b052c105eef-- From nobody Thu Feb 18 11:36:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13B91A1A76 for ; Thu, 18 Feb 2016 11:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEyuTXM8cuQY for ; Thu, 18 Feb 2016 11:36:42 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813DB1A0370 for ; Thu, 18 Feb 2016 11:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hIPKCctkeRofvQpuOiuD3CIkUhwu5OwCkdAtdAmlU9Q=; b=cHOPQAQ4wWHzGVeWWelRFlQHhX7iTcaJxh06kbO3xV0uSGBzkLWruPYIWe86PhUH5bIS2NlFGPlf1KSxzrOg27ecIQGymLNQuyC25sOe0xJ4OutOPwlz+kdBeC3gz+VTg823fX4BHk57GkPYodwzoxq4x79r1mEbDT/TZmKgT0k= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY1PR0301MB1237.namprd03.prod.outlook.com (10.161.203.21) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 19:36:40 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 19:36:40 +0000 From: Mike Jones To: William Denniss Thread-Topic: [OAUTH-WG] OAuth Discovery spec pared down to its essence Thread-Index: AdFqFQkhCqRsHpNHQ7yss0+yEvGHSAAPDGMAAAC0dIAAAGHBgAABarKAAAcSQqAAADTzoAAAPiiwAABcswAAACrwwAABwWYAAAA+mRA= Date: Thu, 18 Feb 2016 19:36:40 +0000 Message-ID: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> <111B18CA-B61D-46C5-99D0-2BCF4673B0D5@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 5db11465-6b05-441e-9950-08d3389ad31c x-microsoft-exchange-diagnostics: 1; BY1PR0301MB1237; 5:6WvRZuN69BRs3uWUBrtbvHAkzeGRNiiKEnVah5ppJxiEPJIUJ+jao03PGdHxxhWB51qhn7XUcb2vcb1k4QXde/Smuqm1kKeVEyRg21tJ4ztnXnTFo18EqxU7BicXt3VaMENZCLXp+/AyoA7IG2FcJw==; 24:RqPZ8pDKy59h+a8iaifr8AMFDgjybMU7Loe4xcjGFiO7Lrc0fEDHoz+8B3LqigVDEE/4JJyGw2WOHjfyGj/9GW/DsCc5U/ypzCqdEosRxUY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1237; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY1PR0301MB1237; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1237; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(24454002)(57704003)(479174004)(377454003)(13464003)(6116002)(5004730100002)(86612001)(93886004)(5005710100001)(87936001)(66066001)(3846002)(102836003)(86362001)(19300405004)(16236675004)(790700001)(5001960100002)(19617315012)(10400500002)(10290500002)(74316001)(586003)(5008740100001)(19580405001)(77096005)(19625215002)(15975445007)(2906002)(40100003)(19580395003)(3660700001)(3900700001)(76576001)(33656002)(3280700002)(5003600100002)(10090500001)(4326007)(2950100001)(50986999)(110136002)(11100500001)(76176999)(1220700001)(1096002)(5002640100001)(99286002)(189998001)(92566002)(54356999)(122556002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1237; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A29EEEFDF8951EF7A8C5F5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 19:36:40.5013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB1237 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:36:51 -0000 --_000_BY2PR03MB442A29EEEFDF8951EF7A8C5F5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBXaWxsaWFtLiAgSeKAmW0gZ29vZCB3aXRoIHJlZmVyZW5jaW5nIHRoZSByZWdpc3Ry eSBpbiBTZWN0aW9uIDIuICBJ4oCZbGwgdGhpbmsgYWJvdXQgdGhlIHJlZ2lzdGVyZWQvcHVibGlj L3ByaXZhdGUgY29tbWVudC4NCg0KSXTigJlzIGZpbmUgdG8gcmVmZXJlbmNlIG9hdXRoLW1peC11 cC1taXRpZ2F0aW9uIGFzIGEgZHJhZnQgaW4gYSBmaW5pc2hlZCBSRkMgYXMgbG9uZyBhcyBpdOKA mXMgYW4gaW5mb3JtYXRpdmUgYW5kIG5vdCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb21d DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgMTE6MjggQU0NClRvOiBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzogSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbT47IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPjsg b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIERpc2NvdmVyeSBz cGVjIHBhcmVkIGRvd24gdG8gaXRzIGVzc2VuY2UNCg0KVHdvIHJldmlldyBjb21tZW50czoNCg0K MS4NCkNhbiB0aGUgdGV4dCBpbiAiU2VjdGlvbiAyLiAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0 YWRhdGEiIG5lYXIgdGhlIGVuZCByZWdhcmRpbmcgYWRkaXRpb25hbCBtZXRhZGF0YSBiZSBleHBh bmRlZD8gSSB0aGluayB3ZSBzaG91bGQgcmVmZXJlbmNlIHRoZSBJQU5BIHJlZ2lzdHJ5IGVzdGFi bGlzaGVkIGJ5IHRoaXMgc3BlYyBpbiB0aGF0IHNlY3Rpb24gKGFzIHRoaXMgd2lsbCBiZSB0aGUg cmVmZXJlbmNlIHBvaW50IGZvciBwZW9wbGUgbG9va2luZyBmb3Igb3RoZXIgcmVnaXN0ZXJlZCBt ZXRhZGF0YSksIGFuZCBwb3NzaWJseSBtZW50aW9uIHNvbWV0aGluZyBhYm91dCByZWdpc3RlcmVk IHZzIHVucmVnaXN0ZXJlZCBwYXJhbWV0ZXJzIGFuZCBpbnRlcm9wZXJhYmlsaXR5LiBBdCBwcmVz ZW50IGlmIHlvdSBvbmx5IHJlYWQgdGhhdCBzZWN0aW9uIGl0IGlzIGEgbGl0dGxlIHZhZ3VlLg0K DQoNCkkgbGlrZSB0aGUgdHJlYXRtZW50IG9mIGNsYWltcyBpbiB0aGUgSldUIHNwZWMgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjIsIHNwbGl0dGluZyBpbnRv IDMgZ3JvdXBzOiByZWdpc3RlcmVkLCBwdWJsaWMgYW5kIHByaXZhdGUuIE5vdCBzYXlpbmcgd2Ug c2hvdWxkIG1pcnJvciBpdCBleGFjdGx5LCBidXQgYXMgYW4gaW1wbGVtZW50ZXIgSSBsaWtlZCBo b3cgY2xlYXJseSBpdCB3YXMgc3RhdGVkIGluIHRoYXQgc3BlYy4NCg0KDQoyLg0KU2luY2UgdGhp cyBkb2MgaXMgaW4gV0cgTGFzdCBjYWxsLCBkbyB3ZSBuZWVkIHRvIHJlbW92ZSB0aGUgcmVmZXJl bmNlIHRvIHRoZSBtaXgtdXAgSS1EIChTZWN0aW9uIDIsICJpc3N1ZXIiKSwgb3IgYXJlIHdlIGV4 cGVjdGluZyB0aGVtIHRvIGJlIGZpbmFsaXplZCB0b2dldGhlcj8NCg0KDQpPbiBUaHUsIEZlYiAx OCwgMjAxNiBhdCAxMDo0MiBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkknbSBmaW5l IHdpdGggY2hhbmdpbmcgZHluYW1pYyByZWdpc3RyYXRpb24gZnJvbSBiZWluZyBSRUNPTU1FTkRF RCB0byBPUFRJT05BTC4gIFRoYXQncyBnb29kIGFjdGlvbmFibGUgZmVlZGJhY2suICBMaWtld2lz ZSwgbG9va2luZyBhdCBhZ2Fpbiwgd2UgYWxzbyBuZWVkIHRvIGNoYW5nZSBqd2tzX3VyaSBmcm9t IFJFUVVJUkVEIHRvIE9QVElPTkFMLCBzaW5jZSBub3QgYWxsIE9BdXRoIGRlcGxveW1lbnRzIG5l ZWQga2V5cy4NCg0KSSBleHBlY3QgbW9yZSBnb29kLCBhY3Rpb25hYmxlIGZlZWRiYWNrIHRvIGFs c28gY29tZSBmcm9tIHRoZSBXR0xDIGFzIHBlb3BsZSBjYXJlZnVsbHkgcmVhZCB0aGUgZHJhZnQg d2l0aCBmcmVzaCBleWVzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaG4gQnJhZGxleSBbbWFp bHRvOnZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT5dDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgMTA6MzMgQU0NClRvOiBBbnRob255IE5hZGFsaW4g PHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkNj OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+OyBQaGlsIEh1bnQg PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+OyBvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBPQXV0aCBEaXNjb3Zlcnkgc3BlYyBwYXJlZCBkb3duIHRvIGl0cyBlc3NlbmNlDQoNCldlIGFy ZSBlc3RhYmxpc2hpbmcgYSByZWdpc3RyeS4gIFNvbWUgZm9sa3MgZG8gdXNlIGR5bmFtaWMgY2xp ZW50IHJlZ2lzdHJhdGlvbi4NCg0KV2UgY2FuIHJlZ2lzdGVyIGl0IGluIHRoaXMgZG9jdW1lbnQg b3IgdGFrZSBpdCBvdXQgYW5kIGxldCBvdGhlcnMgcmVnaXN0ZXIgaXQgb25jZSB0aGUgcmVnaXN0 cnkgaXMgZXN0YWJsaXNoZWQuDQoNCkl0IHdpbGwgYmUgcmVnaXN0ZXJlZCBvbmUgd2F5IG9yIHRo ZSBvdGhlci4NCg0KT25lIG9mIHRoZSByZWFzb25zIGZvciBzdGFydGluZyBsYXN0IGNhbGwgaXMg dG8gZ2V0IHBlb3BsZSB0byByZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC4NClRoYXQgc2VlbXMg dG8gYmUgd29ya2luZy4NCg0KSWYgeW91IGhhdmUgc3BlY2lmaWMgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMsIHBsZWFzZSBsZXQgdXMga25vdyBzbyB0aGV5IGNhbiBiZSBhZGRyZXNzZWQuICAgVGV4 dCBpcyBhbHdheXMgYXBwcmVjaWF0ZWQuDQoNCkpvaG4gQi4NCg0KPiBPbiBGZWIgMTgsIDIwMTYs IGF0IDE6MjcgUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0 bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4NCj4gTm90IHN1cmUgYWJvdXQgdGhh dC4gVGhlcmUgYXJlIHRoaW5ncyB0aGF0IGFyZSAicmVjb21tZW5kZWQiIGxpa2UgdGhlIGR5bmFt aWMgcmVnaXN0cmF0aW9uIGVuZHBvaW50LCBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMgaXMg cmVjb21tZW5kZWQgYXMgYSBsb3Qgb2YgZm9sa3Mgc3RpbGwgZG9uJ3QgZG8gdGhpcy4gVGhlcmUg YXJlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFib3V0IGFsbCB0aGUgaW5mb3JtYXRpb24gdGhh dCBpcyBpbiB0aGUgZGlzY292ZXJ5IHRoYXQgaGF2ZSBub3QgYmVlbiBhZGRyZXNzZWQuDQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pa2UgSm9uZXMNCj4gU2VudDog VGh1cnNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDEwOjE4IEFNDQo+IFRvOiBBbnRob255IE5hZGFs aW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj47 IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj47IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208 bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0 Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCj4gQ2M6IG9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGggRGlz Y292ZXJ5IHNwZWMgcGFyZWQgZG93biB0byBpdHMgZXNzZW5jZQ0KPg0KPiBJdCdzIHRoZSBPQXV0 aC1zcGVjaWZpYyBzdWJzZXQgb2Ygd2hhdCdzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLiAgTm90 aGluZyB3YXMgaW52ZW50ZWQgLSBqdXN0IHN1YnNldHRlZC4NCj4NCj4gSSB0aGluayBpdCdzIGFs cmVhZHkgYXMgc2ltcGxlIGFzIHBvc3NpYmxlIHVubGVzcyB0aGUgd29ya2luZyBncm91cCBkZWNp ZGVzIHRvIHJlbW92ZSBldmVuIG1vcmUgZnVuY3Rpb25hbGl0eSAod2hpY2ggaXQgY2FuIG9idmlv dXNseSBkbykuDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4N Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVo YWxmIE9mIEFudGhvbnkgTmFkYWxpbg0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIw MTYgMTA6MTMgQU0NCj4gVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0Bn bXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj47IFBoaWwgSHVudCA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IEpvaG4gQnJh ZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCj4gQ2M6 IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtP QVVUSC1XR10gT0F1dGggRGlzY292ZXJ5IHNwZWMgcGFyZWQgZG93biB0byBpdHMgZXNzZW5jZQ0K Pg0KPiBJIGFsc28gdGhpbmsgd2UgYXJlIHdheSBmYXIgZnJvbSBsYXN0IGNhbGwgKGFuZCBzdXJw cmlzZWQgdG8gc2VlIGxhc3QgY2FsbCBpc3N1ZWQpIG9uIHRoaXMgZG9jdW1lbnQgYXMgaXQgaXMg c3RpbGwgdmVyeSBjb21wbGV4IGZvciBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgdmVyeSBzaW1w bGUNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAxOCwgMjAxNiA2OjQ3IEFNDQo+IFRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+OyBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdq dGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQo+IENjOiBvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIERp c2NvdmVyeSBzcGVjIHBhcmVkIGRvd24gdG8gaXRzIGVzc2VuY2UNCj4NCj4NCj4NCj4gT24gMDIv MTgvMjAxNiAwMzowNiBQTSwgUGhpbCBIdW50IHdyb3RlOg0KPj4gQlRXLiBJIHRoaW5rIHdlIGFy ZSBGQVIgZnJvbSBMYXN0IENhbGwgb24gdGhpcyB0b3BpYy4NCj4NCj4gVGhhbmtzIGZvciB5b3Vy IGZlZWRiYWNrLCBQaGlsLiBBcyB5b3UgaGF2ZSBzZWVuIEkgaGFkIGlzc3VlZCBhIFdHTEMgcHJp b3IgdG8geW91ciBtZXNzYWdlIGJhc2VkIG9uIHRoZSBjbGFpbSBmcm9tIHRoZSBhdXRob3JzIHRo YXQgdGhleSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBmaW5pc2hlZC4NCj4NCj4gV2Ugd2lsbCwg b2YgY291cnNlLCB0YWtlIGFsbCByZXZpZXdzIGludG8gYWNjb3VudCBhbmQgc2VlIHdoZXJlIHdl IGFyZSB3aXRoIHRoZSBkaXNjb3Zlcnkgc3BlYy4gSSwgYXMgdGhlIHNoZXBoZXJkLCB3aWxsIGFs c28gZG8gbXkgcmV2aWV3IGFuZCBJIGVuY291cmFnZSBtYW55IHdvcmtpbmcgZ3JvdXAgbWVtYmVy cyB0byBhbHNvIHRha2UgYSBsb29rIGF0IHRoZSBkb2N1bWVudCBhbmQgdG8gcHJvdmlkZSB0aGVp ciBpbnB1dC4NCj4NCj4gQ2lhbw0KPiBIYW5uZXMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg== --_000_BY2PR03MB442A29EEEFDF8951EF7A8C5F5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLmltDQoJe21zby1zdHlsZS1uYW1lOmltO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzLCBXaWxsaWFt LiZuYnNwOyBJ4oCZbSBnb29kIHdpdGggcmVmZXJlbmNpbmcgdGhlIHJlZ2lzdHJ5IGluIFNlY3Rp b24gMi4mbmJzcDsgSeKAmWxsIHRoaW5rIGFib3V0IHRoZSByZWdpc3RlcmVkL3B1YmxpYy9wcml2 YXRlIGNvbW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J dOKAmXMgZmluZSB0byByZWZlcmVuY2Ugb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24gYXMgYSBkcmFm dCBpbiBhIGZpbmlzaGVkIFJGQyBhcyBsb25nIGFzIGl04oCZcyBhbiBpbmZvcm1hdGl2ZSBhbmQg bm90IGEgbm9ybWF0aXZlIHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBX aWxsaWFtIERlbm5pc3MgW21haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxOCwgMjAxNiAxMToyOCBBTTxicj4NCjxiPlRvOjwv Yj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs7IEFudGhvbnkg TmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0Ozsgb2F1dGhAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5IHNwZWMgcGFy ZWQgZG93biB0byBpdHMgZXNzZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ud28gcmV2aWV3IGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHRoZSB0ZXh0IGluICZxdW90O1NlY3Rpb24g Mi4mbmJzcDsgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGEmcXVvdDsgbmVhciB0aGUgZW5k IHJlZ2FyZGluZyBhZGRpdGlvbmFsIG1ldGFkYXRhIGJlIGV4cGFuZGVkPyBJIHRoaW5rIHdlIHNo b3VsZCByZWZlcmVuY2UgdGhlIElBTkEgcmVnaXN0cnkgZXN0YWJsaXNoZWQgYnkgdGhpcyBzcGVj IGluIHRoYXQgc2VjdGlvbiAoYXMgdGhpcyB3aWxsIGJlIHRoZSByZWZlcmVuY2UgcG9pbnQNCiBm b3IgcGVvcGxlIGxvb2tpbmcgZm9yIG90aGVyIHJlZ2lzdGVyZWQgbWV0YWRhdGEpLCBhbmQgcG9z c2libHkgbWVudGlvbiBzb21ldGhpbmcgYWJvdXQgcmVnaXN0ZXJlZCB2cyB1bnJlZ2lzdGVyZWQg cGFyYW1ldGVycyBhbmQgaW50ZXJvcGVyYWJpbGl0eS4gQXQgcHJlc2VudCBpZiB5b3Ugb25seSBy ZWFkIHRoYXQgc2VjdGlvbiBpdCBpcyBhIGxpdHRsZSB2YWd1ZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5J IGxpa2UgdGhlIHRyZWF0bWVudCBvZiBjbGFpbXMgaW4gdGhlIEpXVCBzcGVjIDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE5I3NlY3Rpb24tNC4yIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMjwvYT4sIHNwbGl0dGluZyBpbnRv IDMgZ3JvdXBzOiByZWdpc3RlcmVkLCBwdWJsaWMgYW5kIHByaXZhdGUuIE5vdCBzYXlpbmcgd2Ug c2hvdWxkIG1pcnJvciBpdCBleGFjdGx5LCBidXQgYXMgYW4gaW1wbGVtZW50ZXIgSSBsaWtlZCBo b3cgY2xlYXJseSBpdCB3YXMgc3RhdGVkIGluIHRoYXQgc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIHRoaXMgZG9jIGlz IGluIFdHIExhc3QgY2FsbCwgZG8gd2UgbmVlZCB0byByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byB0 aGUgbWl4LXVwIEktRCAoU2VjdGlvbiAyLCAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+aXNzdWVyJnF1b3Q7KTwvc3Bhbj4sIG9yIGFyZSB3ZSBleHBlY3Rp bmcgdGhlbSB0byBiZSBmaW5hbGl6ZWQgdG9nZXRoZXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMTgsIDIwMTYgYXQg MTA6NDIgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ20gZmluZSB3aXRoIGNoYW5naW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGZyb20g YmVpbmcgUkVDT01NRU5ERUQgdG8gT1BUSU9OQUwuJm5ic3A7IFRoYXQncyBnb29kIGFjdGlvbmFi bGUgZmVlZGJhY2suJm5ic3A7IExpa2V3aXNlLCBsb29raW5nIGF0IGFnYWluLCB3ZSBhbHNvIG5l ZWQgdG8gY2hhbmdlIGp3a3NfdXJpIGZyb20gUkVRVUlSRUQgdG8gT1BUSU9OQUwsIHNpbmNlIG5v dCBhbGwgT0F1dGggZGVwbG95bWVudHMgbmVlZA0KIGtleXMuPGJyPg0KPGJyPg0KSSBleHBlY3Qg bW9yZSBnb29kLCBhY3Rpb25hYmxlIGZlZWRiYWNrIHRvIGFsc28gY29tZSBmcm9tIHRoZSBXR0xD IGFzIHBlb3BsZSBjYXJlZnVsbHkgcmVhZCB0aGUgZHJhZnQgd2l0aCBmcmVzaCBleWVzLjxicj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0g TWlrZTwvc3Bhbj48YnI+DQo8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkZyb206IEpvaG4g QnJhZGxleSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRi QHZlN2p0Yi5jb208L2E+XTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPlNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAxOCwgMjAxNiAxMDozMyBBTTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i aW0iPlRvOiBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jv c29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYzogTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVm PSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVuaWdAZ214 Lm5ldDwvYT4mZ3Q7OyBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gT0F1dGggRGlzY292ZXJ5IHNwZWMgcGFyZWQgZG93biB0byBpdHMgZXNzZW5jZTxicj4N Cjxicj4NCldlIGFyZSBlc3RhYmxpc2hpbmcgYSByZWdpc3RyeS4mbmJzcDsgU29tZSBmb2xrcyBk byB1c2UgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uLjxicj4NCjxicj4NCldlIGNhbiByZWdp c3RlciBpdCBpbiB0aGlzIGRvY3VtZW50IG9yIHRha2UgaXQgb3V0IGFuZCBsZXQgb3RoZXJzIHJl Z2lzdGVyIGl0IG9uY2UgdGhlIHJlZ2lzdHJ5IGlzIGVzdGFibGlzaGVkLjxicj4NCjxicj4NCkl0 IHdpbGwgYmUgcmVnaXN0ZXJlZCBvbmUgd2F5IG9yIHRoZSBvdGhlci48YnI+DQo8YnI+DQpPbmUg b2YgdGhlIHJlYXNvbnMgZm9yIHN0YXJ0aW5nIGxhc3QgY2FsbCBpcyB0byBnZXQgcGVvcGxlIHRv IHJlYWQgdGhlIGRyYWZ0IGFuZCBjb21tZW50Ljxicj4NClRoYXQgc2VlbXMgdG8gYmUgd29ya2lu Zy48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSBzcGVjaWZpYyBzZWN1cml0eSBjb25zaWRlcmF0aW9u cywgcGxlYXNlIGxldCB1cyBrbm93IHNvIHRoZXkgY2FuIGJlIGFkZHJlc3NlZC4mbmJzcDsgJm5i c3A7VGV4dCBpcyBhbHdheXMgYXBwcmVjaWF0ZWQuPGJyPg0KPGJyPg0KSm9obiBCLjxicj4NCjxi cj4NCiZndDsgT24gRmViIDE4LCAyMDE2LCBhdCAxOjI3IFBNLCBBbnRob255IE5hZGFsaW4gJmx0 OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IE5vdCBzdXJlIGFib3V0IHRo YXQuIFRoZXJlIGFyZSB0aGluZ3MgdGhhdCBhcmUgJnF1b3Q7cmVjb21tZW5kZWQmcXVvdDsgbGlr ZSB0aGUgZHluYW1pYyByZWdpc3RyYXRpb24gZW5kcG9pbnQsIEkgZG9uJ3QgdW5kZXJzdGFuZCB3 aHkgdGhpcyBpcyByZWNvbW1lbmRlZCBhcyBhIGxvdCBvZiBmb2xrcyBzdGlsbCBkb24ndCBkbyB0 aGlzLiBUaGVyZSBhcmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYWJvdXQgYWxsIHRoZSBpbmZv cm1hdGlvbiB0aGF0IGlzIGluIHRoZQ0KIGRpc2NvdmVyeSB0aGF0IGhhdmUgbm90IGJlZW4gYWRk cmVzc2VkLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyBGcm9tOiBNaWtlIEpvbmVzPGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwgRmVicnVh cnkgMTgsIDIwMTYgMTA6MTggQU08YnI+DQomZ3Q7IFRvOiBBbnRob255IE5hZGFsaW4gJmx0Ozxh IGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7OyBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OzsgUGhp bCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9hPiZndDs7DQogSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86 dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQomZ3Q7IENj OiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4N CiZndDsgU3ViamVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5IHNwZWMgcGFyZWQg ZG93biB0byBpdHMgZXNzZW5jZTxicj4NCiZndDs8YnI+DQomZ3Q7IEl0J3MgdGhlIE9BdXRoLXNw ZWNpZmljIHN1YnNldCBvZiB3aGF0J3MgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuJm5ic3A7IE5v dGhpbmcgd2FzIGludmVudGVkIC0ganVzdCBzdWJzZXR0ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsg SSB0aGluayBpdCdzIGFscmVhZHkgYXMgc2ltcGxlIGFzIHBvc3NpYmxlIHVubGVzcyB0aGUgd29y a2luZyBncm91cCBkZWNpZGVzIHRvIHJlbW92ZSBldmVuIG1vcmUgZnVuY3Rpb25hbGl0eSAod2hp Y2ggaXQgY2FuIG9idmlvdXNseSBkbykuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSBNaWtlPGJyPg0KJmd0 Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IE9B dXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQW50aG9ueSBOYWRhbGluPGJyPg0K Jmd0OyBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTgsIDIwMTYgMTA6MTMgQU08YnI+DQomZ3Q7 IFRvOiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2Zl bmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OzsgUGhpbCBIdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFj bGUuY29tPC9hPiZndDs7IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogPGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIERpc2NvdmVyeSBzcGVjIHBhcmVkIGRvd24gdG8g aXRzIGVzc2VuY2U8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFsc28gdGhpbmsgd2UgYXJlIHdheSBm YXIgZnJvbSBsYXN0IGNhbGwgKGFuZCBzdXJwcmlzZWQgdG8gc2VlIGxhc3QgY2FsbCBpc3N1ZWQp IG9uIHRoaXMgZG9jdW1lbnQgYXMgaXQgaXMgc3RpbGwgdmVyeSBjb21wbGV4IGZvciBzb21ldGhp bmcgdGhhdCBzaG91bGQgYmUgdmVyeSBzaW1wbGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogT0F1dGggW21haWx0bzo8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv YT5dIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCiZndDsgU2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDY6NDcgQU08YnI+DQomZ3Q7IFRvOiBQaGlsIEh1bnQgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+Jmd0OzsgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0 Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVj dDogUmU6IFtPQVVUSC1XR10gT0F1dGggRGlzY292ZXJ5IHNwZWMgcGFyZWQgZG93biB0byBpdHMg ZXNzZW5jZTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMDIvMTgv MjAxNiAwMzowNiBQTSwgUGhpbCBIdW50IHdyb3RlOjxicj4NCiZndDsmZ3Q7IEJUVy4gSSB0aGlu ayB3ZSBhcmUgRkFSIGZyb20gTGFzdCBDYWxsIG9uIHRoaXMgdG9waWMuPGJyPg0KJmd0Ozxicj4N CiZndDsgVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLCBQaGlsLiBBcyB5b3UgaGF2ZSBzZWVuIEkg aGFkIGlzc3VlZCBhIFdHTEMgcHJpb3IgdG8geW91ciBtZXNzYWdlIGJhc2VkIG9uIHRoZSBjbGFp bSBmcm9tIHRoZSBhdXRob3JzIHRoYXQgdGhleSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBmaW5p c2hlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSB3aWxsLCBvZiBjb3Vyc2UsIHRha2UgYWxsIHJl dmlld3MgaW50byBhY2NvdW50IGFuZCBzZWUgd2hlcmUgd2UgYXJlIHdpdGggdGhlIGRpc2NvdmVy eSBzcGVjLiBJLCBhcyB0aGUgc2hlcGhlcmQsIHdpbGwgYWxzbyBkbyBteSByZXZpZXcgYW5kIEkg ZW5jb3VyYWdlIG1hbnkgd29ya2luZyBncm91cCBtZW1iZXJzIHRvIGFsc28gdGFrZSBhIGxvb2sg YXQgdGhlIGRvY3VtZW50IGFuZCB0byBwcm92aWRlIHRoZWlyIGlucHV0Ljxicj4NCiZndDs8YnI+ DQomZ3Q7IENpYW88YnI+DQomZ3Q7IEhhbm5lczxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442A29EEEFDF8951EF7A8C5F5AF0BY2PR03MB442namprd_-- From nobody Thu Feb 18 11:40:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049371B335D for ; Thu, 18 Feb 2016 11:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 mQi2WPEvXsMy for ; Thu, 18 Feb 2016 11:40:28 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 547931B3106 for ; Thu, 18 Feb 2016 11:40:13 -0800 (PST) Received: by mail-ob0-x22a.google.com with SMTP id jq7so83231898obb.0 for ; Thu, 18 Feb 2016 11:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dsulkYimh9owiZcVAdg1kydjHZmVrlDNf0ve4sLBXes=; b=nyjgC4ppAqhRPBWvq7ypp1/+AgrBV7bSHMgnJDQ4p7QMQqEbhoxjapW8VMq3t6ME5M LQsY+C9gQLr8acNew0A/wf7Ew0tj/ASpIKSxOrPA0Nc7OGRKW8ty66jAlPhcgfzFEr35 nJQYfiHx5G10v2tUXuLtkk/auuYR8oDs3t9mS/3eeSUjOJDC+AjVCwMMN2B0sC50tfvR 8iq+8eB0/OrQ7Ic49ZvDD6Oh8D+3uA/2LOMbSNB3M0HmIckRuKT+DupUlyXyJUrmt215 X/wFjsCOXERAiED9BhkFSgG/+Thx67hEAEZ/HlCbazBLXH1BEmEp6hVnTB/iNerON5BN +GjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dsulkYimh9owiZcVAdg1kydjHZmVrlDNf0ve4sLBXes=; b=OZwLMwXbUfgNOa5G2xO9Jdjx2TX3GTCH2R3lCiGEALxbXz+vD8e/nM1Pdpvo2gA+yr X8gKt/3bS1MBf8twTRRm9ZPP9bW+KSoehhW81osmeC4cD42wE185AD5LRP/13n9b+47A 9QrDFJH+gaWkNZpv9g/shoScF0JISMoMACHDRV8ZeRbzfimEI8hYkQD1DKrBHRfOPh0E aRNuJ2WHx4warnmuk50LPQfk7zaQu0yMy658woZ2PIA2zwoSeTMBM0RBOl/jiqsQIwHI ZUbpZ9X/vyOUU3IB5XYXSDPHH1GOYE/zw1+FY2KwTKGTvmk7qD5lmUdI8v6kZyAVVMoY 8H6g== X-Gm-Message-State: AG10YORn9FVMKjis1pZemM4Ay0BaujjbjDMyzFZZ9uX1RpfXhiWmzSniKdSLrIuo2kaGmh4EH3Smv38aQbj2K+AK X-Received: by 10.202.87.208 with SMTP id l199mr7623909oib.97.1455824412250; Thu, 18 Feb 2016 11:40:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Thu, 18 Feb 2016 11:39:52 -0800 (PST) In-Reply-To: <56C5C273.30406@gmx.net> References: <56C5C273.30406@gmx.net> From: William Denniss Date: Thu, 18 Feb 2016 11:39:52 -0800 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113de9b8f2dfd3052c1088c9 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:40:34 -0000 --001a113de9b8f2dfd3052c1088c9 Content-Type: text/plain; charset=UTF-8 +1 to adopt. My previous concerns of this draft have been addressed, and I am supportive of having an IANA registry of amr values. On Thu, Feb 18, 2016 at 5:09 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > In response to my message to the list regarding the initial call for > adoption of the Authentication Method Reference Values draft, see > https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike > submitted an updated version of the document to take raised concerns > into account. Several working group participants responded positively to > the new version. > > We would therefore like to issue a 2nd call for adoption of the recently > submitted version -05: > https://tools.ietf.org/html/draft-jones-oauth-amr-values-05 > > Please let us know by March 3rd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113de9b8f2dfd3052c1088c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to adopt.

My previous concerns of th= is draft have been addressed, and I am supportive of having an IANA registr= y of amr values.

On Thu, Feb 18, 2016 at 5:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
In response to my message to the list regarding the initial call = for
adoption of the Authentication Method Reference Values draft, see
https://www.ietf.org/mail-archive/w= eb/oauth/current/msg15694.html, Mike
submitted an updated version of the document to take raised concerns
into account. Several working group participants responded positively to the new version.

We would therefore like to issue a 2nd call for adoption of the recently submitted version -05:
https://tools.ietf.org/html/draft-jones-o= auth-amr-values-05

Please let us know by March 3rd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek


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


--001a113de9b8f2dfd3052c1088c9-- From nobody Thu Feb 18 11:43:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A832E1B2FAF for ; Thu, 18 Feb 2016 11:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 7E02ykv_TXDN for ; Thu, 18 Feb 2016 11:43:17 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 192481B2EA5 for ; Thu, 18 Feb 2016 11:43:17 -0800 (PST) Received: by mail-ob0-x22a.google.com with SMTP id xk3so84771055obc.2 for ; Thu, 18 Feb 2016 11:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F2q+EMSu9VvuQgEWFEhpWygd5MTu74GgY8rwSTN57vY=; b=IXssV/1fj/3OVzBVoE+BKTQyFEsDSC9ueWfH4Tz6M4AtoovdU3zYvCVrJFO6xB1PSs nl8FOMgBPfSwn/nHexRfqq56usENasdfgOOBk/Wme4LeSigps8AtQKKuXl8XTiwLokAj XmOfcQeV6C1RMm4tfHvBxWT+nY7vdIKFPq8zJvIpqk7U9LOrt9K2Ili+Ilp6egai3s79 JtKc4ZkfvK3kdKOTX++EA+Wm6cP21/huJJHA+47qdUIShj/Ht7flPyDTFDTXtK8yXRjC s+EjgbqeCTCnUCEV847dOP+GAGlAs/ccAfFxVymOZA5+lchdghM6EilvXnMg9yJwYx+v FJng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F2q+EMSu9VvuQgEWFEhpWygd5MTu74GgY8rwSTN57vY=; b=fapIO88txvoai9qqV+l8JTO7DktADKatUKqH2FBMR5Bo+asxfpH9KTfWraFIuW0Bdd yROyCkW+vmQjW2lQK7uMfLzkc7kGnYt0HFnaazI1a22rOn6OTHarPoGpLWPj3arku8pf ITNHlOv0NIUpmGonKRkFPuxAM7Rux/oGAu6czKfo3AhDFs/IhYRQ9kHoBUhA896DCBr8 2CWclRBkKLTivMKAMTrE7IiR/vbLAjeYemAeUwY4UtMHXAdegDPOGCzL4rtQrFC6ZT4H BF9UQM8f0a2Bq/pbt7pZKoJLA4V14w4IOmQQ6L1e1zXDKI0pseoNwjq2+qGFUl29DF93 k6vg== X-Gm-Message-State: AG10YOT95XblLG/RvNXI3HldODFUhsPmg14Xw8IugZw9HubCDK3Y8y4gsJOody3LUJluFYpxHI2BaGV8Kw8Wv0Ut X-Received: by 10.202.51.195 with SMTP id z186mr7037044oiz.12.1455824596339; Thu, 18 Feb 2016 11:43:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Thu, 18 Feb 2016 11:42:56 -0800 (PST) In-Reply-To: References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <56C5D96D.7000805@gmx.net> <111B18CA-B61D-46C5-99D0-2BCF4673B0D5@ve7jtb.com> From: William Denniss Date: Thu, 18 Feb 2016 11:42:56 -0800 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113ce568ebb8b1052c1093ea Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:43:19 -0000 --001a113ce568ebb8b1052c1093ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2016 at 11:36 AM, Mike Jones wrote: > Thanks, William. I=E2=80=99m good with referencing the registry in Secti= on 2. > Great! > I=E2=80=99ll think about the registered/public/private comment. > > I'm not suggesting we necessarily have to use the same registered/public/private structure, only that some discussion of standardized vs non-standard could be helpful for implementers (e.g. try to pick something that is collision resistant for proprietary metadata). > It=E2=80=99s fine to reference oauth-mix-up-mitigation as a draft in a fi= nished > RFC as long as it=E2=80=99s an informative and not a normative reference. > Ah ok, I wasn't aware of that. > *From:* William Denniss [mailto:wdenniss@google.com] > > *Sent:* Thursday, February 18, 2016 11:28 AM > *To:* Mike Jones > *Cc:* John Bradley ; Anthony Nadalin < > tonynad@microsoft.com>; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > Two review comments: > > > > 1. > > Can the text in "Section 2. Authorization Server Metadata" near the end > regarding additional metadata be expanded? I think we should reference th= e > IANA registry established by this spec in that section (as this will be t= he > reference point for people looking for other registered metadata), and > possibly mention something about registered vs unregistered parameters an= d > interoperability. At present if you only read that section it is a little > vague. > > > > I like the treatment of claims in the JWT spec https://tools.ietf.org/htm= l/rfc7519#section-4.2, splitting into 3 groups: registered, public and priv= ate. Not saying we should mirror it exactly, but as an implementer I liked = how clearly it was stated in that spec. > > > > 2. > > Since this doc is in WG Last call, do we need to remove the reference to > the mix-up I-D (Section 2, "issuer"), or are we expecting them to be > finalized together? > > > > > > On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones > wrote: > > I'm fine with changing dynamic registration from being RECOMMENDED to > OPTIONAL. That's good actionable feedback. Likewise, looking at again, = we > also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAu= th > deployments need keys. > > I expect more good, actionable feedback to also come from the WGLC as > people carefully read the draft with fresh eyes. > > -- Mike > > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Thursday, February 18, 2016 10:33 AM > To: Anthony Nadalin > > Cc: Mike Jones ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; Phil Hunt ; > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > We are establishing a registry. Some folks do use dynamic client > registration. > > We can register it in this document or take it out and let others registe= r > it once the registry is established. > > It will be registered one way or the other. > > One of the reasons for starting last call is to get people to read the > draft and comment. > That seems to be working. > > If you have specific security considerations, please let us know so they > can be addressed. Text is always appreciated. > > John B. > > > On Feb 18, 2016, at 1:27 PM, Anthony Nadalin > wrote: > > > > Not sure about that. There are things that are "recommended" like the > dynamic registration endpoint, I don't understand why this is recommended > as a lot of folks still don't do this. There are security considerations > about all the information that is in the discovery that have not been > addressed. > > > > -----Original Message----- > > From: Mike Jones > > Sent: Thursday, February 18, 2016 10:18 AM > > To: Anthony Nadalin ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; Phil Hunt ; John > Bradley > > Cc: oauth@ietf.org > > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > It's the OAuth-specific subset of what's already widely deployed. > Nothing was invented - just subsetted. > > > > I think it's already as simple as possible unless the working group > decides to remove even more functionality (which it can obviously do). > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadali= n > > Sent: Thursday, February 18, 2016 10:13 AM > > To: Hannes Tschofenig ; Phil Hunt < > phil.hunt@oracle.com>; John Bradley > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > I also think we are way far from last call (and surprised to see last > call issued) on this document as it is still very complex for something > that should be very simple > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > > Sent: Thursday, February 18, 2016 6:47 AM > > To: Phil Hunt ; John Bradley > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > > > > > On 02/18/2016 03:06 PM, Phil Hunt wrote: > >> BTW. I think we are FAR from Last Call on this topic. > > > > Thanks for your feedback, Phil. As you have seen I had issued a WGLC > prior to your message based on the claim from the authors that they belie= ve > the document is finished. > > > > We will, of course, take all reviews into account and see where we are > with the discovery spec. I, as the shepherd, will also do my review and I > encourage many working group members to also take a look at the document > and to provide their input. > > > > Ciao > > Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113ce568ebb8b1052c1093ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 18, 2016 at 11:36 AM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

Thanks, William.=C2=A0 I=E2=80=99m go= od with referencing the registry in Section 2.=C2=A0

=

Great!
=C2=A0
<= p class=3D"MsoNormal"> I=E2=80=99ll think about the register= ed/public/private comment.


I'm not suggesting we necessarily have to use= the same registered/public/private structure, only that some discussion of= standardized vs non-standard could be helpful for implementers (e.g. try t= o pick something that is collision resistant for proprietary metadata).
=C2=A0

It=E2=80=99s fine to reference oauth-= mix-up-mitigation as a draft in a finished RFC as long as it=E2=80=99s an i= nformative and not a normative reference.


Ah ok, I wasn't aware of that.

=C2=A0

From: William Denniss [mailto:wdenniss@google.com]=C2=A0<= br>

Sent: Thursday, February 18, 2016 11:28 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; Anthony Nadalin <tonynad@microsoft.com>; oauth@ietf.org


Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essen= ce

=C2=A0

Two review comments:

=C2=A0

1.

Can the text in "Section 2.=C2=A0 Authorization= Server Metadata" near the end regarding additional metadata be expand= ed? I think we should reference the IANA registry established by this spec = in that section (as this will be the reference point for people looking for other registered metadata), and possibly mention so= mething about registered vs unregistered parameters and interoperability. A= t present if you only read that section it is a little vague.=

=C2=A0

I like the treatment of claims in the JWT spec https:/=
/tools.ietf.org/html/rfc7519#section-4.2, splitting into 3 groups: regi=
stered, public and private. Not saying we should mirror it exactly, but as =
an implementer I liked how clearly it was stated in that spec.
=C2=A0

2.

Since this doc is in WG Last call, do we need to rem= ove the reference to the mix-up I-D (Section 2, "issuer"), or are we expecting them to b= e finalized together?

=C2=A0

=C2=A0

On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

I'm fine with changing dynamic registration from= being RECOMMENDED to OPTIONAL.=C2=A0 That's good actionable feedback.= =C2=A0 Likewise, looking at again, we also need to change jwks_uri from REQ= UIRED to OPTIONAL, since not all OAuth deployments need keys.

I expect more good, actionable feedback to also come from the WGLC as peopl= e carefully read the draft with fresh eyes.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, February 18, 2016 10:33 AM
To: Anthony Nadalin <tonynad@microsoft.com>

Cc: Mike Jones <Michael.Jones@microsoft.com>; Hannes= Tschofenig <hannes.tschofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

We are establishing a registry.=C2=A0 Some folks do use dynamic client regi= stration.

We can register it in this document or take it out and let others register = it once the registry is established.

It will be registered one way or the other.

One of the reasons for starting last call is to get people to read the draf= t and comment.
That seems to be working.

If you have specific security considerations, please let us know so they ca= n be addressed.=C2=A0 =C2=A0Text is always appreciated.

John B.

> On Feb 18, 2016, at 1:27 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:<= br> >
> Not sure about that. There are things that are "recommended"= like the dynamic registration endpoint, I don't understand why this is= recommended as a lot of folks still don't do this. There are security = considerations about all the information that is in the discovery that have not been addressed.
>
> -----Original Message-----
> From: Mike Jones
> Sent: Thursday, February 18, 2016 10:18 AM
> To: Anthony Nadalin <tonynad@microsoft.com>; Hannes Tschofenig <hannes.tschofenig@g= mx.net>; Phil Hunt <phil.hunt@oracle.com>; John Bradley <ve= 7jtb@ve7jtb.com>
> Cc: oauth@ietf.org=
> Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence=
>
> It's the OAuth-specific subset of what's already widely deploy= ed.=C2=A0 Nothing was invented - just subsetted.
>
> I think it's already as simple as possible unless the working grou= p decides to remove even more functionality (which it can obviously do). >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Thursday, February 18, 2016 10:13 AM
> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com= >; John Bradley <ve7jtb@ve7jtb.com>
> Cc: oauth@ietf.org=
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence=
>
> I also think we are way far from last call (and surprised to see last = call issued) on this document as it is still very complex for something tha= t should be very simple
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Thursday, February 18, 2016 6:47 AM
> To: Phil Hunt <phil.hunt@oracle.com>; John Bradley <ve7jtb@ve7jtb.com>
> Cc: oauth@ietf.org=
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence=
>
>
>
> On 02/18/2016 03:06 PM, Phil Hunt wrote:
>> BTW. I think we are FAR from Last Call on this topic.
>
> Thanks for your feedback, Phil. As you have seen I had issued a WGLC p= rior to your message based on the claim from the authors that they believe = the document is finished.
>
> We will, of course, take all reviews into account and see where we are= with the discovery spec. I, as the shepherd, will also do my review and I = encourage many working group members to also take a look at the document an= d to provide their input.
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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

=C2=A0


--001a113ce568ebb8b1052c1093ea-- From nobody Thu Feb 18 11:53:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1575E1B33BB for ; Thu, 18 Feb 2016 11:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 pQVNQacu_b8b for ; Thu, 18 Feb 2016 11:53:38 -0800 (PST) Received: from p3plwbeout02-01.prod.phx3.secureserver.net (p3plsmtp02-01-2.prod.phx3.secureserver.net [72.167.218.94]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0B81B349A for ; Thu, 18 Feb 2016 11:53:24 -0800 (PST) Received: from localhost ([72.167.218.17]) by p3plwbeout02-01.prod.phx3.secureserver.net with bizsmtp id KvtQ1s0010P6mCQ01vtQov; Thu, 18 Feb 2016 12:53:24 -0700 X-SID: KvtQ1s0010P6mCQ01 Received: (qmail 31612 invoked by uid 99); 18 Feb 2016 19:53:24 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_38048772a95672ad6c58c06d5afa1132" To: oauth@ietf.org From: mark@rocksolidimports.com In-Reply-To: Date: Thu, 18 Feb 2016 12:53:23 -0700 Message-Id: <20160218125323.775e101fb789049a384b75407b90d462.08c711b435.mailapi@email02.secureserver.net> X-Originating-IP: 73.247.22.253 User-Agent: MailAPI X-Sender: mark@rocksolidimports.com Archived-At: Subject: [OAUTH-WG] " Help" unsubscribe X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:53:47 -0000 --=_38048772a95672ad6c58c06d5afa1132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please remove/unsubscribe this email address. =20 Thanks =20 =20 Mark Warwick=20 Rock Solid Imports 1700 Quincy Ave Suite #102 Naperville, IL 60540 630-532-2622 www.rocksolidimports.com =20 =20 =20 =20 =20 --------- Original Message --------- Subject: OAuth Digest, Vol 88, Issue 8= 1 From: oauth-request@ietf.org Date: 2/18/16 1:43 pm To: oauth@ietf.org Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: 2nd Call for Adoption: Authentication Method Reference Values (William Denniss) 2. Re: OAuth Discovery spec pared down to its essence (William Denniss) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Feb 2016 11:39:52 -0800 From: William Denniss To: Hannes Tschofenig Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values Message-ID: Content-Type: text/plain; charset=3D"utf-8" +1 to adopt. My previous concerns of this draft have been addressed, and I am supportive of having an IANA registry of amr values. On Thu, Feb 18, 2016 at 5:09 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > In response to my message to the list regarding the initial call for > adoption of the Authentication Method Reference Values draft, see > https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike > submitted an updated version of the document to take raised concerns > into account. Several working group participants responded positively to > the new version. > > We would therefore like to issue a 2nd call for adoption of the recently > submitted version -05: > https://tools.ietf.org/html/draft-jones-oauth-amr-values-05 > > Please let us know by March 3rd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 18 Feb 2016 11:42:56 -0800 From: William Denniss To: Mike Jones Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence Message-ID: Content-Type: text/plain; charset=3D"utf-8" On Thu, Feb 18, 2016 at 11:36 AM, Mike Jones wrote: > Thanks, William. I?m good with referencing the registry in Section 2. > Great! > I?ll think about the registered/public/private comment. > > I'm not suggesting we necessarily have to use the same registered/public/private structure, only that some discussion of standardized vs non-standard could be helpful for implementers (e.g. try to pick something that is collision resistant for proprietary metadata). > It?s fine to reference oauth-mix-up-mitigation as a draft in a finished > RFC as long as it?s an informative and not a normative reference. > Ah ok, I wasn't aware of that. > *From:* William Denniss [mailto:wdenniss@google.com] > > *Sent:* Thursday, February 18, 2016 11:28 AM > *To:* Mike Jones > *Cc:* John Bradley ; Anthony Nadalin < > tonynad@microsoft.com>; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > Two review comments: > > > > 1. > > Can the text in "Section 2. Authorization Server Metadata" near the end > regarding additional metadata be expanded? I think we should reference th= e > IANA registry established by this spec in that section (as this will be t= he > reference point for people looking for other registered metadata), and > possibly mention something about registered vs unregistered parameters an= d > interoperability. At present if you only read that section it is a little > vague. > > > > I like the treatment of claims in the JWT spec https://tools.ietf.org/htm= l/rfc7519#section-4.2, splitting into 3 groups: registered, public and priv= ate. Not saying we should mirror it exactly, but as an implementer I liked = how clearly it was stated in that spec. > > > > 2. > > Since this doc is in WG Last call, do we need to remove the reference to > the mix-up I-D (Section 2, "issuer"), or are we expecting them to be > finalized together? > > > > > > On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones > wrote: > > I'm fine with changing dynamic registration from being RECOMMENDED to > OPTIONAL. That's good actionable feedback. Likewise, looking at again, we > also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAu= th > deployments need keys. > > I expect more good, actionable feedback to also come from the WGLC as > people carefully read the draft with fresh eyes. > > -- Mike > > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Thursday, February 18, 2016 10:33 AM > To: Anthony Nadalin > > Cc: Mike Jones ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; Phil Hunt ; > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > We are establishing a registry. Some folks do use dynamic client > registration. > > We can register it in this document or take it out and let others registe= r > it once the registry is established. > > It will be registered one way or the other. > > One of the reasons for starting last call is to get people to read the > draft and comment. > That seems to be working. > > If you have specific security considerations, please let us know so they > can be addressed. Text is always appreciated. > > John B. > > > On Feb 18, 2016, at 1:27 PM, Anthony Nadalin > wrote: > > > > Not sure about that. There are things that are "recommended" like the > dynamic registration endpoint, I don't understand why this is recommended > as a lot of folks still don't do this. There are security considerations > about all the information that is in the discovery that have not been > addressed. > > > > -----Original Message----- > > From: Mike Jones > > Sent: Thursday, February 18, 2016 10:18 AM > > To: Anthony Nadalin ; Hannes Tschofenig < > hannes.tschofenig@gmx.net>; Phil Hunt ; John > Bradley > > Cc: oauth@ietf.org > > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > It's the OAuth-specific subset of what's already widely deployed. > Nothing was invented - just subsetted. > > > > I think it's already as simple as possible unless the working group > decides to remove even more functionality (which it can obviously do). > > > > -- Mike > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadali= n > > Sent: Thursday, February 18, 2016 10:13 AM > > To: Hannes Tschofenig ; Phil Hunt < > phil.hunt@oracle.com>; John Bradley > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > I also think we are way far from last call (and surprised to see last > call issued) on this document as it is still very complex for something > that should be very simple > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > > Sent: Thursday, February 18, 2016 6:47 AM > > To: Phil Hunt ; John Bradley > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > > > > > On 02/18/2016 03:06 PM, Phil Hunt wrote: > >> BTW. I think we are FAR from Last Call on this topic. > > > > Thanks for your feedback, Phil. As you have seen I had issued a WGLC > prior to your message based on the claim from the authors that they belie= ve > the document is finished. > > > > We will, of course, take all reviews into account and see where we are > with the discovery spec. I, as the shepherd, will also do my review and I > encourage many working group members to also take a look at the document > and to provide their input. > > > > Ciao > > Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 88, Issue 81 ************************************* --=_38048772a95672ad6c58c06d5afa1132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Please remove/unsubscribe this email address.
 
Thanks
 
 
Mark Warwick 
Rock Solid Imports
1700 Quincy Ave Suite #102
Naperville, IL 60540
630-532-2622
www.rocksolidimports.com
 
 
 
 
 
--------- Original Message -----= ----
Subject: OAuth Digest, Vol 88, Issue 81
From: oauth-request@ietf= =2Eorg
Date: 2/18/16 1:43 pm
To: oauth@ietf.org

Send O= Auth mailing list submissions to
oauth@ietf.org

To subscrib= e or unsubscribe via the World Wide Web, visit
https://www.ietf.org/ma= ilman/listinfo/oauth
or, via email, send a message with subject or bod= y 'help' to
oauth-request@ietf.org

You can reach the person= managing the list at
oauth-owner@ietf.org

When replying, p= lease edit your Subject line so it is more specific
than "Re: Contents= of OAuth digest..."


Today's Topics:

1. Re: 2nd= Call for Adoption: Authentication Method Reference
Values (William De= nniss)
2. Re: OAuth Discovery spec pared down to its essence
(Wil= liam Denniss)


--------------------------------------------= --------------------------

Message: 1
Date: Thu, 18 Feb 201= 6 11:39:52 -0800
From: William Denniss <wdenniss@google.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: "oauth@i= etf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] 2nd Call for A= doption: Authentication Method
Reference Values
Message-ID:
= <CAAP42hCR0TP0+qEvXhix0S+b1C0s1Sp7E6N2nhFh7vHaGrQp_g@mail.gmail.com><= br />Content-Type: text/plain; charset=3D"utf-8"

+1 to adopt.
My previous concerns of this draft have been addressed, and I am s= upportive
of having an IANA registry of amr values.

On Thu,= Feb 18, 2016 at 5:09 AM, Hannes Tschofenig <
hannes.tschofenig@gmx= =2Enet> wrote:

> In response to my message to the list reg= arding the initial call for
> adoption of the Authentication Method= Reference Values draft, see
> https://www.ietf.org/mail-archive/we= b/oauth/current/msg15694.html, Mike
> submitted an updated version = of the document to take raised concerns
> into account. Several wor= king group participants responded positively to
> the new version= =2E
>
> We would therefore like to issue a 2nd call for ado= ption of the recently
> submitted version -05:
> https://to= ols.ietf.org/html/draft-jones-oauth-amr-values-05
>
> Pleas= e let us know by March 3rd whether you accept / object to the
> ado= ption of this document as a starting point for work in the OAuth
> = working group.
>
> Ciao
> Hannes & Derek
&= gt;
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>
>
-------------- next = part --------------
An HTML attachment was scrubbed...
URL: <h= ttps://mailarchive.ietf.org/arch/browse/oauth/attachments/20160218/6d7b6e3b= /attachment.html>

------------------------------

M= essage: 2
Date: Thu, 18 Feb 2016 11:42:56 -0800
From: William Den= niss <wdenniss@google.com>
To: Mike Jones <Michael.Jones@micr= osoft.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject= : Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
Messag= e-ID:
<CAAP42hD7Hy78ADm+i70XV=3DhCkWsXw_YvhRtwcE+CiNTpC_Zy8A@mail= =2Egmail.com>
Content-Type: text/plain; charset=3D"utf-8"

On Thu, Feb 18, 2016 at 11:36 AM, Mike Jones <Michael.Jones@microsoft= =2Ecom>
wrote:

> Thanks, William. I?m good with refer= encing the registry in Section 2.
>

Great!

> I?ll think about the registered/public/private comment.
><= br />>
I'm not suggesting we necessarily have to use the same
= registered/public/private structure, only that some discussion of
stan= dardized vs non-standard could be helpful for implementers (e.g. try to
pick something that is collision resistant for proprietary metadata).


> It?s fine to reference oauth-mix-up-mitigation as a draf= t in a finished
> RFC as long as it?s an informative and not a norm= ative reference.
>

Ah ok, I wasn't aware of that.
<= br />

> *From:* William Denniss [mailto:wdenniss@google.com]<= br />>
> *Sent:* Thursday, February 18, 2016 11:28 AM
> = *To:* Mike Jones <Michael.Jones@microsoft.com>
> *Cc:* John B= radley <ve7jtb@ve7jtb.com>; Anthony Nadalin <
> tonynad@mi= crosoft.com>; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-W= G] OAuth Discovery spec pared down to its essence
>
>
= >
> Two review comments:
>
>
>
>= 1.
>
> Can the text in "Section 2. Authorization Server Me= tadata" near the end
> regarding additional metadata be expanded? I= think we should reference the
> IANA registry established by this = spec in that section (as this will be the
> reference point for peo= ple looking for other registered metadata), and
> possibly mention = something about registered vs unregistered parameters and
> interop= erability. At present if you only read that section it is a little
>= ; vague.
>
>
>
> I like the treatment of cl= aims in the JWT spec https://tools.ietf.org/html/rfc7519#section-4.2, split= ting into 3 groups: registered, public and private. Not saying we should mi= rror it exactly, but as an implementer I liked how clearly it was stated in= that spec.
>
>
>
> 2.
>
> = Since this doc is in WG Last call, do we need to remove the reference to> the mix-up I-D (Section 2, "issuer"), or are we expecting them to b= e
> finalized together?
>
>
>
>
>
> On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones <Michael= =2EJones@microsoft.com>
> wrote:
>
> I'm fine wi= th changing dynamic registration from being RECOMMENDED to
> OPTION= AL. That's good actionable feedback. Likewise, looking at again, we
&g= t; also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OA= uth
> deployments need keys.
>
> I expect more good= , actionable feedback to also come from the WGLC as
> people carefu= lly read the draft with fresh eyes.
>
> -- Mike
>> -----Original Message-----
> From: John Bradley [mailto:ve= 7jtb@ve7jtb.com]
> Sent: Thursday, February 18, 2016 10:33 AM
= > To: Anthony Nadalin <tonynad@microsoft.com>
>
> = Cc: Mike Jones <Michael.Jones@microsoft.com>; Hannes Tschofenig <<= br />> hannes.tschofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com= >;
> oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Disc= overy spec pared down to its essence
>
> We are establishin= g a registry. Some folks do use dynamic client
> registration.
>
> We can register it in this document or take it out and let = others register
> it once the registry is established.
>> It will be registered one way or the other.
>
> One= of the reasons for starting last call is to get people to read the
&g= t; draft and comment.
> That seems to be working.
>
&g= t; If you have specific security considerations, please let us know so they=
> can be addressed. Text is always appreciated.
>
>= ; John B.
>
> > On Feb 18, 2016, at 1:27 PM, Anthony Nad= alin <tonynad@microsoft.com>
> wrote:
> >
>= ; > Not sure about that. There are things that are "recommended" like th= e
> dynamic registration endpoint, I don't understand why this is r= ecommended
> as a lot of folks still don't do this. There are secur= ity considerations
> about all the information that is in the disco= very that have not been
> addressed.
> >
> > = -----Original Message-----
> > From: Mike Jones
> > S= ent: Thursday, February 18, 2016 10:18 AM
> > To: Anthony Nadali= n <tonynad@microsoft.com>; Hannes Tschofenig <
> hannes.ts= chofenig@gmx.net>; Phil Hunt <phil.hunt@oracle.com>; John
>= ; Bradley <ve7jtb@ve7jtb.com>
> > Cc: oauth@ietf.org
= > > Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its es= sence
> >
> > It's the OAuth-specific subset of what'= s already widely deployed.
> Nothing was invented - just subsetted= =2E
> >
> > I think it's already as simple as possibl= e unless the working group
> decides to remove even more functional= ity (which it can obviously do).
> >
> > -- Mike
> >
> > -----Original Message-----
> > From: O= Auth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
>= > Sent: Thursday, February 18, 2016 10:13 AM
> > To: Hannes = Tschofenig <hannes.tschofenig@gmx.net>; Phil Hunt <
> phil= =2Ehunt@oracle.com>; John Bradley <ve7jtb@ve7jtb.com>
> &g= t; Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] OAuth Discover= y spec pared down to its essence
> >
> > I also think= we are way far from last call (and surprised to see last
> call is= sued) on this document as it is still very complex for something
> = that should be very simple
> >
> > -----Original Mess= age-----
> > From: OAuth [mailto:oauth-bounces@ietf.org] On Beha= lf Of Hannes
> Tschofenig
> > Sent: Thursday, February 1= 8, 2016 6:47 AM
> > To: Phil Hunt <phil.hunt@oracle.com>; = John Bradley <ve7jtb@ve7jtb.com>
> > Cc: oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its= essence
> >
> >
> >
> > On 02/= 18/2016 03:06 PM, Phil Hunt wrote:
> >> BTW. I think we are F= AR from Last Call on this topic.
> >
> > Thanks for y= our feedback, Phil. As you have seen I had issued a WGLC
> prior to= your message based on the claim from the authors that they believe
&g= t; the document is finished.
> >
> > We will, of cour= se, take all reviews into account and see where we are
> with the d= iscovery spec. I, as the shepherd, will also do my review and I
> e= ncourage many working group members to also take a look at the document
> and to provide their input.
> >
> > Ciao
= > > Hannes
> >
> > ____________________________= ___________________
> > OAuth mailing list
> > OAuth@= ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
&g= t;
> _______________________________________________
> OAut= h mailing list
> OAuth@ietf.org
> https://www.ietf.org/mail= man/listinfo/oauth
>
>
>
-------------- next p= art --------------
An HTML attachment was scrubbed...
URL: <ht= tps://mailarchive.ietf.org/arch/browse/oauth/attachments/20160218/ff25f9cb/= attachment.html>

------------------------------

Su= bject: Digest Footer

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


------------------------------

End of OAuth Digest, Vol 88, Issue 81
*************************= ************
--=_38048772a95672ad6c58c06d5afa1132-- From nobody Thu Feb 18 18:04:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC11A892B for ; Thu, 18 Feb 2016 18:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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-pciXJEWiyQ for ; Thu, 18 Feb 2016 18:04:50 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3F1A8927 for ; Thu, 18 Feb 2016 18:04:48 -0800 (PST) Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs02.index.or.jp (Postfix) with SMTP id 383DE19686A; Fri, 19 Feb 2016 11:04:48 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp (unknown) with ESMTP id u1J24lpY019854; Fri, 19 Feb 2016 11:04:47 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1J24lXg024696; Fri, 19 Feb 2016 11:04:47 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u1J24lqx024695; Fri, 19 Feb 2016 11:04:47 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1J24leZ024692; Fri, 19 Feb 2016 11:04:47 +0900 From: "Nat Sakimura" To: "'Phil Hunt \(IDM\)'" , "'Mike Jones'" References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> In-Reply-To: <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> Date: Fri, 19 Feb 2016 11:04:52 +0900 Message-ID: <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F4_01D16B05.5B794DE0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGS4qFsTGL4fIzuwSUDfPQF/59lfwFfZWRKAXSIQK8DFjyYOQKDVIVZAUNy/HEBYalTWQDkn8zeAONwRlGfSNPY4A== Content-Language: ja x-mailadviser: 20141126 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 02:04:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F4_01D16B05.5B794DE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Phil,=20 =20 You wrote:=20 > If example.com had separate oauth servers for = services xyz and abc,=20 > how would discovery work from a single /.well-known endpoint? =20 I am trying to understand your use case, but I am not sure if I do.=20 =20 The use case seems to be such that:=20 =20 - There is a client C1. It could be a CRM or any kind of = application that uses RFC6749 and RFC6750 to access other resources a = resource server R1. C1 and R1 has a pre-configured relationship.=20 - The resource server R1 supports RFC6750, and can have multiple = OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An.=20 - Ax supports multiple resource services, Rx.=20 - There is a user U1 that wants to access C1, which in turn = access R1. U1 gets authenticated somehow at C1. It could be either = through a password system at C1, or through a federated login protocol = supported at Ax, such as OpenID Connect.=20 =20 Another possibility is a case where Cx =3D Rx, which makes things a bit = simpler.=20 =20 Is this what you have in mind? Please let me know. If it is not, please = correct me. =20 Cheers,=20 =20 Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM) Sent: Friday, February 19, 2016 2:09 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 How does the client request the oauth configuration assigned to xyz? =20 The example you give appears to presume a single oauth infrastructure = for all apps.=20 =20 The only way right now to have apps specific oauth is to infer the = relation by the domain "xyz.example.com". =20 =20 That makes discovery more complex because there arw many more discovery = locations and many more configurations to maintain.=20 =20 If example.com had separate oauth servers for = services xyz and abc, how would discovery work from a single /.well-know = endpoint? Phil On Feb 18, 2016, at 09:41, Mike Jones > wrote: Let me second John=E2=80=99s point that OAuth configuration information = and application configuration information need not be interspersed. For = instance, if the service is at https://example.com and the XYZ = application is being used, then these configuration metadata documents = could both be used: * https://example.com/.well-known/openid-configuration - OAuth = configuration metadata * https://example.com/.well-known/xyz-configuration - XYZ = configuration metadata =20 There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 = value, since there is no such thing as generic OAuth 2.0. By = definition, it must always be used in an application context that = profiles OAuth 2.0 to enable interoperability. The existing = /.well-known/openid-configuration value works fine for this purpose. = Yes, the optics of having a different value might seem better but it = comes at the cost of interoperability problems. In my view, interop = trumps optics. =20 To a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context. The editors took WebFinger out = of the OAuth Discovery document since it isn=E2=80=99t always = applicable. =20 Cheers, -- Mike =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Thursday, February 18, 2016 7:41 AM To: Phil Hunt > Cc: Mike Jones >; oauth@ietf.org = =20 Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 I suspect that the configuration well-knowns are going to be on the root = domain. You could try and get a user to put in crm.example.com = , but I suspect that is not going to work. =20 If the app doesn=E2=80=99t have a specific protocol identifier then it = would use the default. =20 =20 I don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app. =20 John B. =20 =20 =20 =20 =20 =20 On Feb 18, 2016, at 9:49 AM, Phil Hunt > wrote: =20 resource service X could be any http accessible service: =20 * CRM * Finance * Payroll * ERP * any application on the web. =20 The spec seems to suggest that we use /.well-known/crm to discover OAuth = config for crm. But that may cause conflict if crm has its own = discovery. Which leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. =20 Then there is confusion about what host the discovery is done on. =20 For example, hypothetically do I do: =20 GET /.well-known/crm Host: example.com =20 =20 But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? =20 Or, what If we put the oauth configuration at the host for the crm = service: GET /.well-known/openid-configuration Host: crm.example.com =20 =20 I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 =20 The client needs to discover: * Where is its designated resource service and what security does it use * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 18, 2016, at 7:19 AM, John Bradley > wrote: =20 Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? =20 Is that the RS base URI for the resource, a specific URI that the = client is requesting? =20 That is getting UMA ish.=20 =20 The concept of a base RS URI is a rat hole that I prefer not to go down, = as it is something everyone thinks exists but like SCIM if it exists it = is protocol or deployment specific. =20 The notion that you would send the URI you are planning on requesting to = a Webfinger server to find the OAuth server, is probably going to have = privacy issues. =20 I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. =20 RS discovery probably wants to be separate from AS discovery. (Yes I do = think we need something, UMA rpt or something like it might be a way to = go) =20 John B. =20 On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: =20 Maybe SCIM was a bad example. It functions as a RESTful resource in the = context of OAuth. =20 I find the use of OIDC to be confusing as an example (and the default) = because it is both an OAuth resource and a security service. It is a = modification of OAuth. =20 Start thinking about every application ever written that uses OAuth. Are = we expecting 100s of thousands of these to each register? =20 To me, this specification is a fine specification for OIDC and it should = be published there because the specification defines how to discovery = OAuth and OpenID information. =20 Likewise you suggest it is ok for SCIM to do the same.=20 =20 How do we expect normal applications to set up and do discovery? =20 It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. =20 That still allows me to have a separate discovery service that says, = tell me about resource service X itself. =20 BTW. I think we are FAR from Last Call on this topic. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: =20 Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. =20 It should be posable to have them as one document, but forcing them to = use one document is going to cause a explosion of claim registration for = discovery. =20 I think it is better for SCIM to register one well known than to have to = register 20 claims with scim prefixes or something silly like that. =20 Name-spacing the claims by allowing them to be in different well known = files is not unreasonable. =20 Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. =20 Nothing stops a protocol from doing what it likes with webfinger if it = wants to use that for discovery. =20 In principal I like the idea of having another protocol as an example. =20 My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 I personally think sorting out discovery for SCIM is a good idea, but = OAUTh is but one of several authentication methods for SCIM, and there = are probably other non OAuth things that want to be described. =20 I would feel better about using it as an example if it were adopted by = the WG and some general interest shown. =20 I encourage you to do that so we can use it as a example. =20 John B. =20 On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: =20 I still find the following text objectionable and confusing=E2=80=A6 By default, for historical reasons, unless an application-specific well-known URI path suffix is registered and used for an application, the client for that application SHOULD use the well-known URI path suffix "openid-configuration" and publish the metadata document at the path formed by concatenating "/.well-known/openid-configuration" to the authorization server's issuer identifier. As described in Section 5 = , = despite the identifier "/.well-known/openid-configuration", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect. =20 Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. =20 It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). =20 GET /.well-known/openid-configuration and GET /.well-known/scim Retrieve the OAuth configuration for the application openid and scim = respectively. =20 The use of: GET /.well-known/oauth2/ Should be the default used when there is no known application based = well-known application based URI discovery. =20 Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? =20 It seemed better to me to use the webfinger syntax to allow the client = to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: =20 In response to working group input, this version of the OAuth Discovery = specification has been pared down to its essence =E2=80=93 leaving only = the features that are already widely deployed. Specifically, all that = remains is the definition of the authorization server discovery metadata = document and the metadata values used in it. The WebFinger discovery = logic has been removed. The relationship between the issuer identifier = URL and the well-known URI path relative to it at which the discovery = metadata document is located has also been clarified. =20 Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. =20 The specification is available at: * = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 =20 An HTML-formatted version is also available at: * = = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html =20 -- Mike & Nat = & John =20 P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org = https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 ------=_NextPart_000_01F4_01D16B05.5B794DE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

H= i Phil,

<= o:p> 

Y= ou wrote:

&= gt; If example.com had separate = oauth servers for services xyz and abc,

> how would discovery work from = a single /.well-known endpoint?

<= o:p> 

I= am trying to understand your use case, but I am not sure if I do. =

<= o:p> 

T= he use case seems to be such that:

<= o:p> 

<= span style=3D'mso-list:Ignore'>-        = T= here is a client C1. It could be a CRM or any kind of application that = uses RFC6749 and RFC6750 to access other resources a resource server R1. = C1 and R1 has a pre-configured relationship.

<= span style=3D'mso-list:Ignore'>-        = T= he resource server R1 supports RFC6750, and can have multiple OAuth = RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An. =

<= span style=3D'mso-list:Ignore'>-        = A= x supports multiple resource services, Rx.

<= span style=3D'mso-list:Ignore'>-        = T= here is a user U1 that wants to access C1, which in turn access R1. U1 = gets authenticated somehow at C1. It could be either through a password = system at C1, or through a federated login protocol supported at Ax, = such as OpenID Connect.

<= o:p> 

A= nother possibility is a case where Cx =3D Rx, which makes things a bit = simpler.

<= o:p> 

I= s this what you have in mind? Please let me know. If it is not, please = correct me.

<= o:p> 

C= heers,

<= o:p> 

N= at

--=

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt = (IDM)
Sent: Friday, February 19, 2016 2:09 AM
To: = Mike Jones
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] OAuth Discovery spec pared down to its = essence

 

How does the client request the oauth configuration = assigned to xyz?

 

The = example you give appears to presume a single oauth infrastructure for = all apps. 

 

The only = way right now to have apps specific oauth is to infer the relation by = the domain "xyz.example.com". =  

 

That = makes discovery more complex because there arw many more discovery = locations and many more configurations to = maintain. 

 

If example.com had separate oauth servers = for services xyz and abc, how would discovery work from a single = /.well-know endpoint?


Phil


On Feb 18, 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com> wrote:

Let me second John=E2=80=99s point that OAuth configuration information = and application configuration information need not be = interspersed.  For instance, if the service is at https://example.com and the XYZ = application is being used, then these configuration metadata documents = could both be used:

=C2=B7       = https://exa= mple.com/.well-known/openid-configuration - OAuth configuration = metadata

=C2=B7       = https://exampl= e.com/.well-known/xyz-configuration - XYZ configuration = metadata

 

There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 = value, since there is no such thing as generic OAuth 2.0.  By = definition, it must always be used in an application context that = profiles OAuth 2.0 to enable interoperability.  The existing = /.well-known/openid-configuration value works fine for this = purpose.  Yes, the optics of having a different value might seem = better but it comes at the cost of interoperability problems.  In = my view, interop trumps optics.

 

To a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context.  The editors took WebFinger = out of the OAuth Discovery document since it isn=E2=80=99t always = applicable.

 

            =             &= nbsp;           &n= bsp;           &nb= sp;         Cheers,

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

 

From:<= /b> John = Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil = Hunt <phil.hunt@oracle.com>
C= c: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: = [OAUTH-WG] OAuth Discovery spec pared down to its essence

 

I suspect that the configuration = well-knowns are going to be on the root domain.   You could try and = get a user to put in crm.example.com, but I suspect that = is not going to work.

 

If the app doesn=E2=80=99t have a = specific protocol identifier then it would use the default. =  

 

I don=E2=80=99t know if you can get = around having some sort of app/protocol identifier configured in the = app.

 

John = B.

 

 

 

 

 

 

On Feb 18, 2016, at 9:49 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

resource service X could be any = http accessible service:

 

* = CRM

* Finance

* = Payroll

* ERP

* any application on the = web.

 

The spec seems to suggest that we = use /.well-known/crm to discover OAuth config for crm.  But that = may cause conflict if crm has its own discovery. Which leads us down the = path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D.

 

Then there is confusion about what = host the discovery is done on.

 

For example, hypothetically do I = do:

 

GET = /.well-known/crm

<= div>

 

But what about the CRM=E2=80=99s = configuration information. Is this stomping on = it?

 

Or, what If we put the oauth = configuration at the host for the crm = service:

GET = /.well-known/openid-configuration

 

I think the point is that there is = a relationship between a protected resource and its designated OAuth = service. 

 

The client needs to = discover:

* Where is its designated resource service and what = security does it use

* If it is OAuth, where is the = intended OAuth configuration for that resource service = instance?

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 18, 2016, at 7:19 AM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Can you clarify what you mean by = =E2=80=9Cresource service x=E2=80=9D?

 

Is that the RS base URI for the = resource,  a specific URI that the client is = requesting?

 

That is getting UMA = ish. 

 

The concept of a base RS URI is a = rat hole that I prefer not to go down, as it is something everyone = thinks exists but like SCIM if it exists it is protocol or deployment = specific.

 

The notion that you would send the = URI you are planning on requesting to a Webfinger server to find the = OAuth server, is probably going to have privacy = issues.

 

I suspect that you need to hand = back a error from the resource to say where the AS is, or have a = .well-known for the RS.

 

RS discovery probably wants to be = separate from AS discovery.  (Yes I do think we need something, =  UMA rpt or something like it might be a way to = go)

 

John = B.

 

On Feb 18, 2016, at 9:06 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

Maybe SCIM was a bad example. =  It functions as a RESTful resource in the context of = OAuth.

 

I find the use of OIDC to be = confusing as an example (and the default) because it is both an OAuth = resource and a security service.  It is a modification of = OAuth.

 

Start thinking about every = application ever written that uses OAuth. Are we expecting 100s of = thousands of these to each register?

 

To me, this specification is a fine = specification for OIDC and it should be published there because the = specification defines how to discovery OAuth and OpenID = information.

 

Likewise you suggest it is ok for = SCIM to do the same. 

 

How do we expect normal = applications to set up and do = discovery?

 

It seems to me that an = =E2=80=9COAUTH=E2=80=9D discovery spec should have a parameter to ask, I = want to discover OAuth configuration for resource service = X.

 

That still allows me to have a = separate discovery service that says, tell me about resource service X = itself.

 

BTW. I think we are FAR from Last = Call on this topic.

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 18, 2016, at 6:55 AM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Diffrent protocols like Connect and = SCIM may have different configurations, endpoints , keys , = authentication methods, scopes etc.

 

It should be posable to have them = as one document, but forcing them to use one document is going to cause = a explosion of claim registration for = discovery.

 

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like = that.

 

Name-spacing the claims by allowing = them to be in different well known files is not = unreasonable.

 

Remember some of these protocols = may be hosted on SaaS so there is no guarantee that all protocols will = have the same OAuth Config.

 

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

 

In principal I like the idea of = having another protocol as an = example.

 

My only concern is that I = haven=E2=80=99t seen any discussion of your SCIM discovery document in = the SCIM WG.  

I personally think sorting out = discovery for SCIM is a good idea,  but OAUTh is but one of several = authentication methods for SCIM, and there are probably other non OAuth = things that want to be described.

 

I would feel better about using it = as an example if it were adopted by the WG and some general interest = shown.

 

I encourage you to do that so we = can use it as a example.

 

John = B.

 

On Feb 18, 2016, at 8:35 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

I still find the following text = objectionable and = confusing=E2=80=A6

   By =
default, for historical reasons, unless an =
application-specific
   =
well-known URI path suffix is registered and used for an =
application,
   the =
client for that application SHOULD use the well-known URI =
path
   =
suffix "openid-configuration" and publish the metadata =
document at
   the =
path formed by concatenating =
"/.well-known/openid-configuration"
   to = the authorization server's issuer identifier.  As described = in
   Section 5, despite the identifier
   =
"/.well-known/openid-configuration", appearing to be =
OpenID-specific,
   its =
usage in this specification is actually referring to a =
general
   OAuth =
2.0 feature that is not specific to OpenID =
Connect.

 

Further, as a default = =E2=80=9Copenid-configuration=E2=80=9D as the default further gives = people the impression that a plain OAuth server *is* an authentication = server and that the normal access token received is evidence of a = successful authentication.

 

It would be better to point out = that application may include oauth discovery in their discovery URI and = that OAuth is an example of this. It might be good to include two = examples.  E.g. OIDC and SCIM (as another referenceable = example).

 

 GET =
/.well-known/openid-configuration

and

 GET =
/.well-known/scim

Retrieve the OAuth configuration = for the application openid and scim = respectively.

 

The use = of:

 GET =
/.well-known/oauth2/

Should be the default used when = there is no known application based well-known application based URI = discovery.

 

Of course, the concern I raised = earlier is that this approach of application specific URIs ends up = requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

 

It seemed better to me to use the = webfinger syntax to allow the client to say =E2=80=9CI want the = designated OAuth configuration for the resource service X=E2=80=9D would = be a better design that avoids extensive IANA = registration.

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 17, 2016, at 11:48 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

 

 =

An = HTML-formatted version is also available at:

 =

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

 =

P.S.  = This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.

____________= ___________________________________
OAuth mailing = list
OAuth@ietf.org
<= span lang=3DEN-US>https://www.ietf.org/mailman/listinfo/oauth

 

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

 

<= /div>

 

 

<= /div>

 

<= /div>

 

------=_NextPart_000_01F4_01D16B05.5B794DE0-- From nobody Thu Feb 18 20:58:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A641D1ACDEE for ; Thu, 18 Feb 2016 20:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YylaU-Hjdyaj for ; Thu, 18 Feb 2016 20:58:06 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEE11ACDE7 for ; Thu, 18 Feb 2016 20:58:05 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1J4w4a9027531 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 19 Feb 2016 04:58:04 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1J4w3hf014766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 04:58:03 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1J4w3FB008995; Fri, 19 Feb 2016 04:58:03 GMT Received: from [10.5.50.218] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 20:57:53 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-225333FC-B1C0-4405-90EE-E51F6DFEFE4F Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> Date: Thu, 18 Feb 2016 21:57:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> To: Nat Sakimura X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 04:58:11 -0000 --Apple-Mail-225333FC-B1C0-4405-90EE-E51F6DFEFE4F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No. Much simpler.=20 A service provider has decided to have a separate oauth server for each web '= property'. This could be because they were acquired separately and run diffe= rent infrastructures. Or the business structure keeps each BU completely sep= arate.=20 The client can't really depend on previously known or hard coded endpoints b= ecause there are 1000s of instances deployed (eg as in tenancies).=20 This dynamic discovery is going to be particularly true of open source softw= are that customers choose to host on PaaS cloud providers of their choosing.= =20 Phil > On Feb 18, 2016, at 19:04, Nat Sakimura wrote: >=20 > Hi Phil, > =20 > You wrote: > > If example.com had separate oauth servers for services xyz and abc, > > how would discovery work from a single /.well-known endpoint? > =20 > I am trying to understand your use case, but I am not sure if I do. > =20 > The use case seems to be such that: > =20 > - There is a client C1. It could be a CRM or any kind of applicatio= n that uses RFC6749 and RFC6750 to access other resources a resource server R= 1. C1 and R1 has a pre-configured relationship. > - The resource server R1 supports RFC6750, and can have multiple OA= uth RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An. > - Ax supports multiple resource services, Rx. > - There is a user U1 that wants to access C1, which in turn access R= 1. U1 gets authenticated somehow at C1. It could be either through a passwor= d system at C1, or through a federated login protocol supported at Ax, such a= s OpenID Connect. > =20 > Another possibility is a case where Cx =3D Rx, which makes things a bit si= mpler. > =20 > Is this what you have in mind? Please let me know. If it is not, please co= rrect me. > =20 > Cheers, > =20 > Nat > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM) > Sent: Friday, February 19, 2016 2:09 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > =20 > How does the client request the oauth configuration assigned to xyz? > =20 > The example you give appears to presume a single oauth infrastructure for a= ll apps.=20 > =20 > The only way right now to have apps specific oauth is to infer the relatio= n by the domain "xyz.example.com". =20 > =20 > That makes discovery more complex because there arw many more discovery lo= cations and many more configurations to maintain.=20 > =20 > If example.com had separate oauth servers for services xyz and abc, how wo= uld discovery work from a single /.well-know endpoint? >=20 > Phil >=20 > On Feb 18, 2016, at 09:41, Mike Jones wrote:= >=20 > Let me second John=E2=80=99s point that OAuth configuration information an= d application configuration information need not be interspersed. For insta= nce, if the service is at https://example.com and the XYZ application is bei= ng used, then these configuration metadata documents could both be used: > =C2=B7 https://example.com/.well-known/openid-configuration - OAuth c= onfiguration metadata > =C2=B7 https://example.com/.well-known/xyz-configuration - XYZ confi= guration metadata > =20 > There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 val= ue, since there is no such thing as generic OAuth 2.0. By definition, it mu= st always be used in an application context that profiles OAuth 2.0 to enabl= e interoperability. The existing /.well-known/openid-configuration value wo= rks fine for this purpose. Yes, the optics of having a different value migh= t seem better but it comes at the cost of interoperability problems. In my v= iew, interop trumps optics. > =20 > To a point that George Fletcher made, WebFinger could still be used to lea= rn the locations of these configuration metadata documents if that makes sen= se in the application context. The editors took WebFinger out of the OAuth D= iscovery document since it isn=E2=80=99t always applicable. > =20 > Cheers, > -- Mike > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, February 18, 2016 7:41 AM > To: Phil Hunt > Cc: Mike Jones ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > =20 > I suspect that the configuration well-knowns are going to be on the root d= omain. You could try and get a user to put in crm.example.com, but I suspe= ct that is not going to work. > =20 > If the app doesn=E2=80=99t have a specific protocol identifier then it wou= ld use the default. =20 > =20 > I don=E2=80=99t know if you can get around having some sort of app/protoco= l identifier configured in the app. > =20 > John B. > =20 > =20 > =20 > =20 > =20 > =20 > On Feb 18, 2016, at 9:49 AM, Phil Hunt wrote: > =20 > resource service X could be any http accessible service: > =20 > * CRM > * Finance > * Payroll > * ERP > * any application on the web. > =20 > The spec seems to suggest that we use /.well-known/crm to discover OAuth c= onfig for crm. But that may cause conflict if crm has its own discovery. Wh= ich leads us down the path of doing something like =E2=80=9Ccrm-oauth=E2=80=9D= . > =20 > Then there is confusion about what host the discovery is done on. > =20 > For example, hypothetically do I do: > =20 > GET /.well-known/crm > Host: example.com > =20 > But what about the CRM=E2=80=99s configuration information. Is this stompi= ng on it? > =20 > Or, what If we put the oauth configuration at the host for the crm service= : > GET /.well-known/openid-configuration > Host: crm.example.com > =20 > I think the point is that there is a relationship between a protected reso= urce and its designated OAuth service.=20 > =20 > The client needs to discover: > * Where is its designated resource service and what security does it use > * If it is OAuth, where is the intended OAuth configuration for that resou= rce service instance? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 18, 2016, at 7:19 AM, John Bradley wrote: > =20 > Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? > =20 > Is that the RS base URI for the resource, a specific URI that the client i= s requesting? > =20 > That is getting UMA ish.=20 > =20 > The concept of a base RS URI is a rat hole that I prefer not to go down, a= s it is something everyone thinks exists but like SCIM if it exists it is pr= otocol or deployment specific. > =20 > The notion that you would send the URI you are planning on requesting to a= Webfinger server to find the OAuth server, is probably going to have privac= y issues. > =20 > I suspect that you need to hand back a error from the resource to say wher= e the AS is, or have a .well-known for the RS. > =20 > RS discovery probably wants to be separate from AS discovery. (Yes I do t= hink we need something, UMA rpt or something like it might be a way to go) > =20 > John B. > =20 > On Feb 18, 2016, at 9:06 AM, Phil Hunt wrote: > =20 > Maybe SCIM was a bad example. It functions as a RESTful resource in the c= ontext of OAuth. > =20 > I find the use of OIDC to be confusing as an example (and the default) bec= ause it is both an OAuth resource and a security service. It is a modificat= ion of OAuth. > =20 > Start thinking about every application ever written that uses OAuth. Are w= e expecting 100s of thousands of these to each register? > =20 > To me, this specification is a fine specification for OIDC and it should b= e published there because the specification defines how to discovery OAuth a= nd OpenID information. > =20 > Likewise you suggest it is ok for SCIM to do the same.=20 > =20 > How do we expect normal applications to set up and do discovery? > =20 > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should have a= parameter to ask, I want to discover OAuth configuration for resource servi= ce X. > =20 > That still allows me to have a separate discovery service that says, tell m= e about resource service X itself. > =20 > BTW. I think we are FAR from Last Call on this topic. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 18, 2016, at 6:55 AM, John Bradley wrote: > =20 > Diffrent protocols like Connect and SCIM may have different configurations= , endpoints , keys , authentication methods, scopes etc. > =20 > It should be posable to have them as one document, but forcing them to use= one document is going to cause a explosion of claim registration for discov= ery. > =20 > I think it is better for SCIM to register one well known than to have to r= egister 20 claims with scim prefixes or something silly like that. > =20 > Name-spacing the claims by allowing them to be in different well known fil= es is not unreasonable. > =20 > Remember some of these protocols may be hosted on SaaS so there is no guar= antee that all protocols will have the same OAuth Config. > =20 > Nothing stops a protocol from doing what it likes with webfinger if it wan= ts to use that for discovery. > =20 > In principal I like the idea of having another protocol as an example. > =20 > My only concern is that I haven=E2=80=99t seen any discussion of your SCIM= discovery document in the SCIM WG. =20 > I personally think sorting out discovery for SCIM is a good idea, but OAU= Th is but one of several authentication methods for SCIM, and there are prob= ably other non OAuth things that want to be described. > =20 > I would feel better about using it as an example if it were adopted by the= WG and some general interest shown. > =20 > I encourage you to do that so we can use it as a example. > =20 > John B. > =20 > On Feb 18, 2016, at 8:35 AM, Phil Hunt wrote: > =20 > I still find the following text objectionable and confusing=E2=80=A6 > By default, for historical reasons, unless an application-specific > well-known URI path suffix is registered and used for an application, > the client for that application SHOULD use the well-known URI path > suffix "openid-configuration" and publish the metadata document at > the path formed by concatenating "/.well-known/openid-configuration" > to the authorization server's issuer identifier. As described in > Section 5, despite the identifier > "/.well-known/openid-configuration", appearing to be OpenID-specific, > its usage in this specification is actually referring to a general > OAuth 2.0 feature that is not specific to OpenID Connect. > =20 > Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the defaul= t further gives people the impression that a plain OAuth server *is* an auth= entication server and that the normal access token received is evidence of a= successful authentication. > =20 > It would be better to point out that application may include oauth discove= ry in their discovery URI and that OAuth is an example of this. It might be g= ood to include two examples. E.g. OIDC and SCIM (as another referenceable e= xample). > =20 > GET /.well-known/openid-configuration > and > GET /.well-known/scim > Retrieve the OAuth configuration for the application openid and scim respe= ctively. > =20 > The use of: > GET /.well-known/oauth2/ > Should be the default used when there is no known application based well-k= nown application based URI discovery. > =20 > Of course, the concern I raised earlier is that this approach of applicati= on specific URIs ends up requiring every application to make an IANA registr= ation if they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80= =9D (or =E2=80=9Copenid-configuration=E2=80=9D). Is that what the authors e= xpect? > =20 > It seemed better to me to use the webfinger syntax to allow the client to s= ay =E2=80=9CI want the designated OAuth configuration for the resource servi= ce X=E2=80=9D would be a better design that avoids extensive IANA registrati= on. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 17, 2016, at 11:48 PM, Mike Jones wro= te: > =20 > In response to working group input, this version of the OAuth Discovery sp= ecification has been pared down to its essence =E2=80=93 leaving only the fe= atures that are already widely deployed. Specifically, all that remains is t= he definition of the authorization server discovery metadata document and th= e metadata values used in it. The WebFinger discovery logic has been remove= d. The relationship between the issuer identifier URL and the well-known UR= I path relative to it at which the discovery metadata document is located ha= s also been clarified. > =20 > Given that this now describes only features that are in widespread deploym= ent, the editors believe that this version is ready for working group last c= all. > =20 > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > =20 > An HTML-formatted version is also available at: > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-01.ht= ml > =20 > -- Mike & Nat & J= ohn > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1544 and= as @selfissued. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 > =20 > =20 --Apple-Mail-225333FC-B1C0-4405-90EE-E51F6DFEFE4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No. Much simpler. 

A service prov= ider has decided to have a separate oauth server for each web 'property'. Th= is could be because they were acquired separately and run different infrastr= uctures. Or the business structure keeps each BU completely separate. <= /div>

The client can't really depend on previously known or hard coded endpoints b= ecause there are 1000s of instances deployed (eg as in tenancies). 

Th= is dynamic discovery is going to be particularly true of open source softwar= e that customers choose to host on PaaS cloud providers of their choosing.&n= bsp;

Phil

On Feb 18, 2= 016, at 19:04, Nat Sakimura <n-sa= kimura@nri.co.jp> wrote:

=

Hi Phil,

 

Yo= u wrote:

> If example.com had sepa= rate oauth servers for services xyz and abc,

> how would discovery work from a single= /.well-known endpoint?

 

I am trying to understand your use case, but I am not su= re if I do.

 

The use case seems to be such that:

 

-        There is a client C1. It could be a CR= M or any kind of application that uses RFC6749 and RFC6750 to access other r= esources a resource server R1. C1 and R1 has a pre-configured relationship. <= o:p>

-      &nbs= p; The resourc= e server R1 supports RFC6750, and can have multiple OAuth RFC6749 endpoints t= hat it supports, which are A1, =E2=80=A6, An.

-        Ax supports multiple resource services, R= x.

There i= s a user U1 that wants to access C1, which in turn access R1. U1 gets authen= ticated somehow at C1. It could be either through a password system at C1, o= r through a federated login protocol supported at Ax, such as OpenID Connect= .

 

Another possibility is a case where Cx =3D= Rx, which makes things a bit simpler.

 

Is this what you have in mind? Please l= et me know. If it is not, please correct me.

 

Cheers,

 

Nat

<= p class=3D"MsoNormal">--

PLEASE READ :This e-mail is= confidential and intended for the

named re= cipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 =

From:= OAuth [= mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Friday, February 19, 2016 2:09 AM
To: Mike Jones
= Cc: oauth@ietf.org
Subject:<= /b> Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence=

&nbs= p;

How does= the client request the oauth configuration assigned to xyz?

 

=

The example you give appears to p= resume a single oauth infrastructure for all apps. 

 

The only way right now to have apps s= pecific oauth is to infer the relation by the domain "xyz.example.com".  

&nb= sp;

That makes discovery more complex because there arw= many more discovery locations and many more configurations to maintain.&nbs= p;

 

If example.com had separate oauth servers for services x= yz and abc, how would discovery work from a single /.well-know endpoint?


Phil


On Feb 18= , 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com> wrote:

Let me second John=E2=80=99s point tha= t OAuth configuration information and application configuration information n= eed not be interspersed.  For instance, if the service is at https://example.com and the XYZ application is bei= ng used, then these configuration metadata documents could both be used:

https://example.com/.well-known/openid-configuration - OAuth config= uration metadata

=C2=B7       https://example.com/.well-known/xyz-configuration= - XYZ configuration metadata<= /p>

 

There=E2=80=99s not much point in defining a new /.well-known/oau= th2.0 value, since there is no such thing as generic OAuth 2.0.  By def= inition, it must always be used in an application context that profiles OAut= h 2.0 to enable interoperability.  The existing /.well-known/openid-con= figuration value works fine for this purpose.  Yes, the optics of havin= g a different value might seem better but it comes at the cost of interopera= bility problems.  In my view, interop trumps optics.

 

To a point that George Fletcher made, W= ebFinger could still be used to learn the locations of these configuration m= etadata documents if that makes sense in the application context.  The e= ditors took WebFinger out of the OAuth Discovery document since it isn=E2=80= =99t always applicable.

 

            =             &nbs= p;            &n= bsp;            =         Cheers,

=             &nbs= p;            &n= bsp;            =             &nbs= p;       -- Mike

&nbs= p;

 

I suspect that the configuration well-knowns= are going to be on the root domain.   You could try and get a user to p= ut in crm.example.com, but I suspect t= hat is not going to work.

<= span lang=3D"EN-US"> 

If the app doesn=E2=80=99t have a specific protoc= ol identifier then it would use the default.  

 =

I don=E2=80=99t k= now if you can get around having some sort of app/protocol identifier config= ured in the app.

 

John B.

 

 

 

 

 

<= /div>

 

<= p class=3D"MsoNormal">On Feb 18, 2016, at 9:49 AM, Phil= Hunt <phil.hunt@oracle.com&g= t; wrote:

 

resource service X could be any http accessible service:

 

* CRM

*= Finance

* Payroll

* ERP

* any application on the web.

<= /div>

 

The spec seems t= o suggest that we use /.well-known/crm to discover OAuth config for crm. &nb= sp;But that may cause conflict if crm has its own discovery. Which leads us d= own the path of doing something like =E2=80=9Ccrm-oauth=E2=80=9D.=

 

The= n there is confusion about what host the discovery is done on.

 

For ex= ample, hypothetically do I do:

 

GET /.well-known/crm=

 

=

But what about the CRM=E2=80=99s= configuration information. Is this stomping on it?

 =

Or, what If we pu= t the oauth configuration at the host for the crm service:=

GET /.well-k= nown/openid-configuration

 

I think the point is that there is a relationship b= etween a protected resource and its designated OAuth service. 

 

T= he client needs to discover:

* Where is its designated resource service and w= hat security does it use

* If it is OAuth, where is the intended OAuth confi= guration for that resource service instance?

 

Phil

=  

@independentid

<= p class=3D"MsoNormal">www.independentid.com

phil.hunt@oracle.com

 

 

 

 

On Feb 1= 8, 2016, at 7:19 AM, John Bradley <v= e7jtb@ve7jtb.com> wrote:

 

Can you clarify what you mean by =E2=80=9Cr= esource service x=E2=80=9D?

 

Is that the RS base URI for the resource,  = ;a specific URI that the client is requesting?

 

<= /div>

That is getting UMA is= h. 

 

The concept of a base RS URI is a rat hole that I prefer not t= o go down, as it is something everyone thinks exists but like SCIM if it exi= sts it is protocol or deployment specific.

<= p class=3D"MsoNormal"> 

The notion that you would s= end the URI you are planning on requesting to a Webfinger server to find the= OAuth server, is probably going to have privacy issues.

 

I suspect th= at you need to hand back a error from the resource to say where the AS is, o= r have a .well-known for the RS.

 

RS discovery probably wants to be se= parate from AS discovery.  (Yes I do think we need something,  UMA= rpt or something like it might be a way to go)

<= div>

 

=

John B.

 

On Feb 18, 20= 16, at 9:06 AM, Phil Hunt <phil.h= unt@oracle.com> wrote:

 

Maybe SCIM was a bad example.  It functi= ons as a RESTful resource in the context of OAuth.

 

I find the use of OIDC t= o be confusing as an example (and the default) because it is both an OAuth r= esource and a security service.  It is a modification of OAuth.

 

Start t= hinking about every application ever written that uses OAuth. Are we expecti= ng 100s of thousands of these to each register?

<= div>

 

=

To me, this specifica= tion is a fine specification for OIDC and it should be published there becau= se the specification defines how to discovery OAuth and OpenID information.<= o:p>

=  

Likewise you suggest it is ok for SCIM to do the same. 

 

How do we expect normal applications to set up and do discovery?

 <= o:p>

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should h= ave a parameter to ask, I want to discover OAuth configuration for resource s= ervice X.

 

That still allows me to have a separate discovery service that= says, tell me about resource service X itself.

<= div>

 

=

BTW. I think we are FA= R from Last Call on this topic.

 

 =

On Feb 18, 2016, at 6:= 55 AM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:

 

Diffrent protocols like Connect and SCIM may have differe= nt configurations, endpoints , keys , authentication methods, scopes etc.

 

I= t should be posable to have them as one document, but forcing them to use on= e document is going to cause a explosion of claim registration for discovery= .

 

I think it is better for SCIM to register one well known than to hav= e to register 20 claims with scim prefixes or something silly like that.

&nb= sp;

Name-spacing the claims by allowing them to be in different well known f= iles is not unreasonable.

 

Remember some of these protocols may be hos= ted on SaaS so there is no guarantee that all protocols will have the same O= Auth Config.

 

<= span lang=3D"EN-US">Nothing stops a protocol from doing what it likes with w= ebfinger if it wants to use that for discovery.

<= div>

 

=

In principal I like t= he idea of having another protocol as an example.

 

My only concern is t= hat I haven=E2=80=99t seen any discussion of your SCIM discovery document in= the SCIM WG.  

= I personally think sorting out discovery for SCIM is a g= ood idea,  but OAUTh is but one of several authentication methods for S= CIM, and there are probably other non OAuth things that want to be described= .

 

I would feel better about using it as an example if it were adopted b= y the WG and some general interest shown.

 

=

I encourage you to do that s= o we can use it as a example.

 

John B.

 

On Feb 18, 2016, at 8:35 AM, Phil Hunt <= phil.hunt@oracle.com> wrote:<= o:p>

 = ;

I still find the following text objectionable and confusing=E2=80=A6

   By default, for historical reasons, unless an a=
pplication-specific
   well-known URI path suffix is regis=
tered and used for an application,
   the client for that a=
pplication SHOULD use the well-known URI path
   suffix "o=
penid-configuration" and publish the metadata document at<=
/pre>
 &nbs=
p; the path formed by concatenating "/.well-known/openid-configuration"=

   to the authorization server's issuer identifier.  As d=
escribed in
<=
span lang=3D"EN-US">   Section 5, despite the identifier
   "/.well-known/openid-configuration", appearing to be Open=
ID-specific,
=
   its usage in this specification is actuall=
y referring to a general
   OAuth 2.0 feature that is not s=
pecific to OpenID Connect.

 

Further, as a default =E2=80=9Copenid-co= nfiguration=E2=80=9D as the default further gives people the impression that= a plain OAuth server *is* an authentication server and that the normal acce= ss token received is evidence of a successful authentication.

 

It woul= d be better to point out that application may include oauth discovery in the= ir discovery URI and that OAuth is an example of this. It might be good to i= nclude two examples.  E.g. OIDC and SCIM (as another referenceable exam= ple).

 

 GET /.well-known/openid-configuration

and

 GET /.well-known/scim

Retrieve the OAuth configurati= on for the application openid and scim respectively.

 =

The use of= :

 GET /.well-known/oauth2/

Should be the default used when ther= e is no known application based well-known application based URI discovery.<= o:p>

 

Of course, the concern I raised earlier is that this approach o= f application specific URIs ends up requiring every application to make an I= ANA registration if they don=E2=80=99t want to use the default of =E2=80=9Co= auth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D).  Is that wh= at the authors expect?

 

It seemed better to me to use the webfinger sy= ntax to allow the client to say =E2=80=9CI want the designated OAuth configu= ration for the resource service X=E2=80=9D would be a better design that avo= ids extensive IANA registration.

 

 =

On Feb 17, 2016, at 11= :48 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

 

In response to working group input, this ver= sion of the OAuth Discovery specification has been pared down to its essence= =E2=80=93 leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization serve= r discovery metadata document and the metadata values used in it.  The W= ebFinger discovery logic has been removed.  The relationship between th= e issuer identifier URL and the well-known URI path relative to it at which t= he discovery metadata document is located has also been clarified.

 

<= div>

Given that this now describes only= features that are in widespread deployment, the editors believe that this v= ersion is ready for working group last call.

 

The specification is available at:

 

<= div>

An HTML-formatted version is also a= vailable at:

 <= span lang=3D"EN-US">

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

 

P.S.  This noti= ce was also posted at http= ://self-issued.info/?p=3D1544 and as @selfis= sued.

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

 

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

=

 

 

 

 

 

= = --Apple-Mail-225333FC-B1C0-4405-90EE-E51F6DFEFE4F-- From nobody Thu Feb 18 21:19:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AB01AD0D2 for ; Thu, 18 Feb 2016 21:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 OpRqwd3YIb8r for ; Thu, 18 Feb 2016 21:19:29 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42E61AD16B for ; Thu, 18 Feb 2016 21:19:28 -0800 (PST) Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs02.index.or.jp (Postfix) with SMTP id 1AD1D196878; Fri, 19 Feb 2016 14:19:28 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u1J5JRTp019910; Fri, 19 Feb 2016 14:19:27 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1J5JRWa050511; Fri, 19 Feb 2016 14:19:27 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u1J5JRiN050506; Fri, 19 Feb 2016 14:19:27 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1J5JRUT050503; Fri, 19 Feb 2016 14:19:27 +0900 From: "Nat Sakimura" To: "'Phil Hunt \(IDM\)'" References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> In-Reply-To: <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> Date: Fri, 19 Feb 2016 14:19:33 +0900 Message-ID: <023e01d16ad5$1defad00$59cf0700$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023F_01D16B20.8DDE80F0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGS4qFsTGL4fIzuwSUDfPQF/59lfwFfZWRKAXSIQK8DFjyYOQKDVIVZAUNy/HEBYalTWQDkn8zeAONwRlEB+5pRSQFnm5sxny3y5TA= Content-Language: ja x-mailadviser: 20141126 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:19:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023F_01D16B20.8DDE80F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the explanation. Let me re-formulate.=20 =20 Assumption 1. There are resource server =E2=80=93 authorization server pairs: = R1A1 =E2=80=A6 RnAn.=20 2. There are clients C1 =E2=80=A6 Cm.=20 3. These instances can be hosted on a multi-tenancy environment.=20 =20 Flow 1. Client Cx goes to a resource server Ry, but he was denied of the = access and was told to get an access token. Now Cx needs to know where = to go.=20 2. Cx uses << Discovery>> to find the OAuth endpoints and the = associated metadata on Ay that corresponds to Ry.=20 3. Cx goes and fetches the Discovery file.=20 4. Cx goes to Ay to get authorized using the config info in the = Discovery file and the rest is normal RFC6749.=20 =20 Is this correct?=20 =20 Nat =20 -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 Sent: Friday, February 19, 2016 1:58 PM To: Nat Sakimura Cc: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 No. Much simpler.=20 =20 A service provider has decided to have a separate oauth server for each = web 'property'. This could be because they were acquired separately and = run different infrastructures. Or the business structure keeps each BU = completely separate.=20 =20 The client can't really depend on previously known or hard coded = endpoints because there are 1000s of instances deployed (eg as in = tenancies).=20 =20 This dynamic discovery is going to be particularly true of open source = software that customers choose to host on PaaS cloud providers of their = choosing.=20 Phil On Feb 18, 2016, at 19:04, Nat Sakimura > wrote: Hi Phil,=20 =20 You wrote:=20 > If example.com had separate oauth servers for = services xyz and abc,=20 > how would discovery work from a single /.well-known endpoint? =20 I am trying to understand your use case, but I am not sure if I do.=20 =20 The use case seems to be such that:=20 =20 - There is a client C1. It could be a CRM or any kind of = application that uses RFC6749 and RFC6750 to access other resources a = resource server R1. C1 and R1 has a pre-configured relationship.=20 - The resource server R1 supports RFC6750, and can have multiple = OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An.=20 - Ax supports multiple resource services, Rx.=20 - There is a user U1 that wants to access C1, which in turn access = R1. U1 gets authenticated somehow at C1. It could be either through a = password system at C1, or through a federated login protocol supported = at Ax, such as OpenID Connect.=20 =20 Another possibility is a case where Cx =3D Rx, which makes things a bit = simpler.=20 =20 Is this what you have in mind? Please let me know. If it is not, please = correct me. =20 Cheers,=20 =20 Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM) Sent: Friday, February 19, 2016 2:09 AM To: Mike Jones Cc: oauth@ietf.org =20 Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 How does the client request the oauth configuration assigned to xyz? =20 The example you give appears to presume a single oauth infrastructure = for all apps.=20 =20 The only way right now to have apps specific oauth is to infer the = relation by the domain "xyz.example.com ". =20 =20 That makes discovery more complex because there arw many more discovery = locations and many more configurations to maintain.=20 =20 If example.com had separate oauth servers for = services xyz and abc, how would discovery work from a single /.well-know = endpoint? Phil On Feb 18, 2016, at 09:41, Mike Jones > wrote: Let me second John=E2=80=99s point that OAuth configuration information = and application configuration information need not be interspersed. For = instance, if the service is at https://example.com and the XYZ = application is being used, then these configuration metadata documents = could both be used: * https://example.com/.well-known/openid-configuration - OAuth = configuration metadata * https://example.com/.well-known/xyz-configuration - XYZ = configuration metadata =20 There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 = value, since there is no such thing as generic OAuth 2.0. By = definition, it must always be used in an application context that = profiles OAuth 2.0 to enable interoperability. The existing = /.well-known/openid-configuration value works fine for this purpose. = Yes, the optics of having a different value might seem better but it = comes at the cost of interoperability problems. In my view, interop = trumps optics. =20 To a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context. The editors took WebFinger out = of the OAuth Discovery document since it isn=E2=80=99t always = applicable. =20 Cheers, -- Mike =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Thursday, February 18, 2016 7:41 AM To: Phil Hunt > Cc: Mike Jones >; oauth@ietf.org = =20 Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence =20 I suspect that the configuration well-knowns are going to be on the root = domain. You could try and get a user to put in crm.example.com = , but I suspect that is not going to work. =20 If the app doesn=E2=80=99t have a specific protocol identifier then it = would use the default. =20 =20 I don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app. =20 John B. =20 =20 =20 =20 =20 =20 On Feb 18, 2016, at 9:49 AM, Phil Hunt > wrote: =20 resource service X could be any http accessible service: =20 * CRM * Finance * Payroll * ERP * any application on the web. =20 The spec seems to suggest that we use /.well-known/crm to discover OAuth = config for crm. But that may cause conflict if crm has its own = discovery. Which leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. =20 Then there is confusion about what host the discovery is done on. =20 For example, hypothetically do I do: =20 GET /.well-known/crm Host: example.com =20 =20 But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? =20 Or, what If we put the oauth configuration at the host for the crm = service: GET /.well-known/openid-configuration Host: crm.example.com =20 =20 I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 =20 The client needs to discover: * Where is its designated resource service and what security does it use * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 18, 2016, at 7:19 AM, John Bradley > wrote: =20 Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? =20 Is that the RS base URI for the resource, a specific URI that the = client is requesting? =20 That is getting UMA ish.=20 =20 The concept of a base RS URI is a rat hole that I prefer not to go down, = as it is something everyone thinks exists but like SCIM if it exists it = is protocol or deployment specific. =20 The notion that you would send the URI you are planning on requesting to = a Webfinger server to find the OAuth server, is probably going to have = privacy issues. =20 I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. =20 RS discovery probably wants to be separate from AS discovery. (Yes I do = think we need something, UMA rpt or something like it might be a way to = go) =20 John B. =20 On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: =20 Maybe SCIM was a bad example. It functions as a RESTful resource in the = context of OAuth. =20 I find the use of OIDC to be confusing as an example (and the default) = because it is both an OAuth resource and a security service. It is a = modification of OAuth. =20 Start thinking about every application ever written that uses OAuth. Are = we expecting 100s of thousands of these to each register? =20 To me, this specification is a fine specification for OIDC and it should = be published there because the specification defines how to discovery = OAuth and OpenID information. =20 Likewise you suggest it is ok for SCIM to do the same.=20 =20 How do we expect normal applications to set up and do discovery? =20 It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. =20 That still allows me to have a separate discovery service that says, = tell me about resource service X itself. =20 BTW. I think we are FAR from Last Call on this topic. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: =20 Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. =20 It should be posable to have them as one document, but forcing them to = use one document is going to cause a explosion of claim registration for = discovery. =20 I think it is better for SCIM to register one well known than to have to = register 20 claims with scim prefixes or something silly like that. =20 Name-spacing the claims by allowing them to be in different well known = files is not unreasonable. =20 Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. =20 Nothing stops a protocol from doing what it likes with webfinger if it = wants to use that for discovery. =20 In principal I like the idea of having another protocol as an example. =20 My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 I personally think sorting out discovery for SCIM is a good idea, but = OAUTh is but one of several authentication methods for SCIM, and there = are probably other non OAuth things that want to be described. =20 I would feel better about using it as an example if it were adopted by = the WG and some general interest shown. =20 I encourage you to do that so we can use it as a example. =20 John B. =20 On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: =20 I still find the following text objectionable and confusing=E2=80=A6 By default, for historical reasons, unless an application-specific well-known URI path suffix is registered and used for an application, the client for that application SHOULD use the well-known URI path suffix "openid-configuration" and publish the metadata document at the path formed by concatenating "/.well-known/openid-configuration" to the authorization server's issuer identifier. As described in Section 5 = , = despite the identifier "/.well-known/openid-configuration", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect. =20 Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. =20 It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). =20 GET /.well-known/openid-configuration and GET /.well-known/scim Retrieve the OAuth configuration for the application openid and scim = respectively. =20 The use of: GET /.well-known/oauth2/ Should be the default used when there is no known application based = well-known application based URI discovery. =20 Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? =20 It seemed better to me to use the webfinger syntax to allow the client = to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. =20 Phil =20 @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 =20 =20 =20 On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: =20 In response to working group input, this version of the OAuth Discovery = specification has been pared down to its essence =E2=80=93 leaving only = the features that are already widely deployed. Specifically, all that = remains is the definition of the authorization server discovery metadata = document and the metadata values used in it. The WebFinger discovery = logic has been removed. The relationship between the issuer identifier = URL and the well-known URI path relative to it at which the discovery = metadata document is located has also been clarified. =20 Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. =20 The specification is available at: * = http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 =20 An HTML-formatted version is also available at: * = = http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html =20 -- Mike & Nat = & John =20 P.S. This notice was also posted at = http://self-issued.info/?p=3D1544 = and as @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org = https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 =20 =20 =20 =20 ------=_NextPart_000_023F_01D16B20.8DDE80F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

T= hanks for the explanation. Let me re-formulate. =

<= o:p> 

A= ssumption

<= span style=3D'mso-list:Ignore'>1.     T= here are resource server =E2=80=93 authorization server pairs: R1A1 = =E2=80=A6 RnAn.

<= span style=3D'mso-list:Ignore'>2.     T= here are clients C1 =E2=80=A6 Cm.

<= span style=3D'mso-list:Ignore'>3.     T= hese instances can be hosted on a multi-tenancy environment. =

<= o:p> 

F= low

<= span style=3D'mso-list:Ignore'>1.     C= lient Cx goes to a resource server Ry, but he was denied of the access = and was told to get an access token. Now Cx needs to know where to go. =

<= span style=3D'mso-list:Ignore'>2.     C= x uses << Discovery>> to find the OAuth endpoints and the = associated metadata on Ay that corresponds to Ry. =

<= span style=3D'mso-list:Ignore'>3.     C= x goes and fetches the Discovery file.

<= span style=3D'mso-list:Ignore'>4.     C= x goes to Ay to get authorized using the config info in the Discovery = file and the rest is normal RFC6749.

<= o:p> 

I= s this correct?

<= o:p> 

N= at

<= o:p> 

--=

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> Phil Hunt = (IDM) [mailto:phil.hunt@oracle.com]
Sent: Friday, February = 19, 2016 1:58 PM
To: Nat Sakimura
Cc: Mike Jones; = oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec = pared down to its essence

 

No. Much = simpler. 

 

A = service provider has decided to have a separate oauth server for each = web 'property'. This could be because they were acquired separately and = run different infrastructures. Or the business structure keeps each BU = completely separate. 

 

The = client can't really depend on previously known or hard coded endpoints = because there are 1000s of instances deployed (eg as in = tenancies). 

 

This = dynamic discovery is going to be particularly true of open source = software that customers choose to host on PaaS cloud providers of their = choosing. 


Phil


On Feb 18, 2016, at 19:04, Nat Sakimura <n-sakimura@nri.co.jp> = wrote:

H= i Phil,

&= nbsp;

Y= ou wrote:

&= gt; If example.com had separate oauth servers = for services xyz and abc,

> how would discovery work from = a single /.well-known endpoint?

&= nbsp;

I= am trying to understand your use case, but I am not sure if I do. =

&= nbsp;

T= he use case seems to be such that:

&= nbsp;

-       = T= here is a client C1. It could be a CRM or any kind of application that = uses RFC6749 and RFC6750 to access other resources a resource server R1. = C1 and R1 has a pre-configured relationship.

-       = T= he resource server R1 supports RFC6750, and can have multiple OAuth = RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An. =

-       = A= x supports multiple resource services, Rx.

-       = T= here is a user U1 that wants to access C1, which in turn access R1. U1 = gets authenticated somehow at C1. It could be either through a password = system at C1, or through a federated login protocol supported at Ax, = such as OpenID Connect.

&= nbsp;

A= nother possibility is a case where Cx =3D Rx, which makes things a bit = simpler.

&= nbsp;

I= s this what you have in mind? Please let me know. If it is not, please = correct me.

&= nbsp;

C= heers,

&= nbsp;

N= at

--

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender  and delete this e-mail.

&= nbsp;

From:<= /b> OAuth [mailto:oauth-bounces@ietf.org]= On Behalf Of Phil Hunt (IDM)
Sent: Friday, February = 19, 2016 2:09 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] OAuth Discovery spec pared down to its essence

 

How does the client request the = oauth configuration assigned to xyz?

 

The = example you give appears to presume a single oauth infrastructure for = all apps. 

 

The only = way right now to have apps specific oauth is to infer the relation by = the domain "xyz.example.com". =  

 

That = makes discovery more complex because there arw many more discovery = locations and many more configurations to = maintain. 

 

If example.com had separate oauth servers = for services xyz and abc, how would discovery work from a single = /.well-know endpoint?


Phil


On Feb 18, 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com> wrote:

Let me second John=E2=80=99s point that OAuth configuration information = and application configuration information need not be = interspersed.  For instance, if the service is at https://example.com and the XYZ = application is being used, then these configuration metadata documents = could both be used:

=C2=B7       = https://exa= mple.com/.well-known/openid-configuration - OAuth configuration = metadata

=C2=B7       = https://exampl= e.com/.well-known/xyz-configuration - XYZ configuration = metadata

 

There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 = value, since there is no such thing as generic OAuth 2.0.  By = definition, it must always be used in an application context that = profiles OAuth 2.0 to enable interoperability.  The existing = /.well-known/openid-configuration value works fine for this = purpose.  Yes, the optics of having a different value might seem = better but it comes at the cost of interoperability problems.  In = my view, interop trumps optics.

 

To a point that George Fletcher made, WebFinger could still be used to = learn the locations of these configuration metadata documents if that = makes sense in the application context.  The editors took WebFinger = out of the OAuth Discovery document since it isn=E2=80=99t always = applicable.

 

            =             &= nbsp;           &n= bsp;           &nb= sp;         Cheers,

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

 

From:<= /b> John = Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil = Hunt <phil.hunt@oracle.com>
C= c: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: = [OAUTH-WG] OAuth Discovery spec pared down to its essence

 

I suspect that the configuration = well-knowns are going to be on the root domain.   You could try and = get a user to put in crm.example.com, but I suspect that = is not going to work.

 

If the app doesn=E2=80=99t have a = specific protocol identifier then it would use the default. =  

 

I don=E2=80=99t know if you can get = around having some sort of app/protocol identifier configured in the = app.

 

John = B.

 

 

 

 

 

 

On Feb 18, 2016, at 9:49 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

resource service X could be any = http accessible service:

 

* = CRM

* Finance

* = Payroll

* ERP

* any application on the = web.

 

The spec seems to suggest that we = use /.well-known/crm to discover OAuth config for crm.  But that = may cause conflict if crm has its own discovery. Which leads us down the = path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D.

 

Then there is confusion about what = host the discovery is done on.

 

For example, hypothetically do I = do:

 

GET = /.well-known/crm

<= div>

 

But what about the CRM=E2=80=99s = configuration information. Is this stomping on = it?

 

Or, what If we put the oauth = configuration at the host for the crm = service:

GET = /.well-known/openid-configuration

 

I think the point is that there is = a relationship between a protected resource and its designated OAuth = service. 

 

The client needs to = discover:

* Where is its designated resource service and what = security does it use

* If it is OAuth, where is the = intended OAuth configuration for that resource service = instance?

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 18, 2016, at 7:19 AM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Can you clarify what you mean by = =E2=80=9Cresource service x=E2=80=9D?

 

Is that the RS base URI for the = resource,  a specific URI that the client is = requesting?

 

That is getting UMA = ish. 

 

The concept of a base RS URI is a = rat hole that I prefer not to go down, as it is something everyone = thinks exists but like SCIM if it exists it is protocol or deployment = specific.

 

The notion that you would send the = URI you are planning on requesting to a Webfinger server to find the = OAuth server, is probably going to have privacy = issues.

 

I suspect that you need to hand = back a error from the resource to say where the AS is, or have a = .well-known for the RS.

 

RS discovery probably wants to be = separate from AS discovery.  (Yes I do think we need something, =  UMA rpt or something like it might be a way to = go)

 

John = B.

 

On Feb 18, 2016, at 9:06 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

Maybe SCIM was a bad example. =  It functions as a RESTful resource in the context of = OAuth.

 

I find the use of OIDC to be = confusing as an example (and the default) because it is both an OAuth = resource and a security service.  It is a modification of = OAuth.

 

Start thinking about every = application ever written that uses OAuth. Are we expecting 100s of = thousands of these to each register?

 

To me, this specification is a fine = specification for OIDC and it should be published there because the = specification defines how to discovery OAuth and OpenID = information.

 

Likewise you suggest it is ok for = SCIM to do the same. 

 

How do we expect normal = applications to set up and do = discovery?

 

It seems to me that an = =E2=80=9COAUTH=E2=80=9D discovery spec should have a parameter to ask, I = want to discover OAuth configuration for resource service = X.

 

That still allows me to have a = separate discovery service that says, tell me about resource service X = itself.

 

BTW. I think we are FAR from Last = Call on this topic.

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 18, 2016, at 6:55 AM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

 

Diffrent protocols like Connect and = SCIM may have different configurations, endpoints , keys , = authentication methods, scopes etc.

 

It should be posable to have them = as one document, but forcing them to use one document is going to cause = a explosion of claim registration for = discovery.

 

I think it is better for SCIM to = register one well known than to have to register 20 claims with scim = prefixes or something silly like = that.

 

Name-spacing the claims by allowing = them to be in different well known files is not = unreasonable.

 

Remember some of these protocols = may be hosted on SaaS so there is no guarantee that all protocols will = have the same OAuth Config.

 

Nothing stops a protocol from doing = what it likes with webfinger if it wants to use that for = discovery.

 

In principal I like the idea of = having another protocol as an = example.

 

My only concern is that I = haven=E2=80=99t seen any discussion of your SCIM discovery document in = the SCIM WG.  

I personally think sorting out = discovery for SCIM is a good idea,  but OAUTh is but one of several = authentication methods for SCIM, and there are probably other non OAuth = things that want to be described.

 

I would feel better about using it = as an example if it were adopted by the WG and some general interest = shown.

 

I encourage you to do that so we = can use it as a example.

 

John = B.

 

On Feb 18, 2016, at 8:35 AM, Phil = Hunt <phil.hunt@oracle.com> = wrote:

 

I still find the following text = objectionable and = confusing=E2=80=A6

   By =
default, for historical reasons, unless an =
application-specific
   =
well-known URI path suffix is registered and used for an =
application,
   the =
client for that application SHOULD use the well-known URI =
path
   =
suffix "openid-configuration" and publish the metadata =
document at
   the =
path formed by concatenating =
"/.well-known/openid-configuration"
   to = the authorization server's issuer identifier.  As described = in
   Section 5, despite the identifier
   =
"/.well-known/openid-configuration", appearing to be =
OpenID-specific,
   its =
usage in this specification is actually referring to a =
general
   OAuth =
2.0 feature that is not specific to OpenID =
Connect.

 

Further, as a default = =E2=80=9Copenid-configuration=E2=80=9D as the default further gives = people the impression that a plain OAuth server *is* an authentication = server and that the normal access token received is evidence of a = successful authentication.

 

It would be better to point out = that application may include oauth discovery in their discovery URI and = that OAuth is an example of this. It might be good to include two = examples.  E.g. OIDC and SCIM (as another referenceable = example).

 

 GET =
/.well-known/openid-configuration

and

 GET =
/.well-known/scim

Retrieve the OAuth configuration = for the application openid and scim = respectively.

 

The use = of:

 GET =
/.well-known/oauth2/

Should be the default used when = there is no known application based well-known application based URI = discovery.

 

Of course, the concern I raised = earlier is that this approach of application specific URIs ends up = requiring every application to make an IANA registration if they = don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or = =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors = expect?

 

It seemed better to me to use the = webfinger syntax to allow the client to say =E2=80=9CI want the = designated OAuth configuration for the resource service X=E2=80=9D would = be a better design that avoids extensive IANA = registration.

 

<= div>

Phil

 

@independentid

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

 

 

 

 

On Feb 17, 2016, at 11:48 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:

 

 =

An = HTML-formatted version is also available at:

 =

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

 =

P.S.  = This notice was also posted at http://self-issued.info/?p=3D1544 and as @selfissued.

____________= ___________________________________
OAuth mailing = list
OAuth@ietf.org
<= span lang=3DEN-US>https://www.ietf.org/mailman/listinfo/oauth

 

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

 

<= /div>

 

 

<= /div>

 

<= /div>

 

------=_NextPart_000_023F_01D16B20.8DDE80F0-- From nobody Thu Feb 18 21:58:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0181ACE48 for ; Thu, 18 Feb 2016 21:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmOq3LnVZx7Z for ; Thu, 18 Feb 2016 21:58:23 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CE01ACCEF for ; Thu, 18 Feb 2016 21:58:22 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1J5wLFS029704 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Feb 2016 05:58:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1J5wL75026611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 05:58:21 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1J5wKdl029362; Fri, 19 Feb 2016 05:58:20 GMT Received: from [10.5.50.218] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 21:57:59 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-32E6D37E-206B-4C31-9CC5-CC5605FD88A6 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <023e01d16ad5$1defad00$59cf0700$@nri.co.jp> Date: Thu, 18 Feb 2016 22:57:38 -0700 Content-Transfer-Encoding: 7bit Message-Id: <56F355AB-077D-4264-8417-051E10634128@oracle.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> <023e01d16ad5$1defad00$59cf0700$@nri.co.jp> To: Nat Sakimura X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:58:29 -0000 --Apple-Mail-32E6D37E-206B-4C31-9CC5-CC5605FD88A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Inline... Phil > On Feb 18, 2016, at 22:19, Nat Sakimura wrote: >=20 > Thanks for the explanation. Let me re-formulate. > =20 > Assumption > 1. There are resource server =E2=80=93 authorization server pairs: R1A= 1 =E2=80=A6 RnAn. > 2. There are clients C1 =E2=80=A6 Cm. > 3. These instances can be hosted on a multi-tenancy environment. > =20 > Flow Step 0. The client discovers the resource server endpoint and its configs.=20= Question: should that include oauth?? John seems to imply yes.=20 > 1. Client Cx goes to a resource server Ry, but he was denied of the ac= cess and was told to get an access token. Now Cx needs to know where to go. > 2. Cx uses << Discovery>> to find the OAuth endpoints and the associat= ed metadata on Ay that corresponds to Ry. Where is the discovery for Ay? > 3. Cx goes and fetches the Discovery file. > 4. Cx goes to Ay to get authorized using the config info in the Discov= ery file and the rest is normal RFC6749. Referring to the risk that a client discovered from a bad source (eg to inse= rt a fake token endpoint), how does Ay know what discovery the client used w= as correct? This might not be a problem in reality but it needs to work.=20= > =20 > Is this correct? > =20 > Nat > =20 > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > =20 > From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20 > Sent: Friday, February 19, 2016 1:58 PM > To: Nat Sakimura > Cc: Mike Jones; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > =20 > No. Much simpler.=20 > =20 > A service provider has decided to have a separate oauth server for each we= b 'property'. This could be because they were acquired separately and run di= fferent infrastructures. Or the business structure keeps each BU completely s= eparate.=20 > =20 > The client can't really depend on previously known or hard coded endpoints= because there are 1000s of instances deployed (eg as in tenancies).=20 > =20 > This dynamic discovery is going to be particularly true of open source sof= tware that customers choose to host on PaaS cloud providers of their choosin= g.=20 >=20 > Phil >=20 > On Feb 18, 2016, at 19:04, Nat Sakimura wrote: >=20 > Hi Phil, > =20 > You wrote: > > If example.com had separate oauth servers for services xyz and abc, > > how would discovery work from a single /.well-known endpoint? > =20 > I am trying to understand your use case, but I am not sure if I do. > =20 > The use case seems to be such that: > =20 > - There is a client C1. It could be a CRM or any kind of application= that uses RFC6749 and RFC6750 to access other resources a resource server R= 1. C1 and R1 has a pre-configured relationship. > - The resource server R1 supports RFC6750, and can have multiple OAu= th RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An. > - Ax supports multiple resource services, Rx. > - There is a user U1 that wants to access C1, which in turn access R= 1. U1 gets authenticated somehow at C1. It could be either through a passwor= d system at C1, or through a federated login protocol supported at Ax, such a= s OpenID Connect. > =20 > Another possibility is a case where Cx =3D Rx, which makes things a bit si= mpler. > =20 > Is this what you have in mind? Please let me know. If it is not, please co= rrect me. > =20 > Cheers, > =20 > Nat > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM) > Sent: Friday, February 19, 2016 2:09 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > =20 > How does the client request the oauth configuration assigned to xyz? > =20 > The example you give appears to presume a single oauth infrastructure for a= ll apps.=20 > =20 > The only way right now to have apps specific oauth is to infer the relatio= n by the domain "xyz.example.com". =20 > =20 > That makes discovery more complex because there arw many more discovery lo= cations and many more configurations to maintain.=20 > =20 > If example.com had separate oauth servers for services xyz and abc, how wo= uld discovery work from a single /.well-know endpoint? >=20 > Phil >=20 > On Feb 18, 2016, at 09:41, Mike Jones wrote:= >=20 > Let me second John=E2=80=99s point that OAuth configuration information an= d application configuration information need not be interspersed. For insta= nce, if the service is at https://example.com and the XYZ application is bei= ng used, then these configuration metadata documents could both be used: > =C2=B7 https://example.com/.well-known/openid-configuration - OAuth c= onfiguration metadata > =C2=B7 https://example.com/.well-known/xyz-configuration - XYZ confi= guration metadata > =20 > There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 val= ue, since there is no such thing as generic OAuth 2.0. By definition, it mu= st always be used in an application context that profiles OAuth 2.0 to enabl= e interoperability. The existing /.well-known/openid-configuration value wo= rks fine for this purpose. Yes, the optics of having a different value migh= t seem better but it comes at the cost of interoperability problems. In my v= iew, interop trumps optics. > =20 > To a point that George Fletcher made, WebFinger could still be used to lea= rn the locations of these configuration metadata documents if that makes sen= se in the application context. The editors took WebFinger out of the OAuth D= iscovery document since it isn=E2=80=99t always applicable. > =20 > Cheers, > -- Mike > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, February 18, 2016 7:41 AM > To: Phil Hunt > Cc: Mike Jones ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > =20 > I suspect that the configuration well-knowns are going to be on the root d= omain. You could try and get a user to put in crm.example.com, but I suspe= ct that is not going to work. > =20 > If the app doesn=E2=80=99t have a specific protocol identifier then it wou= ld use the default. =20 > =20 > I don=E2=80=99t know if you can get around having some sort of app/protoco= l identifier configured in the app. > =20 > John B. > =20 > =20 > =20 > =20 > =20 > =20 > On Feb 18, 2016, at 9:49 AM, Phil Hunt wrote: > =20 > resource service X could be any http accessible service: > =20 > * CRM > * Finance > * Payroll > * ERP > * any application on the web. > =20 > The spec seems to suggest that we use /.well-known/crm to discover OAuth c= onfig for crm. But that may cause conflict if crm has its own discovery. Wh= ich leads us down the path of doing something like =E2=80=9Ccrm-oauth=E2=80=9D= . > =20 > Then there is confusion about what host the discovery is done on. > =20 > For example, hypothetically do I do: > =20 > GET /.well-known/crm > Host: example.com > =20 > But what about the CRM=E2=80=99s configuration information. Is this stompi= ng on it? > =20 > Or, what If we put the oauth configuration at the host for the crm service= : > GET /.well-known/openid-configuration > Host: crm.example.com > =20 > I think the point is that there is a relationship between a protected reso= urce and its designated OAuth service.=20 > =20 > The client needs to discover: > * Where is its designated resource service and what security does it use > * If it is OAuth, where is the intended OAuth configuration for that resou= rce service instance? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 18, 2016, at 7:19 AM, John Bradley wrote: > =20 > Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? > =20 > Is that the RS base URI for the resource, a specific URI that the client i= s requesting? > =20 > That is getting UMA ish.=20 > =20 > The concept of a base RS URI is a rat hole that I prefer not to go down, a= s it is something everyone thinks exists but like SCIM if it exists it is pr= otocol or deployment specific. > =20 > The notion that you would send the URI you are planning on requesting to a= Webfinger server to find the OAuth server, is probably going to have privac= y issues. > =20 > I suspect that you need to hand back a error from the resource to say wher= e the AS is, or have a .well-known for the RS. > =20 > RS discovery probably wants to be separate from AS discovery. (Yes I do t= hink we need something, UMA rpt or something like it might be a way to go) > =20 > John B. > =20 > On Feb 18, 2016, at 9:06 AM, Phil Hunt wrote: > =20 > Maybe SCIM was a bad example. It functions as a RESTful resource in the c= ontext of OAuth. > =20 > I find the use of OIDC to be confusing as an example (and the default) bec= ause it is both an OAuth resource and a security service. It is a modificat= ion of OAuth. > =20 > Start thinking about every application ever written that uses OAuth. Are w= e expecting 100s of thousands of these to each register? > =20 > To me, this specification is a fine specification for OIDC and it should b= e published there because the specification defines how to discovery OAuth a= nd OpenID information. > =20 > Likewise you suggest it is ok for SCIM to do the same.=20 > =20 > How do we expect normal applications to set up and do discovery? > =20 > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should have a= parameter to ask, I want to discover OAuth configuration for resource servi= ce X. > =20 > That still allows me to have a separate discovery service that says, tell m= e about resource service X itself. > =20 > BTW. I think we are FAR from Last Call on this topic. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 18, 2016, at 6:55 AM, John Bradley wrote: > =20 > Diffrent protocols like Connect and SCIM may have different configurations= , endpoints , keys , authentication methods, scopes etc. > =20 > It should be posable to have them as one document, but forcing them to use= one document is going to cause a explosion of claim registration for discov= ery. > =20 > I think it is better for SCIM to register one well known than to have to r= egister 20 claims with scim prefixes or something silly like that. > =20 > Name-spacing the claims by allowing them to be in different well known fil= es is not unreasonable. > =20 > Remember some of these protocols may be hosted on SaaS so there is no guar= antee that all protocols will have the same OAuth Config. > =20 > Nothing stops a protocol from doing what it likes with webfinger if it wan= ts to use that for discovery. > =20 > In principal I like the idea of having another protocol as an example. > =20 > My only concern is that I haven=E2=80=99t seen any discussion of your SCIM= discovery document in the SCIM WG.=20 > I personally think sorting out discovery for SCIM is a good idea, but OAU= Th is but one of several authentication methods for SCIM, and there are prob= ably other non OAuth things that want to be described. > =20 > I would feel better about using it as an example if it were adopted by the= WG and some general interest shown. > =20 > I encourage you to do that so we can use it as a example. > =20 > John B. > =20 > On Feb 18, 2016, at 8:35 AM, Phil Hunt wrote: > =20 > I still find the following text objectionable and confusing=E2=80=A6 > By default, for historical reasons, unless an application-specific > well-known URI path suffix is registered and used for an application, > the client for that application SHOULD use the well-known URI path > suffix "openid-configuration" and publish the metadata document at > the path formed by concatenating "/.well-known/openid-configuration" > to the authorization server's issuer identifier. As described in > Section 5, despite the identifier > "/.well-known/openid-configuration", appearing to be OpenID-specific, > its usage in this specification is actually referring to a general > OAuth 2.0 feature that is not specific to OpenID Connect. > =20 > Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the defaul= t further gives people the impression that a plain OAuth server *is* an auth= entication server and that the normal access token received is evidence of a= successful authentication. > =20 > It would be better to point out that application may include oauth discove= ry in their discovery URI and that OAuth is an example of this. It might be g= ood to include two examples. E.g. OIDC and SCIM (as another referenceable e= xample). > =20 > GET /.well-known/openid-configuration > and > GET /.well-known/scim > Retrieve the OAuth configuration for the application openid and scim respe= ctively. > =20 > The use of: > GET /.well-known/oauth2/ > Should be the default used when there is no known application based well-k= nown application based URI discovery. > =20 > Of course, the concern I raised earlier is that this approach of applicati= on specific URIs ends up requiring every application to make an IANA registr= ation if they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80= =9D (or =E2=80=9Copenid-configuration=E2=80=9D). Is that what the authors e= xpect? > =20 > It seemed better to me to use the webfinger syntax to allow the client to s= ay =E2=80=9CI want the designated OAuth configuration for the resource servi= ce X=E2=80=9D would be a better design that avoids extensive IANA registrati= on. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > =20 > =20 >=20 > =20 > On Feb 17, 2016, at 11:48 PM, Mike Jones wro= te: > =20 > In response to working group input, this version of the OAuth Discovery sp= ecification has been pared down to its essence =E2=80=93 leaving only the fe= atures that are already widely deployed. Specifically, all that remains is t= he definition of the authorization server discovery metadata document and th= e metadata values used in it. The WebFinger discovery logic has been remove= d. The relationship between the issuer identifier URL and the well-known UR= I path relative to it at which the discovery metadata document is located ha= s also been clarified. > =20 > Given that this now describes only features that are in widespread deploym= ent, the editors believe that this version is ready for working group last c= all. > =20 > The specification is available at: > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > =20 > An HTML-formatted version is also available at: > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-01.ht= ml > =20 > -- Mike & Nat & J= ohn > =20 > P.S. This notice was also posted at http://self-issued.info/?p=3D1544 and= as @selfissued. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > =20 > =20 > =20 --Apple-Mail-32E6D37E-206B-4C31-9CC5-CC5605FD88A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Inline...

Phil

On= Feb 18, 2016, at 22:19, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

Thanks for t= he explanation. Let me re-formulate.

 

Assumption


1.     There are resource server =E2=80=93 authorization serv= er pairs: R1A1 =E2=80=A6 RnAn.

2. &= nbsp;   There are clients C1 =E2=80=A6 Cm.

3.&= nbsp;    These instances can be hosted on a multi-tenancy environment.

&nb= sp;

Flow

Step 0. The client discovers the resource server endpoint an= d its configs. 
Question: should that include oauth?? John seems to imply yes.=  

1.     Client Cx goes to a resource server Ry, but he was d= enied of the access and was told to get an access token. Now Cx needs to kno= w where to go.

2.    = ; Cx uses <= < Discovery>> to find the OAuth endpoints and the associated metada= ta on Ay that corresponds to Ry.

Where i= s the discovery for Ay?

<= /span>

3.     Cx goes and fetches the Discovery file.=

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial",= sans-serif;color:#1F497D">4.     Cx goes to Ay to get autho= rized using the config info in the Discovery file and the rest is normal RFC= 6749.


Referring to the ri= sk that a client discovered from a bad source (eg to insert a fake token end= point), how does Ay know what discovery the client used was correct?  T= his might not be a problem in reality but it needs to work. 

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial",= sans-serif;color:#1F497D"> 

Is this correct?

 

Nat

 

--

PLEASE READ :This e-mail is confi= dential and intended for the

named recipien= t only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 <= /span>

From: Phil Hunt (IDM) [m= ailto:phil.hunt@oracle.com]
Sent: Friday, February 19, 2016 1= :58 PM
To: Nat Sakimura
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth= Discovery spec pared down to its essence

<= p class=3D"MsoNormal"> 

=

No. Much simpler. 

 

A service provider has de= cided to have a separate oauth server for each web 'property'. This could be= because they were acquired separately and run different infrastructures. Or= the business structure keeps each BU completely separate. <= /span>

 

The client can't really depen= d on previously known or hard coded endpoints because there are 1000s of ins= tances deployed (eg as in tenancies). 

&n= bsp;

This dynamic discovery is going to be particularly= true of open source software that customers choose to host on PaaS cloud pr= oviders of their choosing. 


Phil


On Feb 18, 2016, at 19:04, Nat Sakimura <n-sakimura@nri.co.jp> wrote:<= /o:p>

Hi Phil, =

 

You wrote:

> If examp= le.com had separate oauth servers for services xyz and abc, <= /span>

> how would discove= ry work from a single /.well-known endpoint?

 

I am tr= ying to understand your use case, but I am not sure if I do.

 

The use case seems to be such that: <= /span>

 <= /p>

-  &n= bsp;    There is a client C1. It could be a CRM or any kind of application t= hat uses RFC6749 and RFC6750 to access other resources a resource server R1.= C1 and R1 has a pre-configured relationship.

-       = The resource server R1 supports RFC6750, and can h= ave multiple OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6= , An.

-      = Ax supports m= ultiple resource services, Rx.

-  = ;     There is a user U1 that wants to access C1, which in turn access= R1. U1 gets authenticated somehow at C1. It could be either through a passw= ord system at C1, or through a federated login protocol supported at Ax, suc= h as OpenID Connect.

 

Another possibility is a case where Cx =3D= Rx, which makes things a bit simpler.

 =

Is this what you have in mind? Please let me know. If it is= not, please correct me.

 

Cheers,

 

Nat

--

PLEASE READ :This e-mail is co= nfidential and intended for the

named recipient only. If you are not an intended recipient= ,

please notify t= he sender  and delete this e-mail.

 <= /span>

From: OAuth [mailto:oauth-bounces@ietf.org] On Beh= alf Of Phil Hunt (IDM)
Sent: Friday, February 19, 2016 2:09 AM=
To: Mike Jones
Cc: oa= uth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pare= d down to its essence

 <= /p>

How does the client requ= est the oauth configuration assigned to xyz?

 = ;

The example you give appears to presume a single= oauth infrastructure for all apps. 

 

The only way right now to have apps specific oauth i= s to infer the relation by the domain "xy= z.example.com".  

 

That makes discovery more complex because there arw many more discov= ery locations and many more configurations to maintain. 

 

If example.com had separate oauth servers for services xyz and abc, how w= ould discovery work from a single /.well-know endpoint?


Phil


On Feb 18, 2016, at 09:41, M= ike Jones <Michael.Jones@m= icrosoft.com> wrote:

Let me second John=E2=80=99s point that OAuth configurati= on information and application configuration information need not be intersp= ersed.  For instance, if the service is at https://example.com and the XYZ application is being used, then thes= e configuration metadata documents could both be used:

=C2=B7    =    = https://exa= mple.com/.well-known/openid-configuration - OAuth configuration metadata=

=C2=B7&n= bsp;      https://example.com/.well-known/xyz-configuration - XYZ configur= ation metadata

 

Ther= e=E2=80=99s not much point in defining a new /.well-known/oauth2.0 value, si= nce there is no such thing as generic OAuth 2.0.  By definition, it mus= t always be used in an application context that profiles OAuth 2.0 to enable= interoperability.  The existing /.well-known/openid-configuration valu= e works fine for this purpose.  Yes, the optics of having a different v= alue might seem better but it comes at the cost of interoperability problems= .  In my view, interop trumps optics.<= /o:p>

 

To a point that George Fletcher made, WebFinger coul= d still be used to learn the locations of these configuration metadata docum= ents if that makes sense in the application context.  The editors took W= ebFinger out of the OAuth Discovery document since it isn=E2=80=99t always a= pplicable.

 <= /o:p>

 &n= bsp;            =             &nbs= p;            &n= bsp;            =       Cheers,

  =             &nbs= p;            &n= bsp;            =             &nbs= p;     -- Mike

 

= From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thur= sday, February 18, 2016 7:41 AM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike Jone= s <Michael.Jones@microsoft= .com>; oauth@ietf.org
Sub= ject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

 

= I suspect that the configuration well-knowns are going t= o be on the root domain.   You could try and get a user to put in crm.example.com, but I suspect that is not= going to work.

 

If the app doesn=E2=80=99t have a specific protocol identifier= then it would use the default.  

 

I don=E2=80=99t know if you ca= n get around having some sort of app/protocol identifier configured in the a= pp.

 

John B.

 

<= span lang=3D"EN-US"> 

=  

 

 

 

On Feb 18, 2016, at 9:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=

 

res= ource service X could be any http accessible service:

<= div>

 

=

* CRM

* Finance<= /o:p>

* Pay= roll

* ERP

* any application on the web.

 

The spec seems to suggest tha= t we use /.well-known/crm to discover OAuth config for crm.  But that m= ay cause conflict if crm has its own discovery. Which leads us down the path= of doing something like =E2=80=9Ccrm-oauth=E2=80=9D.

<= /div>

 

Then there is c= onfusion about what host the discovery is done on.

 <= /p>

For example, hypot= hetically do I do:

 

GET /.well-known/crm

Host: example.com

 

But what about the CRM=E2=80=99s configurati= on information. Is this stomping on it?

 

Or, what If we put the oauth c= onfiguration at the host for the crm service:

GET /.well-known/openid-c= onfiguration

 

I think the point is that there is a relationship between a prot= ected resource and its designated OAuth service. 

=

 

The client nee= ds to discover:

* Where is its designated resource service and what security= does it use

* If it is OAuth, where is the intended OAuth configuration for= that resource service instance?

 

 =

On Feb 18, 2016, at 7:= 19 AM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:

 

Can you clarify what you mean by =E2=80=9Cresource servic= e x=E2=80=9D?

 

Is that the RS base URI for the resource,  a specific URI= that the client is requesting?

 

That is getting UMA ish. 

 =

The concept of a base RS URI is a rat hole that I prefer not to go down, as= it is something everyone thinks exists but like SCIM if it exists it is pro= tocol or deployment specific.

 

The notion that you would send the URI y= ou are planning on requesting to a Webfinger server to find the OAuth server= , is probably going to have privacy issues.

=

 

I suspect that you need t= o hand back a error from the resource to say where the AS is, or have a .wel= l-known for the RS.

<= span lang=3D"EN-US"> 

RS discovery probably wants to be separate from A= S discovery.  (Yes I do think we need something,  UMA rpt or somet= hing like it might be a way to go)

 

John B.

<= div>

 

=
<= div>

On Feb 18, 2016, at 9:06 AM,= Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:

 

Maybe SCIM was a bad example.  It functions as a RESTful r= esource in the context of OAuth.

I find the use of OIDC to be confusing as a= n example (and the default) because it is both an OAuth resource and a secur= ity service.  It is a modification of OAuth.

=

 

Start thinking about ever= y application ever written that uses OAuth. Are we expecting 100s of thousan= ds of these to each register?

 

To me, this specification is a fine spe= cification for OIDC and it should be published there because the specificati= on defines how to discovery OAuth and OpenID information.<= /p>

 <= /span>

Likewise yo= u suggest it is ok for SCIM to do the same. 

 

How do we expe= ct normal applications to set up and do discovery?

 <= /p>

It seems to m= e that an =E2=80=9COAUTH=E2=80=9D discovery spec should have a parameter to a= sk, I want to discover OAuth configuration for resource service X.

 

Th= at still allows me to have a separate discovery service that says, tell me a= bout resource service X itself.

 

BTW. I think we are FAR from Last Cal= l on this topic.

 

 <= /p>

On Feb 18, 2016, at 6:55 AM, John Br= adley <ve7jtb@ve7jtb.com> wro= te:

&= nbsp;

Diffrent protocols like Connect and SCIM may have different configurati= ons, endpoints , keys , authentication methods, scopes etc.

 

It should be po= sable to have them as one document, but forcing them to use one document is g= oing to cause a explosion of claim registration for discovery.

 

I thin= k it is better for SCIM to register one well known than to have to register 2= 0 claims with scim prefixes or something silly like that.<= /p>

 <= /span>

Name-spacin= g the claims by allowing them to be in different well known files is not unr= easonable.

 

Remember some of these protocols may be hosted on SaaS so t= here is no guarantee that all protocols will have the same OAuth Config.

&nb= sp;

Nothing stops a protocol from doing what it likes with webfinger if it w= ants to use that for discovery.

 

In principal I like the idea of havin= g another protocol as an example.

 

My only concern is that I haven=E2=80= =99t seen any discussion of your SCIM discovery document in the SCIM WG. &nb= sp;

I personally think sorting out discovery for SCIM is a good idea,  = but OAUTh is but one of several authentication methods for SCIM, and there a= re probably other non OAuth things that want to be described.

 

I would= feel better about using it as an example if it were adopted by the WG and s= ome general interest shown.

 

I encourage you to do that so we can use it= as a example.

 

= John B.

 

On Feb 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

I still f= ind the following text objectionable and confusing=E2=80=A6

   By default, for historical reasons, unless an application-spec=
ific
   well-known URI path suffix is registered and used f=
or an application,
   the client for that application SHOU=
LD use the well-known URI path
   suffix "openid-configura=
tion" and publish the metadata document at
   the path for=
med by concatenating "/.well-known/openid-configuration"
  =
; to the authorization server's issuer identifier.  As described in
   Section 5, despite the identifier=

 &nb=
sp; "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a=
 general
   OAuth 2.0 feature that is not specific to Open=
ID Connect.

 

= Further, as a default =E2=80=9Copenid-configuration=E2=80= =9D as the default further gives people the impression that a plain OAuth se= rver *is* an authentication server and that the normal access token received= is evidence of a successful authentication.

 

It would be better to po= int out that application may include oauth discovery in their discovery URI a= nd that OAuth is an example of this. It might be good to include two example= s.  E.g. OIDC and SCIM (as another referenceable example).

 <= /o:p>

 GET /.well-known/openid-configuration

and

 G=
ET /.well-known/scim

Retrieve the OAuth configuration for the applica= tion openid and scim respectively.

 

The use of:= 

=
 GET /.well-known/oauth2/

Should be the default used when there is no known appl= ication based well-known application based URI discovery.<= /p>

 <= /o:p>

Of co= urse, the concern I raised earlier is that this approach of application spec= ific URIs ends up requiring every application to make an IANA registration i= f they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D (or= =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the authors exp= ect?

 

It seemed better to me to use the webfinger syntax to allow the c= lient to say =E2=80=9CI want the designated OAuth configuration for the reso= urce service X=E2=80=9D would be a better design that avoids extensive IANA r= egistration.

 

Phil<= /span>

 =

@ind= ependentid

phil.hunt@oracle.com=

 

 

 

 

On Feb 17, 2016, at 11:48 PM, Mike Jones &l= t;Michael.Jones@microsoft.com= > wrote:

 

In response to working group input, this version of the OAuth Dis= covery specification has been pared down to its essence =E2=80=93 leaving on= ly the features that are already widely deployed.  Specifically, all th= at remains is the definition of the authorization server discovery metadata d= ocument and the metadata values used in it.  The WebFinger discovery lo= gic has been removed.  The relationship between the issuer identifier U= RL and the well-known URI path relative to it at which the discovery metadat= a document is located has also been clarified.

 <= /span>

Given that this now describes only features that are i= n widespread deployment, the editors believe that this version is ready for w= orking group last call.

 

T= he specification is available at:

 

An HTML-formatted version is also available at:<= span lang=3D"EN-US">

 <= o:p>

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

 

P.S.  This notice was also posted a= t http://self-issued.info/= ?p=3D1544 and a= s @selfissued.

<= span lang=3D"EN-US" style=3D"font-size:9.0pt;font-family:"Helvetica&quo= t;,sans-serif">_______________________________________________
OAuth mail= ing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

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

 

 =

 

 

 

= --Apple-Mail-32E6D37E-206B-4C31-9CC5-CC5605FD88A6-- From nobody Thu Feb 18 22:30:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59E71B2B0C for ; Thu, 18 Feb 2016 22:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue9NyN8OKrFo for ; Thu, 18 Feb 2016 22:30:37 -0800 (PST) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175F81B2B01 for ; Thu, 18 Feb 2016 22:30:37 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id y9so55840204qgd.3 for ; Thu, 18 Feb 2016 22:30:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=X6Fzkr5Ty11aOPNTkxGNCCDUsiweOB1X5WOzPHH+Z2U=; b=cJG0bIe7SEy1ICvKALha3gx1nUDK4ZGwkHk9kBWcLJcJWcz5MS3ZptVQ5dpNYklarh cO3ndB3QuAks7fbgsPigsxJzKluvkE2Q3TUFt7QHM2831JKKS5nsLLxHh4UwTYbLc6ft 3kFTWyg9cDA02kvbfNnMP5aFeLNMqNedSHxsJJmfA2iB/i0tIaRgTN18kji1VmI4/AXH ZjhOLVji3ha4gZ+E4rkjeheXeDBLPsprK8KPSfLpuS66aBX9l6zgGjedphVGs83XhM+d tXn/Hbe9YUxkfIwcarE/rnPcLU26jyOhJntZtAfxAIzFGGJE9DmpzD0WIisLrsWBlmYf YTHg== X-Gm-Message-State: AG10YOS9/0yi9PppkRKTtMkDvWm0bTxmTHscNlSMU86sa7/H+mHXb93K5t12XuePM3FeCiOalr1KuUrPShGLpg== X-Received: by 10.140.18.136 with SMTP id 8mr13625298qgf.64.1455863436062; Thu, 18 Feb 2016 22:30:36 -0800 (PST) MIME-Version: 1.0 References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> <023e01d16ad5$1defad00$59cf0700$@nri.co.jp> <56F355AB-077D-4264-8417-051E10634128@oracle.com> In-Reply-To: <56F355AB-077D-4264-8417-051E10634128@oracle.com> From: Nat Sakimura Date: Fri, 19 Feb 2016 06:30:25 +0000 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a11354642f2b8b8052c199efd Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 06:30:44 -0000 --001a11354642f2b8b8052c199efd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2016=E5=B9=B42=E6=9C=8819=E6=97=A5(=E9=87=91) 14:58 Phil Hunt (IDM) : > Inline... > > Phil > > On Feb 18, 2016, at 22:19, Nat Sakimura wrote: > > Thanks for the explanation. Let me re-formulate. > > > > Assumption > > > 1. There are resource server =E2=80=93 authorization server pairs: R1= A1 =E2=80=A6 > RnAn. > > 2. There are clients C1 =E2=80=A6 Cm. > > 3. These instances can be hosted on a multi-tenancy environment. > > > > Flow > > Step 0. The client discovers the resource server endpoint and its configs= . > Sure, but that's out of scope, is it not? If I am not mistaken, we are talking about OAuth server configuration discovery. I do agree that resource discovery in itself is a very interesting and important work which I would love to work on, but that is not what we are talking about here, I think. > Question: should that include oauth?? John seems to imply yes. > I do not think so. I think he was referring to the configuration of Ay that corresponds to Ry. John? > 1. Client Cx goes to a resource server Ry, but he was denied of the > access and was told to get an access token. Now Cx needs to know where to > go. > > 2. Cx uses << Discovery>> to find the OAuth endpoints and the > associated metadata on Ay that corresponds to Ry. > > Where is the discovery for Ay? > I was just trying to understand your use case. I have not put any solution into it. That's why I marked discovery as <>. The default one that the draft suggest is the https://authority (uri(Ay))/.well-known/openid-configuration. What John is suggesting is that we could also have https://authority(uri(Ay))/.well-known/oauth-config-for-Ry, if I read his message correctly. > 3. Cx goes and fetches the Discovery file. > > 4. Cx goes to Ay to get authorized using the config info in the > Discovery file and the rest is normal RFC6749. > > > Referring to the risk that a client discovered from a bad source (eg to > insert a fake token endpoint), how does Ay know what discovery the client > used was correct? This might not be a problem in reality but it needs to > work. > > Right. We are currently asking the clients to be sane enough to get the configuration for the server directly over https at the authorization server, more or less. When Ay gets an authorization request, it has no way of knowing that the client got the config from the right endpoint. Are you suggesting something like have the client send the signature of the config file that it is using now? > > > Is this correct? > > > > Nat > > > > -- > > PLEASE READ :This e-mail is confidential and intended for the > > named recipient only. If you are not an intended recipient, > > please notify the sender and delete this e-mail. > > > > *From:* Phil Hunt (IDM) [mailto:phil.hunt@oracle.com > ] > *Sent:* Friday, February 19, 2016 1:58 PM > *To:* Nat Sakimura > *Cc:* Mike Jones; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > No. Much simpler. > > > > A service provider has decided to have a separate oauth server for each > web 'property'. This could be because they were acquired separately and r= un > different infrastructures. Or the business structure keeps each BU > completely separate. > > > > The client can't really depend on previously known or hard coded endpoint= s > because there are 1000s of instances deployed (eg as in tenancies). > > > > This dynamic discovery is going to be particularly true of open source > software that customers choose to host on PaaS cloud providers of their > choosing. > > > Phil > > > On Feb 18, 2016, at 19:04, Nat Sakimura wrote: > > Hi Phil, > > > > You wrote: > > > If example.com had separate oauth servers for services xyz and abc, > > > how would discovery work from a single /.well-known endpoint? > > > > I am trying to understand your use case, but I am not sure if I do. > > > > The use case seems to be such that: > > > > - There is a client C1. It could be a CRM or any kind of > application that uses RFC6749 and RFC6750 to access other resources a > resource server R1. C1 and R1 has a pre-configured relationship. > > - The resource server R1 supports RFC6750, and can have multiple > OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6, An. > > - Ax supports multiple resource services, Rx. > > - There is a user U1 that wants to access C1, which in turn access > R1. U1 gets authenticated somehow at C1. It could be either through a > password system at C1, or through a federated login protocol supported at > Ax, such as OpenID Connect. > > > > Another possibility is a case where Cx =3D Rx, which makes things a bit > simpler. > > > > Is this what you have in mind? Please let me know. If it is not, please > correct me. > > > > Cheers, > > > > Nat > > -- > > PLEASE READ :This e-mail is confidential and intended for the > > named recipient only. If you are not an intended recipient, > > please notify the sender and delete this e-mail. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Phil Hunt (IDM) > *Sent:* Friday, February 19, 2016 2:09 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > How does the client request the oauth configuration assigned to xyz? > > > > The example you give appears to presume a single oauth infrastructure for > all apps. > > > > The only way right now to have apps specific oauth is to infer the > relation by the domain "xyz.example.com". > > > > That makes discovery more complex because there arw many more discovery > locations and many more configurations to maintain. > > > > If example.com had separate oauth servers for services xyz and abc, how > would discovery work from a single /.well-know endpoint? > > > Phil > > > On Feb 18, 2016, at 09:41, Mike Jones wrote= : > > Let me second John=E2=80=99s point that OAuth configuration information a= nd > application configuration information need not be interspersed. For > instance, if the service is at https://example.com and the XYZ > application is being used, then these configuration metadata documents > could both be used: > > =C2=B7 https://example.com/.well-known/openid-configuration - OAuth > configuration metadata > > =C2=B7 https://example.com/.well-known/xyz-configuration - XYZ > configuration metadata > > > > There=E2=80=99s not much point in defining a new /.well-known/oauth2.0 va= lue, > since there is no such thing as generic OAuth 2.0. By definition, it mus= t > always be used in an application context that profiles OAuth 2.0 to enabl= e > interoperability. The existing /.well-known/openid-configuration value > works fine for this purpose. Yes, the optics of having a different value > might seem better but it comes at the cost of interoperability problems. > In my view, interop trumps optics. > > > > To a point that George Fletcher made, WebFinger could still be used to > learn the locations of these configuration metadata documents if that mak= es > sense in the application context. The editors took WebFinger out of the > OAuth Discovery document since it isn=E2=80=99t always applicable. > > > > Cheers, > > -- Mike > > > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com ] > *Sent:* Thursday, February 18, 2016 7:41 AM > *To:* Phil Hunt > *Cc:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence > > > > I suspect that the configuration well-knowns are going to be on the root > domain. You could try and get a user to put in crm.example.com, but I > suspect that is not going to work. > > > > If the app doesn=E2=80=99t have a specific protocol identifier then it wo= uld use > the default. > > > > I don=E2=80=99t know if you can get around having some sort of app/protoc= ol > identifier configured in the app. > > > > John B. > > > > > > > > > > > > > > On Feb 18, 2016, at 9:49 AM, Phil Hunt wrote: > > > > resource service X could be any http accessible service: > > > > * CRM > > * Finance > > * Payroll > > * ERP > > * any application on the web. > > > > The spec seems to suggest that we use /.well-known/crm to discover OAuth > config for crm. But that may cause conflict if crm has its own discovery= . > Which leads us down the path of doing something like =E2=80=9Ccrm-oauth= =E2=80=9D. > > > > Then there is confusion about what host the discovery is done on. > > > > For example, hypothetically do I do: > > > > GET /.well-known/crm > > Host: example.com > > > > But what about the CRM=E2=80=99s configuration information. Is this stomp= ing on it? > > > > Or, what If we put the oauth configuration at the host for the crm servic= e: > > GET /.well-known/openid-configuration > > Host: crm.example.com > > > > I think the point is that there is a relationship between a protected > resource and its designated OAuth service. > > > > The client needs to discover: > > * Where is its designated resource service and what security does it use > > * If it is OAuth, where is the intended OAuth configuration for that > resource service instance? > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Feb 18, 2016, at 7:19 AM, John Bradley wrote: > > > > Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? > > > > Is that the RS base URI for the resource, a specific URI that the client > is requesting? > > > > That is getting UMA ish. > > > > The concept of a base RS URI is a rat hole that I prefer not to go down, > as it is something everyone thinks exists but like SCIM if it exists it i= s > protocol or deployment specific. > > > > The notion that you would send the URI you are planning on requesting to = a > Webfinger server to find the OAuth server, is probably going to have > privacy issues. > > > > I suspect that you need to hand back a error from the resource to say > where the AS is, or have a .well-known for the RS. > > > > RS discovery probably wants to be separate from AS discovery. (Yes I do > think we need something, UMA rpt or something like it might be a way to = go) > > > > John B. > > > > On Feb 18, 2016, at 9:06 AM, Phil Hunt wrote: > > > > Maybe SCIM was a bad example. It functions as a RESTful resource in the > context of OAuth. > > > > I find the use of OIDC to be confusing as an example (and the default) > because it is both an OAuth resource and a security service. It is a > modification of OAuth. > > > > Start thinking about every application ever written that uses OAuth. Are > we expecting 100s of thousands of these to each register? > > > > To me, this specification is a fine specification for OIDC and it should > be published there because the specification defines how to discovery OAu= th > and OpenID information. > > > > Likewise you suggest it is ok for SCIM to do the same. > > > > How do we expect normal applications to set up and do discovery? > > > > It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should have= a parameter to > ask, I want to discover OAuth configuration for resource service X. > > > > That still allows me to have a separate discovery service that says, tell > me about resource service X itself. > > > > BTW. I think we are FAR from Last Call on this topic. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Feb 18, 2016, at 6:55 AM, John Bradley wrote: > > > > Diffrent protocols like Connect and SCIM may have different > configurations, endpoints , keys , authentication methods, scopes etc. > > > > It should be posable to have them as one document, but forcing them to us= e > one document is going to cause a explosion of claim registration for > discovery. > > > > I think it is better for SCIM to register one well known than to have to > register 20 claims with scim prefixes or something silly like that. > > > > Name-spacing the claims by allowing them to be in different well known > files is not unreasonable. > > > > Remember some of these protocols may be hosted on SaaS so there is no > guarantee that all protocols will have the same OAuth Config. > > > > Nothing stops a protocol from doing what it likes with webfinger if it > wants to use that for discovery. > > > > In principal I like the idea of having another protocol as an example. > > > > My only concern is that I haven=E2=80=99t seen any discussion of your SCI= M > discovery document in the SCIM WG. > > I personally think sorting out discovery for SCIM is a good idea, but > OAUTh is but one of several authentication methods for SCIM, and there ar= e > probably other non OAuth things that want to be described. > > > > I would feel better about using it as an example if it were adopted by th= e > WG and some general interest shown. > > > > I encourage you to do that so we can use it as a example. > > > > John B. > > > > On Feb 18, 2016, at 8:35 AM, Phil Hunt wrote: > > > > I still find the following text objectionable and confusing=E2=80=A6 > > By default, for historical reasons, unless an application-specific > > well-known URI path suffix is registered and used for an application, > > the client for that application SHOULD use the well-known URI path > > suffix "openid-configuration" and publish the metadata document at > > the path formed by concatenating "/.well-known/openid-configuration" > > to the authorization server's issuer identifier. As described in > > Section 5 , despite the identifier > > "/.well-known/openid-configuration", appearing to be OpenID-specific, > > its usage in this specification is actually referring to a general > > OAuth 2.0 feature that is not specific to OpenID Connect. > > > > Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the defau= lt further gives > people the impression that a plain OAuth server *is* an authentication > server and that the normal access token received is evidence of a > successful authentication. > > > > It would be better to point out that application may include oauth > discovery in their discovery URI and that OAuth is an example of this. It > might be good to include two examples. E.g. OIDC and SCIM (as another > referenceable example). > > > > GET /.well-known/openid-configuration > > and > > GET /.well-known/scim > > Retrieve the OAuth configuration for the application openid and scim > respectively. > > > > The use of: > > GET /.well-known/oauth2/ > > Should be the default used when there is no known application based > well-known application based URI discovery. > > > > Of course, the concern I raised earlier is that this approach of > application specific URIs ends up requiring every application to make an > IANA registration if they don=E2=80=99t want to use the default of =E2=80= =9Coauth2=E2=80=9D (or > =E2=80=9Copenid-configuration=E2=80=9D). Is that what the authors expect= ? > > > > It seemed better to me to use the webfinger syntax to allow the client to > say =E2=80=9CI want the designated OAuth configuration for the resource s= ervice X=E2=80=9D > would be a better design that avoids extensive IANA registration. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > > > On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: > > > > In response to working group input, this version of the OAuth Discovery > specification has been pared down to its essence =E2=80=93 leaving only t= he > features that are already widely deployed. Specifically, all that remain= s > is the definition of the authorization server discovery metadata document > and the metadata values used in it. The WebFinger discovery logic has be= en > removed. The relationship between the issuer identifier URL and the > well-known URI path relative to it at which the discovery metadata docume= nt > is located has also been clarified. > > > > Given that this now describes only features that are in widespread > deployment, the editors believe that this version is ready for working > group last call. > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 > > > > An HTML-formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-discovery-01.h= tml > > > > -- Mike & Nat & > John > > > > P.S. This notice was also posted at http://self-issued.info/?p=3D1544 an= d > as @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11354642f2b8b8052c199efd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2016= =E5=B9=B42=E6=9C=8819=E6=97=A5(=E9=87=91) 14:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
Inline...

Phil

On Feb 18, 2016, at 22:19, Nat Sakimura= <n-sakimura@n= ri.co.jp> wrote:


1.=C2=A0=C2=A0=C2=A0=C2=A0 = There are resource server =E2=80=93 authorizati= on server pairs: R1A1 =E2=80=A6 RnAn.

2.=C2=A0=C2=A0=C2=A0=C2=A0 = There are clients C1 =E2=80=A6 Cm.

3.=C2=A0= =C2=A0=C2=A0=C2=A0 These i= nstances can be hosted on a multi-tenancy environment.

=C2=A0

Flow<= /p>

Step 0. The client discovers the = resource server endpoint and its configs.=C2=A0

Sure, but that's out of scope, is it not? If I = am not mistaken, we are talking about OAuth server configuration discovery.= I do agree that resource discovery in itself is a very interesting and imp= ortant work which I would love to work on, but that is not what we are talk= ing about here, I think. =C2=A0
=C2=A0
Question: should that include oauth?? John seems to imply y= es.=C2=A0

I do not= think so. I think he was referring to the configuration of Ay that corresp= onds to Ry. John? =C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0 Client Cx goes to a resource server Ry, but he was denied= of the access and was told to get an access token. Now Cx needs to know wh= ere to go.

2.=C2=A0=C2=A0=C2=A0=C2=A0 Cx uses << Discovery>> to find the OAuth endpoints and = the associated metadata on Ay that corresponds to Ry.

Where is the discovery fo= r Ay?
I was just trying to understand your use= case. I have not put any solution into it. That's why I marked discove= ry as <<Discovery>>. =C2=A0

The defaul= t one that the draft suggest is the https://a= uthority(uri(Ay))/.well-known/openid-configuration.=C2=A0
Wha= t John is suggesting is that we could also have https://authority(uri(Ay))/.wel= l-known/oauth-config-for-Ry, if I read his message correctly.=C2=A0


=

3.=C2=A0=C2=A0=C2=A0=C2=A0 Cx goes and fetches the Discovery file.

4= .=C2=A0=C2=A0=C2=A0= =C2=A0 Cx goes to Ay to ge= t authorized using the config info in the Discovery file and the rest is no= rmal RFC6749.


Referring to the risk that a client discovered fro= m a bad source (eg to insert a fake token endpoint), how does Ay know what = discovery the client used was correct?=C2=A0 This might not be a problem in= reality but it needs to work.=C2=A0

=
Right. We are currently asking the clients to= be sane enough to get the configuration for the server directly over https= at the authorization server, more or less. When Ay gets an authorization r= equest, it has no way of knowing that the client got the config from the ri= ght endpoint. Are you suggesting something like have the client send the si= gnature of the config file that it is using now?=C2=A0
=

<= /span>

=C2=A0<= u>

Is this= correct?

=C2=A0

Nat

=C2=A0

--<= /u>

PLEASE READ :This e-mail is confidential and intended for= the

named recipient only. If you are not an in= tended recipient,

please notify the sender=C2= =A0 and delete this e-mail.

=C2=A0

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
Sent: Friday, February 19, = 2016 1:58 PM
To: Nat Sakimura
Cc: Mike Jones; oauth@ietf.org
Subje= ct: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

= =C2=A0

No. Much simpler.=C2=A0

=C2=A0

=

A service provider has decided = to have a separate oauth server for each web 'property'. This could= be because they were acquired separately and run different infrastructures= . Or the business structure keeps each BU completely separate.=C2=A0=

=C2=A0

The client can't really depend on previously known or hard c= oded endpoints because there are 1000s of instances deployed (eg as in tena= ncies).=C2=A0

=C2=A0

This dynamic discovery is going to be particul= arly true of open source software that customers choose to host on PaaS clo= ud providers of their choosing.=C2=A0


Phil

=


On Feb 18, 2016, at 19:04, Nat Sakimura <n-sakimura@nri.co.jp> wrot= e:

Hi= Phil,

=C2=A0

You = wrote:

> If example.com had separate = oauth servers for services xyz and abc,

> how would discovery work from a si= ngle /.well-known endpoint?

= =C2=A0

I am trying = to understand your use case, but I am not sure if I do.

=C2=A0

The use case seems to be suc= h that:

=C2=A0<= /u>

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>There is a client C1. It co= uld be a CRM or any kind of application that uses RFC6749 and RFC6750 to ac= cess other resources a resource server R1. C1 and R1 has a pre-configured r= elationship.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The resource server R1 supports RFC6750, and can have mu= ltiple OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6, A= n.

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ax supports multiple resource services, Rx.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 There is a user = U1 that wants to access C1, which in turn access R1. U1 gets authenticated = somehow at C1. It could be either through a password system at C1, or throu= gh a federated login protocol supported at Ax, such as OpenID Connect.

=C2=A0=

Anothe= r possibility is a case where Cx =3D Rx, which makes things a bit simpler. =

=C2=A0

Is this wha= t you have in mind? Please let me know. If it is not, please correct me.

=C2=A0<= /span>

Cheers,

=C2=A0

Nat

--

PLEASE READ :This e-mail is confidential an= d intended for the

= named recipient only. If you are not an intended recipient,

please notify the sender=C2=A0 and= delete this e-mail.

=C2=A0

=C2=A0

How does the client request the oauth configuration a= ssigned to xyz?

<= span lang=3D"EN-US">=C2=A0

The example you give appears to presume a si= ngle oauth infrastructure for all apps.=C2=A0

=C2=A0

The only way r= ight now to have apps specific oauth is to infer the relation by the domain= "xyz.example.com= ". =C2=A0

=C2=A0

That makes discovery more complex becau= se there arw many more discovery locations and many more configurations to = maintain.=C2=A0

<= span lang=3D"EN-US">=C2=A0

If example.com had separate oauth servers for services xyz and abc= , how would discovery work from a single /.well-know endpoint?


Phil=


On Feb 18, 2016, at 09:41, Mike Jon= es <Mic= hael.Jones@microsoft.com> wrote:

Let me second John=E2=80=99s point tha= t OAuth configuration information and application configuration information= need not be interspersed.=C2=A0 For instance, if the service is at https://example.com and the = XYZ application is being used, then these configuration metadata documents = could both be used:

= =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 https://e= xample.com/.well-known/openid-configuration - OAuth configuration metad= ata

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://example.com/.well-known= /xyz-configuration - XYZ configuration metadata

=C2=A0

There=E2=80=99s not much point= in defining a new /.well-known/oauth2.0 value, since there is no such thin= g as generic OAuth 2.0.=C2=A0 By definition, it must always be used in an a= pplication context that profiles OAuth 2.0 to enable interoperability.=C2= =A0 The existing /.well-known/openid-configuration value works fine for thi= s purpose.=C2=A0 Yes, the optics of having a different value might seem bet= ter but it comes at the cost of interoperability problems.=C2=A0 In my view= , interop trumps optics.

=C2=A0

To a point that George Fletcher made, WebFinger could stil= l be used to learn the locations of these configuration metadata documents = if that makes sense in the application context.=C2=A0 The editors took WebF= inger out of the OAuth Discovery document since it isn=E2=80=99t always app= licable.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cheers,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

<= div>

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, February 18= , 2016 7:41 AM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike J= ones <M= ichael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Dis= covery spec pared down to its essence=

=C2= =A0

I s= uspect that the configuration well-knowns are going to be on the root domai= n. =C2=A0 You could try and get a user to put in crm.example.com, but I suspect that is not g= oing to work.

=C2=A0

If the app doesn=E2=80=99t have a specific protocol = identifier then it would use the default. =C2=A0

=C2=A0

I don=E2=80= =99t know if you can get around having some sort of app/protocol identifier= configured in the app.

=C2=A0

John B.

=C2=A0

=C2=A0

=C2=A0<= u>

=C2= =A0

=C2=A0

=C2=A0

On Feb 18, 2016, at 9:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:<= u>

= =C2=A0

resource service X could be any http accessible service:<= u>

=C2=A0=

* CRM

* Finance

* Payroll

* ERP

* any application on the = web.

=C2=A0

The spec seems to suggest that we use /.well-known/cr= m to discover OAuth config for crm.=C2=A0 But that may cause conflict if cr= m has its own discovery. Which leads us down the path of doing something li= ke =E2=80=9Ccrm-oauth=E2=80=9D.

=C2=A0

Then there is confusion abou= t what host the discovery is done on.

=C2=A0

For example, hypotheti= cally do I do:

=C2=A0

GET /.well-known/crm

=

=C2=A0

But what= about the CRM=E2=80=99s configuration information. Is this stomping on it?=

=C2=A0

Or, what If we put the oauth configuration at the host for = the crm service:

GET /.well-known/openid-configuration

Host: <= a href=3D"http://crm.example.com/" target=3D"_blank">crm.example.com=

=C2=A0

I think the point is that there is a relationship betwee= n a protected resource and its designated OAuth service.=C2=A0

=C2=A0

The client needs to discover:

* Where is its designated resource ser= vice and what security does it use

* If it is OAuth, where is the inten= ded OAuth configuration for that resource service instance?

=C2=A0

Phil

=

=C2=A0

@independentid<= u>

phil.hunt@oracle.com

=

=C2=A0

=

=C2=A0

=C2=A0

=C2=A0

On Feb 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com> wrote= :

=C2=A0

Can you clarify what you mean by =E2=80=9Cresource service x=E2= =80=9D?

=C2=A0

Is that the RS base URI for the resource, =C2=A0a specific= URI that the client is requesting?

=C2=A0

That is getting UMA ish.= =C2=A0

=C2=A0

The concept of a base RS URI is a rat hole that I pre= fer not to go down, as it is something everyone thinks exists but like SCIM= if it exists it is protocol or deployment specific.

=C2=A0

The not= ion that you would send the URI you are planning on requesting to a Webfing= er server to find the OAuth server, is probably going to have privacy issue= s.

=C2=A0

I suspect that you need to hand back a error from the res= ource to say where the AS is, or have a .well-known for the RS.

=C2=A0<= u>

RS discovery probably wants to be separate from AS discovery. =C2=A0(Ye= s I do think we need something, =C2=A0UMA rpt or something like it might be= a way to go)

=C2=A0

John B.

=C2=A0

On Feb 18, 2016, at 9:06 AM, = Phil Hunt <phi= l.hunt@oracle.com> wrote:

=C2=A0

Maybe SCIM was a bad example.=C2= =A0 It functions as a RESTful resource in the context of OAuth.

=C2=A0=

I = find the use of OIDC to be confusing as an example (and the default) becaus= e it is both an OAuth resource and a security service.=C2=A0 It is a modifi= cation of OAuth.

=C2=A0

Start thinking about every application ever writt= en that uses OAuth. Are we expecting 100s of thousands of these to each reg= ister?

=C2=A0

To me, this specification is a fine specification for= OIDC and it should be published there because the specification defines ho= w to discovery OAuth and OpenID information.

=

=C2=A0

Likewise you su= ggest it is ok for SCIM to do the same.=C2=A0

=C2=A0

How do we= expect normal applications to set up and do discovery?

=C2=A0

It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should have= a parameter to ask, I want to discover OAuth configuration for resource se= rvice X.

=C2=A0

That still allows me to have a separate discovery s= ervice that says, tell me about resource service X itself.

=C2=A0

B= TW. I think we are FAR from Last Call on this topic.

=C2=A0

Phil

=C2=A0

@independentid<= u>

phil.hunt@oracle.com

=C2=A0

<= /div>

=C2=A0

=C2=A0

=C2=A0

On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

=C2=A0=

Diffrent protocols like Connect and SCIM may have different configurati= ons, endpoints , keys , authentication methods, scopes etc.

=C2=A0<= /u>

It sho= uld be posable to have them as one document, but forcing them to use one do= cument is going to cause a explosion of claim registration for discovery.

=C2=A0

I think it is better for SCIM to register one well known than= to have to register 20 claims with scim prefixes or something silly like t= hat.

=C2=A0

Name-spacing the claims by allowing them to be in dif= ferent well known files is not unreasonable.

=

=C2=A0

Remember some o= f these protocols may be hosted on SaaS so there is no guarantee that all p= rotocols will have the same OAuth Config.

=C2=A0

Nothing stops a pr= otocol from doing what it likes with webfinger if it wants to use that for = discovery.

=C2=A0

In principal I like the idea of having another pr= otocol as an example.

=C2=A0

My only concern is that I haven=E2=80= =99t seen any discussion of your SCIM discovery document in the SCIM WG. = =C2=A0

I personally think sorting out discovery for SCIM is a good idea= , =C2=A0but OAUTh is but one of several authentication methods for SCIM, an= d there are probably other non OAuth things that want to be described.

= =C2=A0

I would feel better about using it as an example if it were adop= ted by the WG and some general interest shown.

=C2=A0

I encourage y= ou to do that so we can use it as a example.

=

=C2=A0

John B.<= u>

=C2= =A0

On Feb 18= , 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

=C2=A0

I still = find the following text objectionable and confusing=E2=80=A6<= /span>

=C2=A0=C2=A0 By default, for=
 historical reasons, unless an application-specific
=C2=A0=C2=A0 well-known URI path suffix is reg=
istered and used for an application,
=C2=A0=C2=A0 the client for that application SHOULD use the w=
ell-known URI path
=C2=
=A0=C2=A0 suffix "openid-configuration" and publish the metadata =
document at
=C2=A0=C2=
=A0 the path formed by concatenating "/.well-known/openid-configuratio=
n"
=C2=A0=C2=A0 to=
 the authorization server's issuer identifier.=C2=A0 As described in=

=C2=A0=C2=A0 Section 5, despite the identifier
=C2=A0=C2=A0 "/.well-known/openid-configura=
tion", appearing to be OpenID-specific,
=C2=A0=C2=A0 its usage in this specification is actua=
lly referring to a general
=C2=A0=C2=A0 OAuth 2.0 feature that is not specific to OpenID Connect.<=
u>

=C2=A0

Further, as a default =E2=80=9Copenid-configuration=E2=80= =9D as the default further gives people the impression that a plain OAuth s= erver *is* an authentication server and that the normal access token receiv= ed is evidence of a successful authentication.

=C2=A0

It would be b= etter to point out that application may include oauth discovery in their di= scovery URI and that OAuth is an example of this. It might be good to inclu= de two examples.=C2=A0 E.g. OIDC and SCIM (as another referenceable example= ).

=C2=A0

=
 GET /.well-known/openid-configuration

and

 GET /.well-known/scim

Retrie= ve the OAuth configuration for the application openid and scim respectively= .

=C2=A0

The use of:

=
 GET /.well-known/oauth2/

Should be the default used w= hen there is no known application based well-known application based URI di= scovery.

=C2=A0

Of course, the concern I raised earlier is th= at this approach of application specific URIs ends up requiring every appli= cation to make an IANA registration if they don=E2=80=99t want to use the d= efault of =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80= =9D).=C2=A0 Is that what the authors expect?

=

=C2=A0

It seemed bette= r to me to use the webfinger syntax to allow the client to say =E2=80=9CI w= ant the designated OAuth configuration for the resource service X=E2=80=9D = would be a better design that avoids extensive IANA registration.=

=C2= =A0

<= div>

Phil

=C2=A0

@indepe= ndentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

=C2=A0

In response to working group input, this v= ersion of the OAuth Discovery specification has been pared down to its esse= nce =E2=80=93 leaving only the features that are already widely deployed.= =C2=A0 Specifically, all that remains is the definition of the authorizatio= n server discovery metadata document and the metadata values used in it.=C2= =A0 The WebFinger discovery logic has been removed.=C2=A0 The relationship = between the issuer identifier URL and the well-known URI path relative to i= t at which the discovery metadata document is located has also been clarifi= ed.

=C2=A0=

Given that= this now describes only features that are in widespread deployment, the ed= itors believe that this version is ready for working group last call.

=C2=A0

The specification i= s available at:

<= div style=3D"margin-left:36.0pt">

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0http://tools.ietf.org/html/draft-ietf-oauth-discovery-01

=C2=A0

An HTML-formatted= version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0http://self-issued.info/docs/draft-ietf-oauth-dis= covery-01.html<= /p>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike & Nat &a= mp; John

=C2=A0

P.S.= =C2=A0 This notice was also posted at=C2=A0= http://self-issued.info/?p=3D1544=C2=A0and as= =C2=A0<= span style=3D"color:#954f72">@selfissued.

_______________________________________________
OAuth mailing list
<= /span>OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth

=C2=A0

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

=C2=A0

=

= =C2=A0

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

<= /div>

=C2=A0

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11354642f2b8b8052c199efd-- From nobody Fri Feb 19 02:12:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29411B2BC5 for ; Fri, 19 Feb 2016 02:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXe6GjGiVQ_v for ; Fri, 19 Feb 2016 02:12:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDEB1B2B3C for ; Fri, 19 Feb 2016 02:12:50 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LfYqz-1aD1UP1wSH-00p2oJ for ; Fri, 19 Feb 2016 11:12:48 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56C6EAAA.50009@gmx.net> Date: Fri, 19 Feb 2016 11:12:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="biTHJCH0vUK1GQm8jQkUtw7d9EA4nExOi" X-Provags-ID: V03:K0:Zd5dfy2OavRrsXR8zNBiRmWhKuHhGhUe/1RJTgJf/EF1fcYF6JT dS0l0SWvWMAJ+blJ4sBhOFH4YQiAC3um30MUcQ7x0+JR1QF+ymyJsjkwHhWPq8J0rfHXnWm IDAubtgzZchPFU4oqw5vt3fyVO4PA5xAb2kR/CZGyvXQRMFA4khz3UxNuQSHiCqnu8qns60 pejJYc7u0qjpK0Nt64fXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:n2VGVgAXuL4=:ekCnMxDRgSkeCTQKVAQUBs NVM/OwdBtM6RE+EqEPOZCCXkc+O3hy9AOArYJmWsgu6QGtDiOeH8Y9FlC1cSnvDHGtyOGI0Ox JsNBcJMrvarrx61oGaTMAF5BGroM152cmcmYwEbFxcV5mfhLu0tg3IOSql/FNj5UCfLxZypwD O8MwzTcytn7Wqeg6KMdZD27qAEnGvag/VvKenyWfQ/p6aQI1/9J8O/aBKoAPreOIJR519/oNw en4GhsyBBiYurwUiJTdSeaHuxHisdBPdheHqeBltdan8fkfTB8our0CHvdEl+niTv+bfitZQs oq/DDKBSD0W0/NRwznKAwSyB3bwKKAfPEUIn6/drRXogyGyA6v/eduhiyHE74k9jWdK2MMAYM pxSy+ym0zrCpR+So9dzbJriqQl6n6kz3nYYCb9zE/ek6rUtRwvXuy0N+kyPchMlRglx/pkx76 v+O5Doluv51RReaa6c82venjugxopWd9y0/tWf5zTUC1KD1SoXyeLgbydh9vvwPBI0S1kJJrm 7Pn953rvaxW6wnacsSX8Zm5rvIulTVYzXby0x550x1T2gJZLcvtZJMskBLvR2epy0D776tuvq aeXrAcwT0yORhPL1obtWgcEq48aTALXAhT7VOI8Q+0f9n8opIPMstCPI/r/UYgWpVW6sxX5AV lbpr2pqvsiYs1mHeKLJyP0nFRWcbHNlz0+6h1CxkVPVOz52psVJ2C/0cNXCr7NB6EFIuwokMF nNX+zAmRoggvTditAU2DmzfGKitbRDopD3sUy3ao2Uhitgvlk3Z2DUTajnQ= Archived-At: Subject: [OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 10:12:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --biTHJCH0vUK1GQm8jQkUtw7d9EA4nExOi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, early this year we announced our plans to organize an OAuth security workshop. In the meanwhile we have made progress in the planning activities and we are happy to announce that the workshop will take place July 14th and 15th 2016 in Trier/Germany. The date fits nicely with the IETF meeting in Berlin and our host, the Chair for Information Security and Cryptography at the University of Trier, may be familiar to some of you in context of the formal security analysis of OAuth also published earlier this year. More information can be found here: https://infsec.uni-trier.de/events/osw2016 With this workshop we particularly encourage researchers and other security experts to analyse OAuth and OAuth extensions and to report their findings at this workshop. Please note the position paper deadline, which is May 21st. We are looking forward to your contributions and to the discussions at the workshop! Feel free to contact us if there are questions. Ciao Hannes & Derek --biTHJCH0vUK1GQm8jQkUtw7d9EA4nExOi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWxuqrAAoJEGhJURNOOiAtR2kIAJMVoOGxJlPk4nJlGkT6GiJ6 Q6++F3WDL3g+N+Jcq23gpSxhqOVCucwcqjaXe62H0CfVwu2wX5fCNzsOgcLcWiSt p2iG9IfrimxnW4X67iSsWwGwU1pJjpRb3SyzPqwnQH21AGrfVgUOKz6vpK0WU4EQ IDYTLjBj84qh4KPLaW51BIAWT0NNF8ej/J+X4wuejWwbxafoW7n2N9XVbs8ptGE5 VAKtRmHrbcrwM/ENBRLBCDPEtAyObQNwu0ifq5M/hNsObw3hBqdVmOOA08iCXNWz Q8SUYf7ZRx7E6FY9toBwg0OV1XhtW0Heh/Qho+fn2GcYbUGaMJWU1F+zYR2dAUY= =0/2j -----END PGP SIGNATURE----- --biTHJCH0vUK1GQm8jQkUtw7d9EA4nExOi-- From nobody Fri Feb 19 06:39:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A141B2CFD for ; Fri, 19 Feb 2016 06:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5M1Dg1wkPB1 for ; Fri, 19 Feb 2016 06:39:41 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937F91B2D30 for ; Fri, 19 Feb 2016 06:39:38 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1JEdbJU028108 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Feb 2016 14:39:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1JEdaf8023197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 14:39:36 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1JEdXJ3009744; Fri, 19 Feb 2016 14:39:34 GMT Received: from [10.5.50.68] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Feb 2016 06:39:31 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_EEB83294-B911-4BB2-9045-0B53E7C12938" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: Date: Fri, 19 Feb 2016 07:39:30 -0700 Message-Id: <00031B6E-9A22-483F-AD58-BF0EC27CAFA6@oracle.com> References: <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <7367E525-494E-4B70-8AF7-FFC4F41DD99C@oracle.com> <01f301d16ab9$eb8a04c0$c29e0e40$@nri.co.jp> <9C09EE5B-CB1C-4DDE-8F5B-3CBF49BB3C85@oracle.com> <023e01d16ad5$1defad00$59cf0700$@nri.co.jp> <56F355AB-077D-4264-8417-051E10634128@oracle.com> To: Nat Sakimura X-Mailer: Apple Mail (2.3112) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:39:48 -0000 --Apple-Mail=_EEB83294-B911-4BB2-9045-0B53E7C12938 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Step 0 is something we need to discuss.=20 An OAuth protected resource can be hacked if a client uses an evil = discovery and it returns a proxied resource server. Just as a token = server can be proxied, so can a resource server. So the OAuth server = may be issuing tokens in a secure way, but then it gives it to a client = that uses them at the wrong endpoint. I believe the resource and the As must be bound together in a security = relationship. The security descriptor needs to reflect this. I am ok with separate app data discovery. But from the oauth security = perspective, the oauth server needs to indicate that it is the correct = server to use for Rx. There are probably multiple ways to do this, but I think the discovery = draft has only addressed 2 of 3 endpoints. We need all of them bound = together. @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 18, 2016, at 11:30 PM, Nat Sakimura = wrote: >=20 >=20 >=20 > 2016=E5=B9=B42=E6=9C=8819=E6=97=A5(=E9=87=91) 14:58 Phil Hunt (IDM) = >: > Inline... >=20 > Phil >=20 > On Feb 18, 2016, at 22:19, Nat Sakimura > wrote: >=20 >> Thanks for the explanation. Let me re-formulate.=C2=A0 <> >> =20 >>=20 >> Assumption >>=20 >=20 >=20 >> 1. There are resource server =E2=80=93 authorization server = pairs: R1A1 =E2=80=A6 RnAn.=20 >>=20 >> 2. There are clients C1 =E2=80=A6 Cm.=20 >>=20 >> 3. These instances can be hosted on a multi-tenancy environment.=20= >>=20 >> =20 >>=20 >> Flow >>=20 >=20 > Step 0. The client discovers the resource server endpoint and its = configs.=20 >=20 > Sure, but that's out of scope, is it not? If I am not mistaken, we are = talking about OAuth server configuration discovery. I do agree that = resource discovery in itself is a very interesting and important work = which I would love to work on, but that is not what we are talking about = here, I think. =20 > =20 > Question: should that include oauth?? John seems to imply yes.=20 >=20 > I do not think so. I think he was referring to the configuration of Ay = that corresponds to Ry. John? =20 >> 1. Client Cx goes to a resource server Ry, but he was denied of = the access and was told to get an access token. Now Cx needs to know = where to go.=20 >>=20 >> 2. Cx uses << Discovery>> to find the OAuth endpoints and the = associated metadata on Ay that corresponds to Ry.=20 >>=20 >=20 > Where is the discovery for Ay? > I was just trying to understand your use case. I have not put any = solution into it. That's why I marked discovery as <>. =20 >=20 > The default one that the draft suggest is the https://authority = (uri(Ay))/.well-known/openid-configuration.=20 > What John is suggesting is that we could also have = https://authority(uri(Ay))/.well-known/oauth-config-for-Ry = , if I read = his message correctly.=20 >=20 >=20 >> 3. Cx goes and fetches the Discovery file.=20 >>=20 >> 4. Cx goes to Ay to get authorized using the config info in the = Discovery file and the rest is normal RFC6749.=20 >>=20 >=20 > Referring to the risk that a client discovered from a bad source (eg = to insert a fake token endpoint), how does Ay know what discovery the = client used was correct? This might not be a problem in reality but it = needs to work.=20 >=20 > Right. We are currently asking the clients to be sane enough to get = the configuration for the server directly over https at the = authorization server, more or less. When Ay gets an authorization = request, it has no way of knowing that the client got the config from = the right endpoint. Are you suggesting something like have the client = send the signature of the config file that it is using now?=20 >> =20 >>=20 >> Is this correct?=20 >>=20 >> =20 >>=20 >> Nat >>=20 >> =20 >>=20 >> -- >>=20 >> PLEASE READ :This e-mail is confidential and intended for the >>=20 >> named recipient only. If you are not an intended recipient, >>=20 >> please notify the sender and delete this e-mail. >>=20 >> =20 >>=20 >> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com = ]=20 >> Sent: Friday, February 19, 2016 1:58 PM >> To: Nat Sakimura >> Cc: Mike Jones; oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its = essence >>=20 >> =20 >>=20 >> No. Much simpler.=20 >>=20 >> =20 >>=20 >> A service provider has decided to have a separate oauth server for = each web 'property'. This could be because they were acquired separately = and run different infrastructures. Or the business structure keeps each = BU completely separate.=20 >>=20 >> =20 >>=20 >> The client can't really depend on previously known or hard coded = endpoints because there are 1000s of instances deployed (eg as in = tenancies).=20 >>=20 >> =20 >>=20 >> This dynamic discovery is going to be particularly true of open = source software that customers choose to host on PaaS cloud providers of = their choosing.=20 >>=20 >>=20 >> Phil >>=20 >>=20 >> On Feb 18, 2016, at 19:04, Nat Sakimura > wrote: >>=20 >> Hi Phil,=20 >>=20 >> =20 >>=20 >> You wrote:=20 >>=20 >> > If example.com had separate oauth servers for = services xyz and abc,=20 >>=20 >> > how would discovery work from a single /.well-known endpoint? >>=20 >> =20 >>=20 >> I am trying to understand your use case, but I am not sure if I do.=20= >>=20 >> =20 >>=20 >> The use case seems to be such that:=20 >>=20 >> =20 >>=20 >> - There is a client C1. It could be a CRM or any kind of = application that uses RFC6749 and RFC6750 to access other resources a = resource server R1. C1 and R1 has a pre-configured relationship.=20 >>=20 >> - The resource server R1 supports RFC6750, and can have = multiple OAuth RFC6749 endpoints that it supports, which are A1, =E2=80=A6= , An.=20 >>=20 >> - Ax supports multiple resource services, Rx.=20 >>=20 >> - There is a user U1 that wants to access C1, which in turn = access R1. U1 gets authenticated somehow at C1. It could be either = through a password system at C1, or through a federated login protocol = supported at Ax, such as OpenID Connect.=20 >>=20 >> =20 >>=20 >> Another possibility is a case where Cx =3D Rx, which makes things a = bit simpler.=20 >>=20 >> =20 >>=20 >> Is this what you have in mind? Please let me know. If it is not, = please correct me. >>=20 >> =20 >>=20 >> Cheers,=20 >>=20 >> =20 >>=20 >> Nat >>=20 >> -- >>=20 >> PLEASE READ :This e-mail is confidential and intended for the >>=20 >> named recipient only. If you are not an intended recipient, >>=20 >> please notify the sender and delete this e-mail. >>=20 >> =20 >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Phil Hunt (IDM) >> Sent: Friday, February 19, 2016 2:09 AM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its = essence >>=20 >> =20 >>=20 >> How does the client request the oauth configuration assigned to xyz? >>=20 >> =20 >>=20 >> The example you give appears to presume a single oauth infrastructure = for all apps.=20 >>=20 >> =20 >>=20 >> The only way right now to have apps specific oauth is to infer the = relation by the domain "xyz.example.com ". =20 >>=20 >> =20 >>=20 >> That makes discovery more complex because there arw many more = discovery locations and many more configurations to maintain.=20 >>=20 >> =20 >>=20 >> If example.com had separate oauth servers for = services xyz and abc, how would discovery work from a single /.well-know = endpoint? >>=20 >>=20 >> Phil >>=20 >>=20 >> On Feb 18, 2016, at 09:41, Mike Jones > wrote: >>=20 >> Let me second John=E2=80=99s point that OAuth configuration = information and application configuration information need not be = interspersed. For instance, if the service is at https://example.com = and the XYZ application is being used, then these = configuration metadata documents could both be used: >>=20 >> =C2=B7 https://example.com/.well-known/openid-configuration = - OAuth = configuration metadata >>=20 >> =C2=B7 https://example.com/.well-known/xyz-configuration = - XYZ configuration = metadata >>=20 >> =20 >>=20 >> There=E2=80=99s not much point in defining a new = /.well-known/oauth2.0 value, since there is no such thing as generic = OAuth 2.0. By definition, it must always be used in an application = context that profiles OAuth 2.0 to enable interoperability. The = existing /.well-known/openid-configuration value works fine for this = purpose. Yes, the optics of having a different value might seem better = but it comes at the cost of interoperability problems. In my view, = interop trumps optics. >>=20 >> =20 >>=20 >> To a point that George Fletcher made, WebFinger could still be used = to learn the locations of these configuration metadata documents if that = makes sense in the application context. The editors took WebFinger out = of the OAuth Discovery document since it isn=E2=80=99t always = applicable. >>=20 >> =20 >>=20 >> Cheers, >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: John Bradley [mailto:ve7jtb@ve7jtb.com = ]=20 >> Sent: Thursday, February 18, 2016 7:41 AM >> To: Phil Hunt > >> Cc: Mike Jones >; oauth@ietf.org = >> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its = essence >>=20 >> =20 >>=20 >> I suspect that the configuration well-knowns are going to be on the = root domain. You could try and get a user to put in crm.example.com = , but I suspect that is not going to work. >>=20 >> =20 >>=20 >> If the app doesn=E2=80=99t have a specific protocol identifier then = it would use the default. =20 >>=20 >> =20 >>=20 >> I don=E2=80=99t know if you can get around having some sort of = app/protocol identifier configured in the app. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 18, 2016, at 9:49 AM, Phil Hunt > wrote: >>=20 >> =20 >>=20 >> resource service X could be any http accessible service: >>=20 >> =20 >>=20 >> * CRM >>=20 >> * Finance >>=20 >> * Payroll >>=20 >> * ERP >>=20 >> * any application on the web. >>=20 >> =20 >>=20 >> The spec seems to suggest that we use /.well-known/crm to discover = OAuth config for crm. But that may cause conflict if crm has its own = discovery. Which leads us down the path of doing something like = =E2=80=9Ccrm-oauth=E2=80=9D. >>=20 >> =20 >>=20 >> Then there is confusion about what host the discovery is done on. >>=20 >> =20 >>=20 >> For example, hypothetically do I do: >>=20 >> =20 >>=20 >> GET /.well-known/crm >>=20 >> Host: example.com >> =20 >>=20 >> But what about the CRM=E2=80=99s configuration information. Is this = stomping on it? >>=20 >> =20 >>=20 >> Or, what If we put the oauth configuration at the host for the crm = service: >>=20 >> GET /.well-known/openid-configuration >>=20 >> Host: crm.example.com >> =20 >>=20 >> I think the point is that there is a relationship between a protected = resource and its designated OAuth service.=20 >>=20 >> =20 >>=20 >> The client needs to discover: >>=20 >> * Where is its designated resource service and what security does it = use >>=20 >> * If it is OAuth, where is the intended OAuth configuration for that = resource service instance? >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >> phil.hunt@oracle.com >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 18, 2016, at 7:19 AM, John Bradley > wrote: >>=20 >> =20 >>=20 >> Can you clarify what you mean by =E2=80=9Cresource service x=E2=80=9D? >>=20 >> =20 >>=20 >> Is that the RS base URI for the resource, a specific URI that the = client is requesting? >>=20 >> =20 >>=20 >> That is getting UMA ish.=20 >>=20 >> =20 >>=20 >> The concept of a base RS URI is a rat hole that I prefer not to go = down, as it is something everyone thinks exists but like SCIM if it = exists it is protocol or deployment specific. >>=20 >> =20 >>=20 >> The notion that you would send the URI you are planning on requesting = to a Webfinger server to find the OAuth server, is probably going to = have privacy issues. >>=20 >> =20 >>=20 >> I suspect that you need to hand back a error from the resource to say = where the AS is, or have a .well-known for the RS. >>=20 >> =20 >>=20 >> RS discovery probably wants to be separate from AS discovery. (Yes I = do think we need something, UMA rpt or something like it might be a way = to go) >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> On Feb 18, 2016, at 9:06 AM, Phil Hunt > wrote: >>=20 >> =20 >>=20 >> Maybe SCIM was a bad example. It functions as a RESTful resource in = the context of OAuth. >>=20 >> =20 >>=20 >> I find the use of OIDC to be confusing as an example (and the = default) because it is both an OAuth resource and a security service. = It is a modification of OAuth. >>=20 >> =20 >>=20 >> Start thinking about every application ever written that uses OAuth. = Are we expecting 100s of thousands of these to each register? >>=20 >> =20 >>=20 >> To me, this specification is a fine specification for OIDC and it = should be published there because the specification defines how to = discovery OAuth and OpenID information. >>=20 >> =20 >>=20 >> Likewise you suggest it is ok for SCIM to do the same.=20 >>=20 >> =20 >>=20 >> How do we expect normal applications to set up and do discovery? >>=20 >> =20 >>=20 >> It seems to me that an =E2=80=9COAUTH=E2=80=9D discovery spec should = have a parameter to ask, I want to discover OAuth configuration for = resource service X. >>=20 >> =20 >>=20 >> That still allows me to have a separate discovery service that says, = tell me about resource service X itself. >>=20 >> =20 >>=20 >> BTW. I think we are FAR from Last Call on this topic. >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >> phil.hunt@oracle.com >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 18, 2016, at 6:55 AM, John Bradley > wrote: >>=20 >> =20 >>=20 >> Diffrent protocols like Connect and SCIM may have different = configurations, endpoints , keys , authentication methods, scopes etc. >>=20 >> =20 >>=20 >> It should be posable to have them as one document, but forcing them = to use one document is going to cause a explosion of claim registration = for discovery. >>=20 >> =20 >>=20 >> I think it is better for SCIM to register one well known than to have = to register 20 claims with scim prefixes or something silly like that. >>=20 >> =20 >>=20 >> Name-spacing the claims by allowing them to be in different well = known files is not unreasonable. >>=20 >> =20 >>=20 >> Remember some of these protocols may be hosted on SaaS so there is no = guarantee that all protocols will have the same OAuth Config. >>=20 >> =20 >>=20 >> Nothing stops a protocol from doing what it likes with webfinger if = it wants to use that for discovery. >>=20 >> =20 >>=20 >> In principal I like the idea of having another protocol as an = example. >>=20 >> =20 >>=20 >> My only concern is that I haven=E2=80=99t seen any discussion of your = SCIM discovery document in the SCIM WG. =20 >>=20 >> I personally think sorting out discovery for SCIM is a good idea, = but OAUTh is but one of several authentication methods for SCIM, and = there are probably other non OAuth things that want to be described. >>=20 >> =20 >>=20 >> I would feel better about using it as an example if it were adopted = by the WG and some general interest shown. >>=20 >> =20 >>=20 >> I encourage you to do that so we can use it as a example. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> On Feb 18, 2016, at 8:35 AM, Phil Hunt > wrote: >>=20 >> =20 >>=20 >> I still find the following text objectionable and confusing=E2=80=A6 >>=20 >> By default, for historical reasons, unless an application-specific >> well-known URI path suffix is registered and used for an = application, >> the client for that application SHOULD use the well-known URI path >> suffix "openid-configuration" and publish the metadata document at >> the path formed by concatenating = "/.well-known/openid-configuration" >> to the authorization server's issuer identifier. As described in >> Section 5 = , = despite the identifier >> "/.well-known/openid-configuration", appearing to be = OpenID-specific, >> its usage in this specification is actually referring to a general >> OAuth 2.0 feature that is not specific to OpenID Connect. >> =20 >>=20 >> Further, as a default =E2=80=9Copenid-configuration=E2=80=9D as the = default further gives people the impression that a plain OAuth server = *is* an authentication server and that the normal access token received = is evidence of a successful authentication. >>=20 >> =20 >>=20 >> It would be better to point out that application may include oauth = discovery in their discovery URI and that OAuth is an example of this. = It might be good to include two examples. E.g. OIDC and SCIM (as = another referenceable example). >>=20 >> =20 >>=20 >> GET /.well-known/openid-configuration >> and >>=20 >> GET /.well-known/scim >> Retrieve the OAuth configuration for the application openid and scim = respectively. >>=20 >> =20 >>=20 >> The use of: >>=20 >> GET /.well-known/oauth2/ >> Should be the default used when there is no known application based = well-known application based URI discovery. >>=20 >> =20 >>=20 >> Of course, the concern I raised earlier is that this approach of = application specific URIs ends up requiring every application to make an = IANA registration if they don=E2=80=99t want to use the default of = =E2=80=9Coauth2=E2=80=9D (or =E2=80=9Copenid-configuration=E2=80=9D). = Is that what the authors expect? >>=20 >> =20 >>=20 >> It seemed better to me to use the webfinger syntax to allow the = client to say =E2=80=9CI want the designated OAuth configuration for the = resource service X=E2=80=9D would be a better design that avoids = extensive IANA registration. >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >> phil.hunt@oracle.com >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 17, 2016, at 11:48 PM, Mike Jones > wrote: >>=20 >> =20 >>=20 >> In response to working group input, this version of the OAuth = Discovery specification has been pared down to its essence =E2=80=93 = leaving only the features that are already widely deployed. = Specifically, all that remains is the definition of the authorization = server discovery metadata document and the metadata values used in it. = The WebFinger discovery logic has been removed. The relationship between = the issuer identifier URL and the well-known URI path relative to it at = which the discovery metadata document is located has also been = clarified. >>=20 >> =20 >>=20 >> Given that this now describes only features that are in widespread = deployment, the editors believe that this version is ready for working = group last call. >>=20 >> =20 >>=20 >> The specification is available at: >>=20 >> =C2=B7http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 = >> =20 >>=20 >> An HTML-formatted version is also available at: >>=20 >> =C2=B7http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html = >> =20 >>=20 >> -- Mike & Nat & John >>=20 >> =20 >>=20 >> P.S. This notice was also posted athttp://self-issued.info/?p=3D1544 = and as@selfissued = . >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_EEB83294-B911-4BB2-9045-0B53E7C12938 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Step 0 is  something we need to discuss. 

An OAuth protected = resource can be hacked if a client uses an evil discovery and it returns = a proxied resource server.  Just as a token server can be proxied, = so can a resource server.  So the OAuth server may be issuing = tokens in a secure way, but then it gives it to a client that uses them = at the wrong endpoint.

I believe the resource and the As must be bound together in a = security relationship. The security descriptor needs to reflect = this.

I am ok = with separate app data discovery.  But from the oauth security = perspective, the oauth server needs to indicate that it is the correct = server to use for Rx.

There are probably multiple ways to do this, but I think the = discovery draft has only addressed 2 of 3 endpoints.  We need all = of them bound together.

@independentid
www.independentid.com
phil.hunt@oracle.com





On Feb 18, 2016, at 11:30 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:



2016=E5=B9=B42=E6=9C=8819=E6=97=A5(=E9=87=91) 14:58 Phil Hunt = (IDM) <phil.hunt@oracle.com>:
Inline...

Phil

On Feb 18, 2016, at 22:19, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

Thanks for the explanation. Let me = re-formulate. 

 

Assumption


1.     There are resource server =E2=80=93 = authorization server pairs: R1A1 =E2=80=A6 RnAn. 

2.     There are clients C1 =E2=80=A6 = Cm. 

3.     These instances can be hosted on a = multi-tenancy environment. 

 

Flow

Step 0. The client discovers the = resource server endpoint and its = configs. 

Sure, but that's out of scope, is it = not? If I am not mistaken, we are talking about OAuth server = configuration discovery. I do agree that resource discovery in itself is = a very interesting and important work which I would love to work on, but = that is not what we are talking about here, I think.  
 
Question: = should that include oauth?? John seems to imply = yes. 

I do not think so. I think he was = referring to the configuration of Ay that corresponds to Ry. John? =  

1.     Client Cx goes to a resource server = Ry, but he was denied of the access and was told to get an access token. = Now Cx needs to know where to go. 

2.     Cx uses << Discovery>> = to find the OAuth endpoints and the associated metadata on Ay that = corresponds to Ry. 

Where is = the discovery for Ay?
I was just = trying to understand your use case. I have not put any solution into it. = That's why I marked discovery as <<Discovery>>. =  

The = default one that the draft suggest is the https://authority(uri(Ay))/.well-known/openid-configuration= . 
What John is suggesting is that we could = also have https://authority(uri(Ay))/.well-known/oauth-config-for-Ry,= if I read his message correctly. 


3.     Cx goes and fetches the Discovery = file. 

4.     Cx goes to Ay to get authorized = using the config info in the Discovery file and the rest is normal = RFC6749. 


Referring to the risk that a client = discovered from a bad source (eg to insert a fake token endpoint), how = does Ay know what discovery the client used was correct?  This = might not be a problem in reality but it needs to = work. 

Right. We are = currently asking the clients to be sane enough to get the configuration = for the server directly over https at the authorization server, more or = less. When Ay gets an authorization request, it has no way of knowing = that the client got the config from the right endpoint. Are you = suggesting something like have the client send the signature of the = config file that it is using now? 

 

Is this correct? 

 

Nat

 

--

PLEASE READ :This e-mail is confidential and intended for = the

named recipient only. If you are = not an intended recipient,

please notify the sender  and delete this e-mail.

 

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 
Sent: Friday, February 19, 2016 = 1:58 PM
To: Nat Sakimura
Cc: Mike= Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth = Discovery spec pared down to its essence

 

No. Much simpler. 

 

A service provider = has decided to have a separate oauth server for each web 'property'. = This could be because they were acquired separately and run different = infrastructures. Or the business structure keeps each BU completely = separate. 

 

The client can't = really depend on previously known or hard coded endpoints because there = are 1000s of instances deployed (eg as in tenancies). 

 

This dynamic = discovery is going to be particularly true of open source software that = customers choose to host on PaaS cloud providers of their = choosing. 


Phil


On Feb 18, 2016, at 19:04, Nat = Sakimura <n-sakimura@nri.co.jp> wrote:

Hi = Phil, 

 

You wrote: 

> If example.com had separate oauth servers = for services xyz and abc, 

> how would discovery work from a single /.well-known = endpoint?

 

I am trying to understand your use = case, but I am not sure if I do. 

 

The use case seems to be such = that: 

 

-       There is a client C1. It could be a = CRM or any kind of application that uses RFC6749 and RFC6750 to access = other resources a resource server R1. C1 and R1 has a pre-configured = relationship. 

-       The resource server R1 supports = RFC6750, and can have multiple OAuth RFC6749 endpoints that it supports, = which are A1, =E2=80=A6, An. 

-       Ax supports multiple resource = services, Rx. 

-       There is a user U1 that wants to = access C1, which in turn access R1. U1 gets authenticated somehow at C1. = It could be either through a password system at C1, or through a = federated login protocol supported at Ax, such as OpenID Connect. 

 

Another possibility is a case where = Cx =3D Rx, which makes things a bit simpler. 

 

Is this what you have in mind? = Please let me know. If it is not, please correct me.

 

Cheers, 

 

Nat

--

PLEASE READ :This e-mail is = confidential and intended for the

named recipient only. If you are not an intended = recipient,

please notify the sender  and delete this = e-mail.

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt = (IDM)
Sent: Friday, February 19, 2016 = 2:09 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth = Discovery spec pared down to its essence

 

How does the client = request the oauth configuration assigned to xyz?

 

The example you give = appears to presume a single oauth infrastructure for all apps. 

 

The only way right = now to have apps specific oauth is to infer the relation by the domain = "xyz.example.com".  

 

That makes discovery = more complex because there arw many more discovery locations and many = more configurations to maintain. 

 

If example.com had separate oauth servers = for services xyz and abc, how would discovery work from a single = /.well-know endpoint?


Phil


On Feb 18, 2016, at 09:41, Mike Jones <Michael.Jones@microsoft.com> wrote:

Let = me second John=E2=80=99s point that OAuth configuration information and = application configuration information need not be interspersed.  = For instance, if the service is at https://example.com and the XYZ application is = being used, then these configuration metadata documents could both be = used:

=C2=B7       https://example.com/.well-known/openid-configuration - OAuth configuration = metadata

=C2=B7       https://example.com/.well-known/xyz-configuration - XYZ configuration = metadata

 

There=E2=80=99s not much point in defining a new = /.well-known/oauth2.0 value, since there is no such thing as generic = OAuth 2.0.  By definition, it must always be used in an application = context that profiles OAuth 2.0 to enable interoperability.  The = existing /.well-known/openid-configuration value works fine for this = purpose.  Yes, the optics of having a different value might seem = better but it comes at the cost of interoperability problems.  In = my view, interop trumps optics.

 

To a point that George Fletcher made, = WebFinger could still be used to learn the locations of these = configuration metadata documents if that makes sense in the application = context.  The editors took WebFinger out of the OAuth Discovery = document since it isn=E2=80=99t always applicable.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Cheers,

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

 

From: John = Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, February 18, 2016 = 7:41 AM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike = Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth = Discovery spec pared down to its essence

 

I suspect that the configuration well-knowns = are going to be on the root domain.   You could try and get a user = to put in crm.example.com, but I suspect that is not going to = work.

 

If the app doesn=E2=80= =99t have a specific protocol identifier then it would use the default. =  

 

I don=E2=80=99t know = if you can get around having some sort of app/protocol identifier = configured in the app.

 

John B.

 

 

 

 

 

 

On Feb = 18, 2016, at 9:49 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

resource service X = could be any http accessible service:

 

* CRM

* Finance

* Payroll

* ERP

* any application on = the web.

 

The spec seems to = suggest that we use /.well-known/crm to discover OAuth config for = crm.  But that may cause conflict if crm has its own discovery. = Which leads us down the path of doing something like =E2=80=9Ccrm-oauth=E2= =80=9D.

 

Then there is = confusion about what host the discovery is done on.

 

For example, = hypothetically do I do:

 

GET = /.well-known/crm

Host: example.com

 

But what about the = CRM=E2=80=99s configuration information. Is this stomping on it?

 

Or, what If we put = the oauth configuration at the host for the crm service:

GET = /.well-known/openid-configuration

Host: crm.example.com

 

I think the point is = that there is a relationship between a protected resource and its = designated OAuth service. 

 

The client needs to = discover:

* = Where is its designated resource service and what security does it use

* If it is OAuth, = where is the intended OAuth configuration for that resource service = instance?

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

 

 

 

On Feb = 18, 2016, at 7:19 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

 

Can you clarify what = you mean by =E2=80=9Cresource service x=E2=80=9D?

 

Is that the RS base = URI for the resource,  a specific URI that the client is = requesting?

 

That is getting UMA = ish. 

 

The concept of a = base RS URI is a rat hole that I prefer not to go down, as it is = something everyone thinks exists but like SCIM if it exists it is = protocol or deployment specific.

 

The notion that you = would send the URI you are planning on requesting to a Webfinger server = to find the OAuth server, is probably going to have privacy issues.

 

I suspect that you = need to hand back a error from the resource to say where the AS is, or = have a .well-known for the RS.

 

RS discovery = probably wants to be separate from AS discovery.  (Yes I do think = we need something,  UMA rpt or something like it might be a way to = go)

 

John B.

 

On Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

Maybe SCIM was a bad = example.  It functions as a RESTful resource in the context of = OAuth.

 

I find the use of = OIDC to be confusing as an example (and the default) because it is both = an OAuth resource and a security service.  It is a modification of = OAuth.

 

Start thinking about = every application ever written that uses OAuth. Are we expecting 100s of = thousands of these to each register?

 

To me, this = specification is a fine specification for OIDC and it should be = published there because the specification defines how to discovery OAuth = and OpenID information.

 

Likewise you suggest = it is ok for SCIM to do the same. 

 

How do = we expect normal applications to set up and do discovery?

 

It seems to me that = an =E2=80=9COAUTH=E2=80=9D discovery spec should have a parameter to = ask, I want to discover OAuth configuration for resource service X.

 

That still allows me = to have a separate discovery service that says, tell me about resource = service X itself.

 

BTW. = I think we are FAR from Last Call on this topic.

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

 

 

 

On Feb = 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

 

Diffrent protocols = like Connect and SCIM may have different configurations, endpoints , = keys , authentication methods, scopes etc.

 

It should be posable = to have them as one document, but forcing them to use one document is = going to cause a explosion of claim registration for discovery.

 

I think it is better = for SCIM to register one well known than to have to register 20 claims = with scim prefixes or something silly like that.

 

Name-spacing the = claims by allowing them to be in different well known files is not = unreasonable.

 

Remember some of = these protocols may be hosted on SaaS so there is no guarantee that all = protocols will have the same OAuth Config.

 

Nothing stops a = protocol from doing what it likes with webfinger if it wants to use that = for discovery.

 

In principal I like = the idea of having another protocol as an example.

 

My only concern is = that I haven=E2=80=99t seen any discussion of your SCIM discovery = document in the SCIM WG.  

I personally think = sorting out discovery for SCIM is a good idea,  but OAUTh is but = one of several authentication methods for SCIM, and there are probably = other non OAuth things that want to be described.

 

I would feel better = about using it as an example if it were adopted by the WG and some = general interest shown.

 

I encourage you to = do that so we can use it as a example.

 

John B.

 

On Feb = 18, 2016, at 8:35 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

I = still find the following text objectionable and confusing=E2=80=A6

   By default, for =
historical reasons, unless an application-specific
   well-known URI path suffix is registered and =
used for an application,
   the client for that application SHOULD use the =
well-known URI path
   suffix =
"openid-configuration" and publish the metadata document at
   the path formed by concatenating =
"/.well-known/openid-configuration"
   to the authorization server's issuer =
identifier.  As described in
   Section 5, despite the identifier
   =
"/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification =
is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID =
Connect.

 

Further, as a = default =E2=80=9Copenid-configuration=E2=80=9D as the default further = gives people the impression that a plain OAuth server *is* an = authentication server and that the normal access token received is = evidence of a successful authentication.

 

It would be better = to point out that application may include oauth discovery in their = discovery URI and that OAuth is an example of this. It might be good to = include two examples.  E.g. OIDC and SCIM (as another referenceable = example).

 

 GET =
/.well-known/openid-configuration

and

 GET /.well-known/scim

Retrieve= the OAuth configuration for the application openid and scim = respectively.

 

The use of:

 GET /.well-known/oauth2/

Should be the = default used when there is no known application based well-known = application based URI discovery.

 

Of course, the = concern I raised earlier is that this approach of application specific = URIs ends up requiring every application to make an IANA registration if = they don=E2=80=99t want to use the default of =E2=80=9Coauth2=E2=80=9D = (or =E2=80=9Copenid-configuration=E2=80=9D).  Is that what the = authors expect?

 

It seemed better to = me to use the webfinger syntax to allow the client to say =E2=80=9CI = want the designated OAuth configuration for the resource service X=E2=80=9D= would be a better design that avoids extensive IANA registration.

 

Phil

 

@independentid

www.independentid.com

phil.hunt@oracle.com

 

 

 

 

On Feb = 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

In response to working = group input, this version of the OAuth Discovery specification has been = pared down to its essence =E2=80=93 leaving only the features that are = already widely deployed.  Specifically, all that remains is the = definition of the authorization server discovery metadata document and = the metadata values used in it.  The WebFinger discovery logic has = been removed.  The relationship between the issuer identifier URL = and the well-known URI path relative to it at which the discovery = metadata document is located has also been clarified.

 

Given that this now = describes only features that are in widespread deployment, the editors = believe that this version is ready for working group last = call.

 

The specification is = available at:

 

An HTML-formatted version = is also available at:

=C2=B7       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html=

 

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

 

P.S.  This notice was = also posted at http://self-issued.info/?p=3D1544 and as @selfissued.

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

 

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

 

 

 

 

 

_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail=_EEB83294-B911-4BB2-9045-0B53E7C12938-- From nobody Fri Feb 19 06:49:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398931A90C6 for ; Fri, 19 Feb 2016 06:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kISkDL3-biNX for ; Fri, 19 Feb 2016 06:49:32 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76FA1ACE9D for ; Fri, 19 Feb 2016 06:49:32 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1JEnUSW010540 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Feb 2016 14:49:31 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1JEnU2Z009048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 14:49:30 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1JEnUoq028967; Fri, 19 Feb 2016 14:49:30 GMT Received: from [10.5.50.68] (/209.121.103.35) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Feb 2016 06:49:30 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_BB898529-CB79-4CEF-9578-2BE36B8CE7D9" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Phil Hunt In-Reply-To: <56C6EAAA.50009@gmx.net> Date: Fri, 19 Feb 2016 07:49:25 -0700 Message-Id: <8B690C95-C55A-4E0B-90EA-1AE718F65082@oracle.com> References: <56C6EAAA.50009@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3112) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:49:35 -0000 --Apple-Mail=_BB898529-CB79-4CEF-9578-2BE36B8CE7D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Hannes. That=E2=80=99s great news! Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 19, 2016, at 3:12 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > early this year we announced our plans to organize an OAuth security > workshop. In the meanwhile we have made progress in the planning > activities and we are happy to announce that the workshop will take > place July 14th and 15th 2016 in Trier/Germany. The date fits nicely > with the IETF meeting in Berlin and our host, the Chair for = Information > Security and Cryptography at the University of Trier, may be familiar = to > some of you in context of the formal security analysis of OAuth also > published earlier this year. >=20 > More information can be found here: > https://infsec.uni-trier.de/events/osw2016 >=20 > With this workshop we particularly encourage researchers and other > security experts to analyse OAuth and OAuth extensions and to report > their findings at this workshop. Please note the position paper > deadline, which is May 21st. >=20 > We are looking forward to your contributions and to the discussions at > the workshop! Feel free to contact us if there are questions. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BB898529-CB79-4CEF-9578-2BE36B8CE7D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Hannes.  That=E2=80=99s great news!




On Feb 19, 2016, at 3:12 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi = all,

early this year we announced our plans = to organize an OAuth security
workshop. In the meanwhile = we have made progress in the planning
activities and we = are happy to announce that the workshop will take
place = July 14th and 15th 2016 in Trier/Germany. The date fits nicely
with the IETF meeting in Berlin and our host, the Chair for = Information
Security and Cryptography at the University of = Trier, may be familiar to
some of you in context of the = formal security analysis of OAuth also
published earlier = this year.

More information can be found = here:
https://infsec.uni-trier.de/events/osw2016

With this workshop we particularly encourage = researchers and other
security experts to analyse OAuth = and OAuth extensions and to report
their findings at this = workshop. Please note the position paper
deadline, which = is May 21st.

We are looking forward to your = contributions and to the discussions at
the workshop! Feel = free to contact us if there are questions.

Ciao
Hannes & Derek

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

= --Apple-Mail=_BB898529-CB79-4CEF-9578-2BE36B8CE7D9-- From prvs=85058ca23=Thomas.Kupka@bmw.de Fri Feb 19 03:15:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554F51B2E8D for ; Fri, 19 Feb 2016 03:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maMwO2w3F27O for ; Fri, 19 Feb 2016 03:15:02 -0800 (PST) Received: from esa8.bmw.c3s2.iphmx.com (esa8.bmw.c3s2.iphmx.com [68.232.139.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5235D1B2E8A for ; Fri, 19 Feb 2016 03:15:01 -0800 (PST) Received: from esagw2.bmwgroup.com (HELO esagw2.muc) ([160.46.252.38]) by esa8.bmw.c3s2.iphmx.com with ESMTP/TLS; 19 Feb 2016 12:14:56 +0100 Received: from unknown (HELO esabb4.muc) ([160.50.100.33]) by esagw2.muc with ESMTP/TLS; 19 Feb 2016 12:14:56 +0100 Received: from smuch56b.muc (HELO SMUCH56B.europe.bmw.corp) ([160.46.137.110]) by esabb4.muc with ESMTP/TLS; 19 Feb 2016 12:14:55 +0100 Received: from SMUCM70B.europe.bmw.corp ([169.254.6.66]) by SMUCH56B.europe.bmw.corp ([160.46.137.110]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 12:14:55 +0100 From: To: Thread-Topic: RFC 7009: Revoke Access Tokens issued to HTML5 web apps Thread-Index: AdFrBR4Ruijl3823QaGFLNeRBqp/1g== Date: Fri, 19 Feb 2016 11:14:54 +0000 Message-ID: <788977955ECA61468DD6F0FF5CAC14DB1DB40F@SMUCM70B.europe.bmw.corp> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.44.100] Content-Type: multipart/alternative; boundary="_000_788977955ECA61468DD6F0FF5CAC14DB1DB40FSMUCM70Beuropebmw_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 19 Feb 2016 07:34:20 -0800 Subject: [OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 11:15:53 -0000 --_000_788977955ECA61468DD6F0FF5CAC14DB1DB40FSMUCM70Beuropebmw_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we use the OAuth 2.0 Implicit grant to issue access_tokens to client applic= ations such as HTML 5 web apps that have no secure means to securely authen= ticating themselves. Even if the credentials would be obfuscated, any user = could extract them from the HTTP requests their User Agent makes with minim= al effort. Since RFC 7009 also talks about the usage of CORS to support Use= r-Agent clients, however, I believe that these clients should be supported. So I am having trouble supporting the revocation requirement in RFC 7009 wh= ich states: The client also includes its authentication credentials as described in Section 2.3. of [RFC6749]. Looking at said section in in RFC 6749, it states: If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server. The authorization server MAY accept any form of client authentication meeting its security requirements. I am unsure whether "having no form of client authentication" conforms to t= he standard, can you comment on this? As a side note, I wonder why client authentication for token revocations is= required anyway, because if a client received a token by any legit means, = it should always be able to revoke it, regardless of authentication. And if= an unauthorized client 'stole' any type of token, revoking it should also = be possible, since loss of service for the intended client should always be= preferred over misusing the token. Cheers, Thomas BMW Group Thomas Kupka Customer Data Management, FG-6301 GCDM Identity & Access Management Bremer Stra=DFe 6 80807 M=FCnchen Postanschrift: 80788 M=FCnchen Tel: +49-89-382-54083 Mail: Thomas.Kupka@bmw.de Web: http://www.bmwgroup.com/ -------------------------------------------------------- Bayerische Motoren Werke Aktiengesellschaft Vorstand: Harald Kr=FCger (Vorsitzender), Milagros Cai=F1a Carreiro-Andree, Klaus Draeger, Friedrich Eichiner, Klaus Fr=F6hlich, Ian Robertson, Peter Schwarzenbauer, Oliver Zipse. Vorsitzender des Aufsichtsrats: Norbert Reithofer Sitz und Registergericht: M=FCnchen HRB 42243 -------------------------------------------------------- --_000_788977955ECA61468DD6F0FF5CAC14DB1DB40FSMUCM70Beuropebmw_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

we use the OAuth 2.0 Implicit g= rant to issue access_tokens to client applications such as HTML 5 web apps = that have no secure means to securely authenticating themselves. Even if th= e credentials would be obfuscated, any user could extract them from the HTTP requests their User Agent makes with= minimal effort. Since RFC 7009 also talks about the usage of CORS to suppo= rt User-Agent clients, however, I believe that these clients should be supp= orted.

 

So I am having trouble supporti= ng the revocation requirement in RFC 7009 which states: 

 
   The client also includes its authent=
ication credentials as described
   in Section 2.3. of [RFC6749].<=
/o:p>

 

Looking at said section in in R= FC 6749, it states:

 

   If the client type is confidential, =
the client and authorization
   server establish a client authentica=
tion method suitable for the
   security requirements of the authori=
zation server.  The authorization
   server MAY accept any form of client=
 authentication meeting its
   security requirements.

 

I am unsure whether “havi= ng no form of client authentication” conforms to the standard, can yo= u comment on this?

 

As a side note, I wonder why cl= ient authentication for token revocations is required anyway, because if a = client received a token by any legit means, it should always be able to rev= oke it, regardless of authentication. And if an unauthorized client ‘stole’ any type of token, revok= ing it should also be possible, since loss of service for the intended clie= nt should always be preferred over misusing the token.

 

Cheers,

 

Thomas

 

 

BMW Group
Thomas Kupka

Customer Data = Management, FG-6301

GCDM Identity = & Access Management

Bremer Stra=DF= e 6

80807 M=FCnche= n

 

Postanschrift:

80788 M=FCnchen


Tel: +49-89-382-54083
Mail: Thomas.Kupka@bmw.de
Web:  = http://www.bmwgroup.com/
--------------------------------------------------------
Bayerische Motoren Werke Aktiengesellschaft Vorstand: Harald Kr=FCger (Vorsitzender),
Milagros Cai=F1a Carreiro-Andree, Klaus Draeger,
Friedrich Eichiner, Klaus Fr=F6hlich, Ian Robertson,
Peter Schwarzenbauer, Oliver Zipse.
Vorsitzender des Aufsichtsrats: Norbert Reithofer
Sitz und Registergericht: M=FCnchen HRB 42243=
--------------------------------------------------------=

 

--_000_788977955ECA61468DD6F0FF5CAC14DB1DB40FSMUCM70Beuropebmw_-- From nobody Fri Feb 19 11:42:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F2F1B2B25 for ; Fri, 19 Feb 2016 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VYWsce55tn8 for ; Fri, 19 Feb 2016 11:42:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC52F1AC3E0 for ; Fri, 19 Feb 2016 11:42:27 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MKbZD-1aUw4M20jn-001wW6 for ; Fri, 19 Feb 2016 20:42:25 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56C7702B.2000401@gmx.net> Date: Fri, 19 Feb 2016 20:42:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GsTROuPn7vlEwrWMDAdqTkEJMluUHexP8" X-Provags-ID: V03:K0:j12PMSFwOuKBkTisd9X+dZNqLIqeuWmJr+5h9yAXMSg4Glq/JLk sRH+KLFdhYmcH/cfDghnyMFH6dWosfKGaU58JuwiawX7z8pN5/8EYLLehVemPurMTy6LSbp AAlOz8Jiiw3lfhEUwXHIR5Sd9JOkZw9+wA4dGEyfkA2DliPeMisT5COdsrN5NbZ9X3RRvjl T7JHX0QsdJ3iOtWzv1ezA== X-UI-Out-Filterresults: notjunk:1;V01:K0:QmM8v+h6PXI=:Wv+OqWhMzCHP7s9+6froHL RtphOgXKPl9x1rtHq2/5dP5VjgR76h2n6/6qKlu+e+Sc/MvpSNp+5A7S+R0L9nz2mWbhvgn9K M2PxpP++ieRZl3Ccl8rD4k/+olF3oheMkcRGl3EtGeqH2X5ZA58ksjvTL2bFjbELDG9e3Gqky ycZbN3PXjSQUM4VS5A7T+BbeqBcE386l1DbA+k079fIAH0V1o6kN3ZV04RNnEbQ20gHyFkum3 KSs6uWEAYiZsSCZulW8XZmblsXqyDAylzKk+WDi/018IarRT1eq8gWQfBjPj8uaRlFXh268Lg O2VvXDMQyvTfMmorqiB19zYPZX2I4gWSt3UAxcYGmno9XEIvOqUdk82nJIICZ3ZZj2W+Dd0F4 S82o3bxJ7p8ofyEIN4hyEyixDoUhtrwHJjTyFCpXN3qrLC5Ldczl6aSbwUEudxxhIvn0aSu8E R31CwmwFBnaV7I+KVbpAX+Qa/2hdf20AFPOJKv+l9nSnE2ZJYfQ+9KBT0QvvUmFbFpsoEa5mN O7N00KbORGPDZlhCUecw2r91v3j9+YQU4Aexm9NtEPS3bmB3u5noRy05UhCFwwW65PY7MY2Uq ZOGZeF/MrTr9Qmpkz3hBU6/MQ0AgZKC7Uj/ecMiUwpvZ56vxV9ljObqrdlm6pZgn1Jvvv6MuU mZcT9vqRlcaPiOCIdsG2DYq1M9eOpHdgyPjrdG6fblI3HRX539udOGzMMlRjtu55yUduUY538 fPGT0ACha0XMOiu7F7x8+8aLYzm499ervFxsOLYYP1XouXNDi0Uw8dT/8QI= Archived-At: Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 19:42:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GsTROuPn7vlEwrWMDAdqTkEJMluUHexP8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Early February I posted a mail to the list to make progress on the solution to the OAuth Authorization Server Mix-Up problem discovered late last year. Here is my mail about the Authorization Server Mix-Up: http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html Here is my mail to the list that tries to summarize the discussion status and asked a few questions: http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html Unfortunately, my mail didn't lead to the intended success. While there was some feedback I wasn't getting the desired response. In order to move forward I believe we need a working group document that serves as a starting point for further work in the group*. We have two documents that provide similar functionality in an attempt to solve the Authorization Server Mix-Up problem. So, here is the question for the group. Which document do you want as a starting point for work on this topic: -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley= Link: https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and Sascha Preibisch Link: https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 Deadline for feedback is March, 4th. Ciao Hannes & Derek PS: (*) Regardless of the selected solution we will provide proper acknowledgement for those who contributed to the work. --GsTROuPn7vlEwrWMDAdqTkEJMluUHexP8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWx3ArAAoJEGhJURNOOiAt2xwH/1rJGpBDGmAzJCbrcMOC/yJt KEwXUozGYFsZEOMZ4mhy1hYgRuIfQUcc4VchMbVDXfUheE3ucA+AI9AsfIg9tE2n HpkBAOwbunljhN/XY8ycgYF3cpxCd787zg0FfGcV9MO59z7HgZ6zFC4wwAycDbTA 4Rp1zXRm0RzeQ14A1fA5wxALwMWBy3L3a0fxWNPBf5nUol4TDTR0HD98jvIncVkM GQt46kBXh8/PE96niSrm+INYCS+tVBYSQcU4IdJWUNkLptoUdgK/zuqNVbSE502P cgYuagFSc3SO21ZaG4UsuisKNUb7URNrHMg5KDeTmBJOXLC87eOc9dHEaUiMx/U= =HWbD -----END PGP SIGNATURE----- --GsTROuPn7vlEwrWMDAdqTkEJMluUHexP8-- From nobody Fri Feb 19 12:19:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3B61B2D82 for ; Fri, 19 Feb 2016 12:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIX9HLumvQyE for ; Fri, 19 Feb 2016 12:19:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2AE1B2A7A for ; Fri, 19 Feb 2016 12:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iXKzrUrjG8ZD6H3Oz2m/bLq1vUqElz2yittqpsAubj0=; b=jycKl6de36L1SoPjEX2Mp9cP6QHaB+7gtlV2+0XZYT1vZOhRuiPhXnCYGnugxdNwu5cIYJxXfw+QNEZW438uZv6JRN2N24maC3F9GhXVF4QJyigcMUQNdxQHH2wjCv1YAODr7SekWVq8aoXtncFHiR7aAoY/EPCE+agrLKYub2c= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 20:18:55 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 20:18:55 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRa02vcYDFrUX6M06+JVJIk0JwsZ8zyRTA Date: Fri, 19 Feb 2016 20:18:55 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> In-Reply-To: <56C7702B.2000401@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 31b81990-ce68-4aba-8701-08d33969e450 x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:xwrFzgZ99SoZrrcrLrXdDOhwrJ2xdjAWWrpc/mW0rC7x5fwOyHmtdKOb88rhKndVNSWK3SCRJ534yyuXIECmvYmuLPJEVEUnu9lZFoiBozwcOW8bNdpOD29aysJNcSjaXmecPM6qZKV3CXh4BcGYKg==; 24:5y+0ku8wMBWMGqCNQ/ExAp2ypC2h93FIO4g++StXb1FCoGMBPC71XT6t4K2up6CwglQrhuC+Q70O46bHuzxupu68e8Dcozhsw/w+R44E8Mo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(72854002)(13464003)(377454003)(86362001)(19580405001)(5001960100002)(86612001)(19617315012)(586003)(3660700001)(790700001)(1220700001)(87936001)(2900100001)(2501003)(15975445007)(77096005)(5001770100001)(19580395003)(1096002)(102836003)(2950100001)(6116002)(189998001)(92566002)(107886002)(3846002)(54356999)(5003600100002)(5004730100002)(11100500001)(99286002)(16236675004)(33656002)(5008740100001)(10090500001)(5002640100001)(66066001)(50986999)(76576001)(5005710100001)(122556002)(10400500002)(3280700002)(106116001)(2906002)(19300405004)(10290500002)(40100003)(76176999)(19625215002)(74316001)(15940465004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E9BF84AFA890378C5116F5A00BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 20:18:55.1860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 20:19:19 -0000 --_000_BY2PR03MB442E9BF84AFA890378C5116F5A00BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3B0aW9uIEEuICBJIGhhdmUgaGlnaGVyIGNvbmZpZGVuY2UgdGhhdCB0aGlzIHNwZWNpZmljYXRp b24gc29sdmVzIHRoZSBwcm9ibGVtcyBiZWNhdXNlIGl0IHdhcyBkZXNpZ25lZCBkdXJpbmcgYSA0 LWRheSBzZWN1cml0eSBtZWV0aW5nIGRlZGljYXRlZCB0byB0aGlzIHRhc2sgYnkgYSBncm91cCBv ZiBvdmVyIDIwIE9BdXRoIHNlY3VyaXR5IGV4cGVydHMsIGluY2x1ZGluZyBib3RoIHNldHMgb2Yg cmVzZWFyY2hlcnMgaW4gR2VybWFueSB3aG8gb3JpZ2luYWxseSBpZGVudGlmaWVkIHRoZSBwcm9i bGVtLiAgVGhpcyBzb2x1dGlvbiBoYXMgYWxzbyBiZWVuIGltcGxlbWVudGVkIGFuZCBpbnRlcm9w IHRlc3RlZCBieSBSb2xhbmQgSGVkYmVyZywgQnJpYW4gQ2FtcGJlbGwsIGFuZCBJIGJlbGlldmUg b3RoZXJzLiAgTm90ZSB0aGF0IHRoZSByZWFzb24gSSBhbSBhZHZvY2F0aW5nIHRoaXMgc3BlY2lm aWNhdGlvbiBpcyAqbm90KiBiZWNhdXNlIEknbSBhbiBlZGl0b3Igb2YgaXQ7IG15IHJvbGUgd2Fz IHRvIHJlY29yZCBpbiBzcGVjIGxhbmd1YWdlIHdoYXQgdGhlIE9BdXRoIHNlY3VyaXR5IGV4cGVy dHMgZGVzaWduZWQgdG9nZXRoZXIgb3ZlciB0aGUgNC1kYXkgcGVyaW9kIGluIERhcm1zdGFkdC4N Cg0KDQoNCknigJlsbCBhbHNvIG5vdGUgdGhhdCBldmVuIGlmIE9wdGlvbiBCIGFsc28gc29sdmVz IHRoZSBwcm9ibGVtLCBpdCBjb21lcyBhdCBzaWduaWZpY2FudCBhZG9wdGlvbiBjb3N0cyBhbmQg Y29tcGxleGl0eSBub3QgZm91bmQgaW4gQS4gIEluIHBhcnRpY3VsYXIsIGl0IHJlcXVpcmVzIHRo YXQgZGV2ZWxvcGVycyB1bmRlcnN0YW5kIHN1cHBvcnQgYSBuZXcg4oCcTGluayBSZWxhdGlvbuKA nSBzeW50YXggbm90IHVzZWQgZWxzZXdoZXJlIGluIE9BdXRoLiAgQXMgTmF0IHdyaXRlcyBhYm91 dCBoaXMgb3duIGRyYWZ0IGluIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzE1Nzg5Lmh0bWwgLSB0aGVyZSBpcyBub3QgYSBzdGFuZGFyZCBKU09O IHN5bnRheCBmb3IgbGluayByZWxhdGlvbnMuICBIZSB3cml0ZXMg4oCcd2UgY291bGQgZWFzaWx5 IGNyZWF0ZSBhIHBhcmFsbGVsIHRvIGl04oCdLiAgSeKAmWQgcmF0aGVyIHdlIHNvbHZlIHRoZSBw cm9ibGVtIHVzaW5nIHN0YW5kYXJkIG1lY2hhbmlzbXMgYWxyZWFkeSBlbXBsb3llZCBpbiBPQXV0 aCwgcmF0aGVyIHRoYW4gcmlzayBiaWZ1cmNhdGluZyBPQXV0aCBpbiB0aGUgZGV2ZWxvcGVyIGNv bW11bml0eSBieSB1bm5lY2Vzc2FyaWx5IGludmVudGluZy9jcmVhdGluZyBuZXcgc3ludGF4IHRo YXQgaXMgdW5mYW1pbGlhciB0byBkZXZlbG9wZXJzIGFuZCB0aGF0IG1hbnkgb2YgdGhlbSBtYXkg cmVqZWN0IHVzaW5nLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNClAuUy4gIEluZm9ybWF0aW9uIGFi b3V0IHRoZSBPQXV0aCBzZWN1cml0eSBtZWV0aW5nIGNhbiBiZSBmb3VuZCBhdCBodHRwczovL2Rv Y3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzEzNkN6Mml3VUZNZG9LV1pQQ3FaUmhrbWZtSEFsSjZr TTVPeWVYekdwdFU0L2VkaXQgYW5kIGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2Qv MWNSYTExRWdpbW5UZUpaUjEtUFVwTlJwaV91X0VvU3BPNU50YWtWYkFfc2svZWRpdCAuDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMTksIDIwMTYgMTE6NDMgQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3Vi amVjdDogW09BVVRILVdHXSBGaXhpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1peC1VcDog Q2FsbCBmb3IgQWRvcHRpb24NCg0KDQoNCkVhcmx5IEZlYnJ1YXJ5IEkgcG9zdGVkIGEgbWFpbCB0 byB0aGUgbGlzdCB0byBtYWtlIHByb2dyZXNzIG9uIHRoZSBzb2x1dGlvbiB0byB0aGUgT0F1dGgg QXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWl4LVVwIHByb2JsZW0gZGlzY292ZXJlZCBsYXRlIGxhc3Qg eWVhci4NCg0KDQoNCkhlcmUgaXMgbXkgbWFpbCBhYm91dCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgTWl4LVVwOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgv Y3VycmVudC9tc2cxNTMzNi5odG1sDQoNCg0KDQpIZXJlIGlzIG15IG1haWwgdG8gdGhlIGxpc3Qg dGhhdCB0cmllcyB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gc3RhdHVzIGFuZCBhc2tlZCBh IGZldyBxdWVzdGlvbnM6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzE1Njk3Lmh0bWwNCg0KDQoNClVuZm9ydHVuYXRlbHksIG15IG1haWwg ZGlkbid0IGxlYWQgdG8gdGhlIGludGVuZGVkIHN1Y2Nlc3MuIFdoaWxlIHRoZXJlIHdhcyBzb21l IGZlZWRiYWNrIEkgd2Fzbid0IGdldHRpbmcgdGhlIGRlc2lyZWQgcmVzcG9uc2UuDQoNCg0KDQpJ biBvcmRlciB0byBtb3ZlIGZvcndhcmQgSSBiZWxpZXZlIHdlIG5lZWQgYSB3b3JraW5nIGdyb3Vw IGRvY3VtZW50IHRoYXQgc2VydmVzIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGZ1cnRoZXIgd29y ayBpbiB0aGUgZ3JvdXAqLiBXZSBoYXZlIHR3byBkb2N1bWVudHMgdGhhdCBwcm92aWRlIHNpbWls YXIgZnVuY3Rpb25hbGl0eSBpbiBhbiBhdHRlbXB0IHRvIHNvbHZlIHRoZSBBdXRob3JpemF0aW9u IFNlcnZlciBNaXgtVXAgcHJvYmxlbS4NCg0KDQoNClNvLCBoZXJlIGlzIHRoZSBxdWVzdGlvbiBm b3IgdGhlIGdyb3VwLiBXaGljaCBkb2N1bWVudCBkbyB5b3Ugd2FudCBhcyBhIHN0YXJ0aW5nIHBv aW50IGZvciB3b3JrIG9uIHRoaXMgdG9waWM6DQoNCg0KDQotLSBPcHRpb24gQTogJ09BdXRoIDIu MCBNaXgtVXAgTWl0aWdhdGlvbicgYnkgTWlrZSBKb25lcyBhbmQgSm9obiBCcmFkbGV5DQoNCg0K DQpMaW5rOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgt bWl4LXVwLW1pdGlnYXRpb24tMDENCg0KDQoNCi0tIE9wdGlvbiBCOiAnT0F1dGggUmVzcG9uc2Ug TWV0YWRhdGEnIGJ5IE5hdCBTYWtpbXVyYSwgTm92IE1hdGFrZSBhbmQgU2FzY2hhIFByZWliaXNj aA0KDQoNCg0KTGluazoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2lt dXJhLW9hdXRoLW1ldGEtMDcNCg0KDQoNCkRlYWRsaW5lIGZvciBmZWVkYmFjayBpcyBNYXJjaCwg NHRoLg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMgJiBEZXJlaw0KDQoNCg0KUFM6ICgqKSBSZWdhcmRs ZXNzIG9mIHRoZSBzZWxlY3RlZCBzb2x1dGlvbiB3ZSB3aWxsIHByb3ZpZGUgcHJvcGVyIGFja25v d2xlZGdlbWVudCBmb3IgdGhvc2Ugd2hvIGNvbnRyaWJ1dGVkIHRvIHRoZSB3b3JrLg0KDQoNCg== --_000_BY2PR03MB442E9BF84AFA890378C5116F5A00BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PcHRpb24gQS4mbmJzcDsgSSBoYXZlIGhp Z2hlciBjb25maWRlbmNlIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIHNvbHZlcyB0aGUgcHJvYmxl bXMgYmVjYXVzZSBpdCB3YXMgZGVzaWduZWQgZHVyaW5nIGEgNC1kYXkgc2VjdXJpdHkgbWVldGlu ZyBkZWRpY2F0ZWQgdG8gdGhpcyB0YXNrIGJ5IGEgZ3JvdXAgb2Ygb3ZlciAyMCBPQXV0aCBzZWN1 cml0eSBleHBlcnRzLA0KPGI+aW5jbHVkaW5nIGJvdGggc2V0cyBvZiByZXNlYXJjaGVycyBpbiBH ZXJtYW55IHdobyBvcmlnaW5hbGx5IGlkZW50aWZpZWQgdGhlIHByb2JsZW08L2I+LiZuYnNwOyBU aGlzIHNvbHV0aW9uIGhhcyBhbHNvIGJlZW4gaW1wbGVtZW50ZWQgYW5kIGludGVyb3AgdGVzdGVk IGJ5IFJvbGFuZCBIZWRiZXJnLCBCcmlhbiBDYW1wYmVsbCwgYW5kIEkgYmVsaWV2ZSBvdGhlcnMu Jm5ic3A7IE5vdGUgdGhhdCB0aGUgcmVhc29uIEkgYW0gYWR2b2NhdGluZyB0aGlzIHNwZWNpZmlj YXRpb24NCiBpcyAqPGI+bm90PC9iPiogYmVjYXVzZSBJJ20gYW4gZWRpdG9yIG9mIGl0OyBteSBy b2xlIHdhcyB0byByZWNvcmQgaW4gc3BlYyBsYW5ndWFnZSB3aGF0IHRoZSBPQXV0aCBzZWN1cml0 eSBleHBlcnRzIGRlc2lnbmVkIHRvZ2V0aGVyIG92ZXIgdGhlIDQtZGF5IHBlcmlvZCBpbiBEYXJt c3RhZHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPknigJlsbCBhbHNvIG5vdGUgdGhh dCBldmVuIGlmIE9wdGlvbiBCIGFsc28gc29sdmVzIHRoZSBwcm9ibGVtLCBpdCBjb21lcyBhdCBz aWduaWZpY2FudCBhZG9wdGlvbiBjb3N0cyBhbmQgY29tcGxleGl0eSBub3QgZm91bmQgaW4gQS4m bmJzcDsgSW4gcGFydGljdWxhciwgaXQgcmVxdWlyZXMgdGhhdCBkZXZlbG9wZXJzIHVuZGVyc3Rh bmQgc3VwcG9ydCBhIG5ldyDigJxMaW5rIFJlbGF0aW9u4oCdIHN5bnRheCBub3QgdXNlZA0KIGVs c2V3aGVyZSBpbiBPQXV0aC4mbmJzcDsgQXMgTmF0IHdyaXRlcyBhYm91dCBoaXMgb3duIGRyYWZ0 IGluIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j dXJyZW50L21zZzE1Nzg5Lmh0bWwiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29hdXRoL2N1cnJlbnQvbXNnMTU3ODkuaHRtbDwvYT4gLSB0aGVyZSBpcyBub3QgYSBzdGFu ZGFyZCBKU09OIHN5bnRheCBmb3IgbGluayByZWxhdGlvbnMuJm5ic3A7IEhlIHdyaXRlcyDigJx3 ZSBjb3VsZCBlYXNpbHkgY3JlYXRlIGEgcGFyYWxsZWwgdG8gaXTigJ0uJm5ic3A7IEnigJlkIHJh dGhlciB3ZSBzb2x2ZSB0aGUgcHJvYmxlbSB1c2luZyBzdGFuZGFyZCBtZWNoYW5pc21zIGFscmVh ZHkgZW1wbG95ZWQNCiBpbiBPQXV0aCwgcmF0aGVyIHRoYW4gcmlzayBiaWZ1cmNhdGluZyBPQXV0 aCBpbiB0aGUgZGV2ZWxvcGVyIGNvbW11bml0eSBieSB1bm5lY2Vzc2FyaWx5IGludmVudGluZy9j cmVhdGluZyBuZXcgc3ludGF4IHRoYXQgaXMgdW5mYW1pbGlhciB0byBkZXZlbG9wZXJzIGFuZCB0 aGF0IG1hbnkgb2YgdGhlbSBtYXkgcmVqZWN0IHVzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QLlMuJm5ic3A7 IEluZm9ybWF0aW9uIGFib3V0IHRoZSBPQXV0aCBzZWN1cml0eSBtZWV0aW5nIGNhbiBiZSBmb3Vu ZCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xMzZDejJp d1VGTWRvS1daUENxWlJoa21mbUhBbEo2a001T3llWHpHcHRVNC9lZGl0Ij4NCmh0dHBzOi8vZG9j cy5nb29nbGUuY29tL2RvY3VtZW50L2QvMTM2Q3oyaXdVRk1kb0tXWlBDcVpSaGttZm1IQWxKNmtN NU95ZVh6R3B0VTQvZWRpdDwvYT4gYW5kDQo8YSBocmVmPSJodHRwczovL2RvY3MuZ29vZ2xlLmNv bS9kb2N1bWVudC9kLzFjUmExMUVnaW1uVGVKWlIxLVBVcE5ScGlfdV9Fb1NwTzVOdGFrVmJBX3Nr L2VkaXQiPg0KaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xY1JhMTFFZ2ltblRl SlpSMS1QVXBOUnBpX3VfRW9TcE81TnRha1ZiQV9zay9lZGl0PC9hPiAuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSAxOSwgMjAxNiAxMTo0MyBBTTxicj4NClRvOiBvYXV0aEBpZXRmLm9yZzxicj4NClN1Ympl Y3Q6IFtPQVVUSC1XR10gRml4aW5nIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNaXgtVXA6IENh bGwgZm9yIEFkb3B0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5FYXJseSBGZWJydWFyeSBJIHBvc3Rl ZCBhIG1haWwgdG8gdGhlIGxpc3QgdG8gbWFrZSBwcm9ncmVzcyBvbiB0aGUgc29sdXRpb24gdG8g dGhlIE9BdXRoIEF1dGhvcml6YXRpb24gU2VydmVyIE1peC1VcCBwcm9ibGVtIGRpc2NvdmVyZWQg bGF0ZSBsYXN0IHllYXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhlcmUgaXMgbXkg bWFpbCBhYm91dCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWl4LVVwOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzMzYuaHRtbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1MzM2Lmh0bWw8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IZXJlIGlzIG15IG1haWwgdG8gdGhlIGxp c3QgdGhhdCB0cmllcyB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb24gc3RhdHVzIGFuZCBhc2tl ZCBhIGZldyBxdWVzdGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTY5Ny5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMTU2OTcuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlVuZm9ydHVuYXRlbHksIG15IG1haWwgZGlkbid0IGxlYWQgdG8gdGhlIGludGVuZGVk IHN1Y2Nlc3MuIFdoaWxlIHRoZXJlIHdhcyBzb21lIGZlZWRiYWNrIEkgd2Fzbid0IGdldHRpbmcg dGhlIGRlc2lyZWQgcmVzcG9uc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIG9y ZGVyIHRvIG1vdmUgZm9yd2FyZCBJIGJlbGlldmUgd2UgbmVlZCBhIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQgdGhhdCBzZXJ2ZXMgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgZnVydGhlciB3b3JrIGlu IHRoZSBncm91cCouIFdlIGhhdmUgdHdvIGRvY3VtZW50cyB0aGF0IHByb3ZpZGUgc2ltaWxhciBm dW5jdGlvbmFsaXR5IGluIGFuIGF0dGVtcHQgdG8gc29sdmUgdGhlIEF1dGhvcml6YXRpb24gU2Vy dmVyDQogTWl4LVVwIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNvLCBo ZXJlIGlzIHRoZSBxdWVzdGlvbiBmb3IgdGhlIGdyb3VwLiBXaGljaCBkb2N1bWVudCBkbyB5b3Ug d2FudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIG9uIHRoaXMgdG9waWM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPi0tIE9wdGlvbiBBOiAnT0F1dGggMi4wIE1peC1VcCBNaXRp Z2F0aW9uJyBieSBNaWtlIEpvbmVzIGFuZCBKb2huIEJyYWRsZXk8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+TGluazo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1t aXgtdXAtbWl0aWdhdGlvbi0wMSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1v YXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0tIE9wdGlvbiBCOiAnT0F1dGggUmVzcG9uc2UgTWV0YWRhdGEnIGJ5IE5hdCBT YWtpbXVyYSwgTm92IE1hdGFrZSBhbmQgU2FzY2hhIFByZWliaXNjaDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5MaW5rOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9h dXRoLW1ldGEtMDciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgt bWV0YS0wNzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRlYWRsaW5l IGZvciBmZWVkYmFjayBpcyBNYXJjaCwgNHRoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IYW5uZXMgJmFt cDsgRGVyZWs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UFM6ICgqKSBSZWdhcmRsZXNz IG9mIHRoZSBzZWxlY3RlZCBzb2x1dGlvbiB3ZSB3aWxsIHByb3ZpZGUgcHJvcGVyIGFja25vd2xl ZGdlbWVudCBmb3IgdGhvc2Ugd2hvIGNvbnRyaWJ1dGVkIHRvIHRoZSB3b3JrLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442E9BF84AFA890378C5116F5A00BY2PR03MB442namprd_-- From nobody Fri Feb 19 12:39:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE301B341E for ; Fri, 19 Feb 2016 12:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e4km9go0jAm for ; Fri, 19 Feb 2016 12:39:50 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A3F1B31F3 for ; Fri, 19 Feb 2016 12:39:49 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id b205so83492601wmb.1 for ; Fri, 19 Feb 2016 12:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=X+hEEUCe76WrkgE2/N3aeFfUD18Nzxc+Ve+o2hjyiyw=; b=jcZGyETwPADAg9/ltW/mNpv1CPNfLdhEc9gyDUx46lmDkkPPa0h0GJNqH40jsUWTxv X15r8ixkBANpAcw2I/8Th/wbmlZebkSSP/FEf9nxlZDwfZxa/NxSsB+/AAb2fdsZANOM jIJHv73rNHLAPRZqR++j3pvuzD4c57Q5DzuGA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=X+hEEUCe76WrkgE2/N3aeFfUD18Nzxc+Ve+o2hjyiyw=; b=D12ua8cEUlT3NwXkuUZhCZ+lg6bT8BgkgDN0TfQW5/IJqmHy6ZzW95mHihcc+7aoF3 AMYGH9I8in3SeNWcqJWLX9Z9zAyLV8AxsyUYMsNwHqG7jaBMU2tu1Kc1MZYe8XwGHqg0 4m4121U7e+51PkJwQDy0IwKDI/verHiNr/N/hNyyhutkY4JoOr6ODWsG8piZPklM06pU JxSKn82Ywm3be+h1G4F1Nc7bBrPm6Sfkr47naOXz+3blX8rPWgvwFgDYdaDr+8Lmyeu4 hqQmjo6YGCYl2biVPjzkgOHtfHzy6UuQ7dDIT9+bd1bVR4XdEkZ+oE93WONMRj35pzkU dsUw== X-Gm-Message-State: AG10YOQOlZcj9RQ3XwB4nFxyNvH4faLfRo6Fc29EXYJc5ya78quD0I+5HOwYb3w7D+K5xqVU X-Received: by 10.28.9.71 with SMTP id 68mr10974844wmj.33.1455914388318; Fri, 19 Feb 2016 12:39:48 -0800 (PST) Received: from [192.168.10.222] (5ED5277C.cm-7-6a.dynamic.ziggo.nl. [94.213.39.124]) by smtp.gmail.com with ESMTPSA id 8sm9159580wmk.13.2016.02.19.12.39.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 12:39:47 -0800 (PST) To: Mike Jones , Hannes Tschofenig , "oauth@ietf.org" References: <56C7702B.2000401@gmx.net> From: Hans Zandbelt Message-ID: <56C77D92.5050203@pingidentity.com> Date: Fri, 19 Feb 2016 21:39:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 20:39:52 -0000 Option A: I agree with Mike that the complexity and implementation cost of Option B will make adoption harder, which was also a concern with the first iteration of Option A. To be honest, I'm not sure most people would even understand why the complexity would be required and just forget about it. At least with the simplicity of the most recent option A they don't have to care, just add some simple parameters/checks. And for the record: I've also implemented option A in the mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and NGINX respectively. Hans. [1] https://github.com/pingidentity/mod_auth_openidc [2] https://github.com/pingidentity/lua-resty-openidc On 2/19/16 9:18 PM, Mike Jones wrote: > Option A. I have higher confidence that this specification solves the > problems because it was designed during a 4-day security meeting > dedicated to this task by a group of over 20 OAuth security experts, > *including both sets of researchers in Germany who originally identified > the problem*. This solution has also been implemented and interop > tested by Roland Hedberg, Brian Campbell, and I believe others. Note > that the reason I am advocating this specification is **not** because > I'm an editor of it; my role was to record in spec language what the > OAuth security experts designed together over the 4-day period in Darmstadt. > > I’ll also note that even if Option B also solves the problem, it comes > at significant adoption costs and complexity not found in A. In > particular, it requires that developers understand support a new “Link > Relation” syntax not used elsewhere in OAuth. As Nat writes about his > own draft in > http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there > is not a standard JSON syntax for link relations. He writes “we could > easily create a parallel to it”. I’d rather we solve the problem using > standard mechanisms already employed in OAuth, rather than risk > bifurcating OAuth in the developer community by unnecessarily > inventing/creating new syntax that is unfamiliar to developers and that > many of them may reject using. > > -- Mike > > P.S. Information about the OAuth security meeting can be found at > https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit > and > https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit > . > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Friday, February 19, 2016 11:43 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for > Adoption > > Early February I posted a mail to the list to make progress on the > solution to the OAuth Authorization Server Mix-Up problem discovered > late last year. > > Here is my mail about the Authorization Server Mix-Up: > > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html > > Here is my mail to the list that tries to summarize the discussion > status and asked a few questions: > > http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html > > Unfortunately, my mail didn't lead to the intended success. While there > was some feedback I wasn't getting the desired response. > > In order to move forward I believe we need a working group document that > serves as a starting point for further work in the group*. We have two > documents that provide similar functionality in an attempt to solve the > Authorization Server Mix-Up problem. > > So, here is the question for the group. Which document do you want as a > starting point for work on this topic: > > -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley > > Link: > > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 > > -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and > Sascha Preibisch > > Link: > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 > > Deadline for feedback is March, 4th. > > Ciao > > Hannes & Derek > > PS: (*) Regardless of the selected solution we will provide proper > acknowledgement for those who contributed to the work. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Fri Feb 19 13:59:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A311B2CE9 for ; Fri, 19 Feb 2016 13:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S4t1dmm2EiD for ; Fri, 19 Feb 2016 13:59:37 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B159D1B2C87 for ; Fri, 19 Feb 2016 13:59:35 -0800 (PST) X-AuditID: 12074425-51bff70000000210-72-56c790436849 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6D.CA.00528.34097C65; Fri, 19 Feb 2016 16:59:32 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1JLxVcr022234 for ; Fri, 19 Feb 2016 16:59:31 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1JLxUtB018826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 19 Feb 2016 16:59:31 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 19 Feb 2016 16:59:32 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixG6nousy4XiYwYvZTBYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxryWbqaCXewVv25kNDAuYOti5OSQEDCRuPXkInMXIxeHkEAb k8SP9kMsEM4xRom/r14zQjjfmCTWdP1hBGlhE1CVmL/yFhOIzSygLvFn3iVmCFtbYtnC12C2 MFDN9G8fWEBsXgEriS3dF9hBbBag+KfOnawgtghQ75rzP5kgavQkXt26zApxkqzE7t+PmCYw 8s5CsmIWkhWzkLQsYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERxMLqo7 GCccUjrEKMDBqMTDeyP5eJgQa2JZcWXuIUZJDiYlUd6USqAQX1J+SmVGYnFGfFFpTmrxIUYJ DmYlEd79vUA53pTEyqrUonyYlDQHi5I4b8zNo2FCAumJJanZqakFqUUwWRkODiUJ3tn9QI2C RanpqRVpmTklCGkmDk6Q4TxAw5NBaniLCxJzizPTIfKnGHU5Fvy4vZZJiCUvPy9VSpzXAKRI AKQoozQPbg4oCSS8PWz6ilEc6C1h3rcgVTzABAI36RXQEiagJfemHQNZUpKIkJJqYIwOd30+ qzzm56z3C7bN2vhqg/uywF/SQvLRxfOWxZ694tnBtPVEWr/31+psP42z1dOevjjwlTu49sGb 0sfnuUvisibx/tZacDr4Kk/s62uzrB5/5GI/bvTKKj9z29L5qR/N/xk7nudylZaa8Lo3PMv0 JkPfHwfZwFTuLVP0D851ecmoy8x7jlGJpTgj0VCLuag4EQA77w5Y3QIAAA== Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 21:59:40 -0000 The newly-trimmed OAuth Discovery document is helpful and moving in the = right direction. It does, however, still have too many vestiges of its = OpenID Connect origins. One issue in particular still really bothers me: = the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the = discovery portion. Is this an OAuth discovery document, or an OpenID = Connect one? There is absolutely no compelling reason to tie the URL to = the OIDC discovery mechanism. I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80= =9D as the default discovery location, and state that the document MAY = also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D= if the server also provides OpenID Connect on the same domain. Other = applications SHOULD use the same parameter names to describe OAuth = endpoints and functions inside their service-specific discovery = document.=20 =E2=80=94 Justin= From nobody Fri Feb 19 20:28:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB071B39AD for ; Fri, 19 Feb 2016 20:28:10 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXA48d7rqHnt for ; Fri, 19 Feb 2016 20:28:09 -0800 (PST) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C0A1B3987 for ; Fri, 19 Feb 2016 20:28:09 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-03.prod.phx3.secureserver.net with id LUU71s00515ZTut01UU8hS; Fri, 19 Feb 2016 21:28:09 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <56C7EB56.3040906@connect2id.com> Date: Sat, 20 Feb 2016 06:28:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000706070507020109070904" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 04:28:11 -0000 This is a cryptographically signed message in MIME format. --------------ms000706070507020109070904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 On 19/02/16 23:59, Justin Richer wrote: > The newly-trimmed OAuth Discovery document is helpful and moving in the= right direction. It does, however, still have too many vestiges of its O= penID Connect origins. One issue in particular still really bothers me: t= he use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the disc= overy portion. Is this an OAuth discovery document, or an OpenID Connect = one? There is absolutely no compelling reason to tie the URL to the OIDC = discovery mechanism. > > I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2= =80=9D as the default discovery location, and state that the document MAY= also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D= if the server also provides OpenID Connect on the same domain. Other app= lications SHOULD use the same parameter names to describe OAuth endpoints= and functions inside their service-specific discovery document.=20 > > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------ms000706070507020109070904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjAwNDI4MDZaMC8GCSqGSIb3DQEJBDEiBCDNZO+NEz3aFh1f1bp0Zf3fIhRQl7ge YrRf7Bh/Io4s7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCARkaa0o25 g39uqgQjtDq9OBElbDdHpA0gIYmpZqLdifpku2jsret/ax3EBEMGXbj38CIStRCqmU0QmSD2 VXNkNmC8m8kv9Dho4gMsC0mnmAPmp1sbl71dv9D30pYlYx2/NH9SqGChbMDpg0nU3vR5Kctb j3B6bD78JPVatT8rmX4ZczwM/63fOW3/vRtUTMRn89Dv9xaFwNqXiAkq9aE4jNFhFHH95zj2 1xDK2dowFWk4+bNBnvgKIlSNMt3qXgJfJXgtkcWEaUmMxL6ia0gFRCinGyQe5354O5UJsRRh w+y7A1F0MEd0n2PqO1IxGs6t4TBvseVcd7zoW09euXxlAAAAAAAA --------------ms000706070507020109070904-- From nobody Fri Feb 19 21:12:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF41B3802 for ; Fri, 19 Feb 2016 21:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGlP3IT9DLZ3 for ; Fri, 19 Feb 2016 21:12:37 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517BC1B38B3 for ; Fri, 19 Feb 2016 21:12:33 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1K5CUIM000852 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Feb 2016 05:12:31 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1K5CU7A030043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 Feb 2016 05:12:30 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1K5CRr9019809; Sat, 20 Feb 2016 05:12:30 GMT Received: from [25.173.105.41] (/72.143.227.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Feb 2016 21:12:27 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <56C77D92.5050203@pingidentity.com> Date: Fri, 19 Feb 2016 22:12:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> To: Hans Zandbelt X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 05:12:40 -0000 Option A Phil > On Feb 19, 2016, at 13:39, Hans Zandbelt wrot= e: >=20 > Option A: I agree with Mike that the complexity and implementation cost of= Option B will make adoption harder, which was also a concern with the first= iteration of Option A. >=20 > To be honest, I'm not sure most people would even understand why the compl= exity would be required and just forget about it. At least with the simplici= ty of the most recent option A they don't have to care, just add some simple= parameters/checks. >=20 > And for the record: I've also implemented option A in the mod_auth_openidc= [1] and lua-resty-openidc [2] clients for Apache and NGINX respectively. >=20 > Hans. >=20 > [1] https://github.com/pingidentity/mod_auth_openidc > [2] https://github.com/pingidentity/lua-resty-openidc >=20 >> On 2/19/16 9:18 PM, Mike Jones wrote: >> Option A. I have higher confidence that this specification solves the >> problems because it was designed during a 4-day security meeting >> dedicated to this task by a group of over 20 OAuth security experts, >> *including both sets of researchers in Germany who originally identified >> the problem*. This solution has also been implemented and interop >> tested by Roland Hedberg, Brian Campbell, and I believe others. Note >> that the reason I am advocating this specification is **not** because >> I'm an editor of it; my role was to record in spec language what the >> OAuth security experts designed together over the 4-day period in Darmsta= dt. >>=20 >> I=E2=80=99ll also note that even if Option B also solves the problem, it c= omes >> at significant adoption costs and complexity not found in A. In >> particular, it requires that developers understand support a new =E2=80=9C= Link >> Relation=E2=80=9D syntax not used elsewhere in OAuth. As Nat writes abou= t his >> own draft in >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there >> is not a standard JSON syntax for link relations. He writes =E2=80=9Cwe c= ould >> easily create a parallel to it=E2=80=9D. I=E2=80=99d rather we solve the= problem using >> standard mechanisms already employed in OAuth, rather than risk >> bifurcating OAuth in the developer community by unnecessarily >> inventing/creating new syntax that is unfamiliar to developers and that >> many of them may reject using. >>=20 >> -- Mike >>=20 >> P.S. Information about the OAuth security meeting can be found at >> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeX= zGptU4/edit >> and >> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5Ntak= VbA_sk/edit >> . >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g >> Sent: Friday, February 19, 2016 11:43 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for >> Adoption >>=20 >> Early February I posted a mail to the list to make progress on the >> solution to the OAuth Authorization Server Mix-Up problem discovered >> late last year. >>=20 >> Here is my mail about the Authorization Server Mix-Up: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >>=20 >> Here is my mail to the list that tries to summarize the discussion >> status and asked a few questions: >>=20 >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >>=20 >> Unfortunately, my mail didn't lead to the intended success. While there >> was some feedback I wasn't getting the desired response. >>=20 >> In order to move forward I believe we need a working group document that >> serves as a starting point for further work in the group*. We have two >> documents that provide similar functionality in an attempt to solve the >> Authorization Server Mix-Up problem. >>=20 >> So, here is the question for the group. Which document do you want as a >> starting point for work on this topic: >>=20 >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley= >>=20 >> Link: >>=20 >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >>=20 >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and >> Sascha Preibisch >>=20 >> Link: >>=20 >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >>=20 >> Deadline for feedback is March, 4th. >>=20 >> Ciao >>=20 >> Hannes & Derek >>=20 >> PS: (*) Regardless of the selected solution we will provide proper >> acknowledgement for those who contributed to the work. >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Feb 20 00:49:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3E1A1ADB for ; Sat, 20 Feb 2016 00:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 AEmabRux083e for ; Sat, 20 Feb 2016 00:49:28 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 941721A1AE3 for ; Sat, 20 Feb 2016 00:49:28 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id gc3so127163314obb.3 for ; Sat, 20 Feb 2016 00:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6KDpHbFlgI3EObrV1JAZzpDdaHxmJqADECxBYiAkM4E=; b=Ek2LHFrrLJ9Ud9CCL8E4Rgr493w7+tYdLqxGQFGNpVw2xz/idXxQ+ctZqNCX7LlSl7 gFxrowZjqdk4Xfa8tS0Sp+5ZsypvesxdiZ/Qz4o6/BZKS4xUSdFa+UpOD8YekChad4/j CDG3kIDWrlzwgXekMzOaP/hUnc8S1OlCgmK+8CA+u72eCNU3wgZiL73qiHFDJWwHLL5Q USYjsvUk6kX03imSgbOoMbJYIEC4WWbLRxGatGfqYM4MTIbzQNziIGYfOGG+lnsv0zIx ZNH7rqIjFPm7wb14pCRJpX8L3Nouevw4CFUfDrl+DBazIuy+l7uSvyaKJiVIdEp8dfB3 TUJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6KDpHbFlgI3EObrV1JAZzpDdaHxmJqADECxBYiAkM4E=; b=Ci+Q0rZM7AGkUQerQg43k8G3wTIz5Av3sVdTERl8r7SfIUkAqmHVYCM/bmPe0WDVVB aW0j5SK45bFT6nk5HdzE35zE9FCc7xMGCVOf08UQO2ETlNpQOBmltT4O7wNnlaltace4 ZS4+r8bin1fl24Wx5G7+rU+Zdwmqi4W+nD7p7F2Ae3upa8Y11ZmEn/0GkIuIlVaba1eg VpZ+PvGTMrQmkrO7+AE7HRzM3REVhZmz51ToqiP/CGab8Go1ByGzNye7XdlBAIh6uGGZ ZQaPjgK8xWf0dn5AFOP0aV/9iBfK2G1U/K8oV3/OZJWQngTdYLGyxarFPMFvhtCE6f/N q55Q== X-Gm-Message-State: AG10YOS0GoxVxivr931r7GSsibOmddhDq3AQ5SyxRk7iWTQ6vS4+LnO/vmu3ku2mjmGwhTFMOrlsHMjhDg4ZEPXk X-Received: by 10.60.226.163 with SMTP id rt3mr14905510oec.11.1455958167845; Sat, 20 Feb 2016 00:49:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Sat, 20 Feb 2016 00:49:08 -0800 (PST) In-Reply-To: <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> From: William Denniss Date: Sat, 20 Feb 2016 00:49:08 -0800 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a11369a06674b54052c2fad42 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 08:49:31 -0000 --001a11369a06674b54052c2fad42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maybe it's because I wasn't at the Darmstadt meeting so I don't have the full context, but I don't find draft A to be all that clear. Here's my review feedback: Regarding the text "a client may be confused simply because it is receiving authorization responses from more than one authorization server at the same redirection endpoint". Even if the client re-uses the same redirection endpoint, shouldn't state solve this? All incoming responses should have an outgoing request with a matching state that would identify the authorization request and therefore authorization server. For the issue of dynamic discovery and the potential to insert a malicious discovery document: can the recommendation be to use the hybrid flow of Connect if you do discovery (and validate the issuer before exchanging the code)? Do we need to invent something new for this use-case? Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint"), this describes something that seems similar to what is achieved by PKCE (RFC7636). Binding information to the authorization code that must be presented to redeem the code is precisely what PKCE does, and PKCE has additional security properties. With the PKCE S256 challenge method, the authorization request and response can leak in their entirety, and yet still the attacker couldn't exchange the authorization code. Let's just recommend RFC7636 for this mitigation. The security researcher documents are only informative references, and yet the spec seems to rely on them normatively. E.g.: * "Mitigating the attacks also relies on the client sending additional data about the interaction to the token endpoint" (how does this mitigate the attacks? and what attack exactly?). * "a client may be confused simply because it is receiving authorization responses from more than one authorization server" (why is the client confused?) I would like to see the attacks normatively described in the spec. For my own knowledge: what are some of the use-cases that are subject to these attacks? I'm not convinced every RP that talks to more than 1 AS is at risk today. What are some risky situations that exist which are mitigated by this draft? On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) wrote: > Option A > > Phil > > > On Feb 19, 2016, at 13:39, Hans Zandbelt > wrote: > > > > Option A: I agree with Mike that the complexity and implementation cost > of Option B will make adoption harder, which was also a concern with the > first iteration of Option A. > > > > To be honest, I'm not sure most people would even understand why the > complexity would be required and just forget about it. At least with the > simplicity of the most recent option A they don't have to care, just add > some simple parameters/checks. > > > > And for the record: I've also implemented option A in the > mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and NGI= NX > respectively. > > > > Hans. > > > > [1] https://github.com/pingidentity/mod_auth_openidc > > [2] https://github.com/pingidentity/lua-resty-openidc > > > >> On 2/19/16 9:18 PM, Mike Jones wrote: > >> Option A. I have higher confidence that this specification solves the > >> problems because it was designed during a 4-day security meeting > >> dedicated to this task by a group of over 20 OAuth security experts, > >> *including both sets of researchers in Germany who originally identifi= ed > >> the problem*. This solution has also been implemented and interop > >> tested by Roland Hedberg, Brian Campbell, and I believe others. Note > >> that the reason I am advocating this specification is **not** because > >> I'm an editor of it; my role was to record in spec language what the > >> OAuth security experts designed together over the 4-day period in > Darmstadt. > >> > >> I=E2=80=99ll also note that even if Option B also solves the problem, = it comes > >> at significant adoption costs and complexity not found in A. In > >> particular, it requires that developers understand support a new =E2= =80=9CLink > >> Relation=E2=80=9D syntax not used elsewhere in OAuth. As Nat writes a= bout his > >> own draft in > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - > there > >> is not a standard JSON syntax for link relations. He writes =E2=80=9C= we could > >> easily create a parallel to it=E2=80=9D. I=E2=80=99d rather we solve = the problem using > >> standard mechanisms already employed in OAuth, rather than risk > >> bifurcating OAuth in the developer community by unnecessarily > >> inventing/creating new syntax that is unfamiliar to developers and tha= t > >> many of them may reject using. > >> > >> -- Mike > >> > >> P.S. Information about the OAuth security meeting can be found at > >> > https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeX= zGptU4/edit > >> and > >> > https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5Ntak= VbA_sk/edit > >> . > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > >> Sent: Friday, February 19, 2016 11:43 AM > >> To: oauth@ietf.org > >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for > >> Adoption > >> > >> Early February I posted a mail to the list to make progress on the > >> solution to the OAuth Authorization Server Mix-Up problem discovered > >> late last year. > >> > >> Here is my mail about the Authorization Server Mix-Up: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html > >> > >> Here is my mail to the list that tries to summarize the discussion > >> status and asked a few questions: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html > >> > >> Unfortunately, my mail didn't lead to the intended success. While ther= e > >> was some feedback I wasn't getting the desired response. > >> > >> In order to move forward I believe we need a working group document th= at > >> serves as a starting point for further work in the group*. We have two > >> documents that provide similar functionality in an attempt to solve th= e > >> Authorization Server Mix-Up problem. > >> > >> So, here is the question for the group. Which document do you want as = a > >> starting point for work on this topic: > >> > >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John > Bradley > >> > >> Link: > >> > >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 > >> > >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and > >> Sascha Preibisch > >> > >> Link: > >> > >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 > >> > >> Deadline for feedback is March, 4th. > >> > >> Ciao > >> > >> Hannes & Derek > >> > >> PS: (*) Regardless of the selected solution we will provide proper > >> acknowledgement for those who contributed to the work. > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Hans Zandbelt | Sr. Technical Architect > > hzandbelt@pingidentity.com | Ping Identity > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11369a06674b54052c2fad42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe it's because I wasn't at the Darmstadt = meeting so I don't have the full context, but I don't find draft A=C2=A0to be all that clear. Here's my review = feedback:

Regarding the text "a client may be conf= used simply because it is receiving authorization responses from more than = one authorization server at the same redirection endpoint". Even if th= e client re-uses the same redirection endpoint, shouldn't state solve t= his? All incoming responses should have an outgoing request with a matching= state that would identify the authorization request and therefore authoriz= ation server.

For the issue of dynamic= discovery and the potential to insert a malicious discovery document: can = the recommendation be to use the hybrid flow of Connect if you do discovery= (and validate the issuer before exchanging the code)?=C2=A0 Do we need to = invent something new for this use-case?

Regarding se= ctions 5 & 6 ("Mitigation Data Sent to the Token Endpoint"), = this describes something that seems similar to what is achieved by PKCE (RF= C7636). Binding information to the authorization code that must be presente= d to redeem the code is precisely what PKCE does, and PKCE has additional s= ecurity properties. With the PKCE S256 challenge method, the authorization = request and response can leak in their entirety, and yet still the attacker= couldn't exchange the authorization code. Let's just recommend RFC= 7636 for this mitigation.

The security resear= cher documents are only informative references, and yet the spec seems to r= ely on them normatively. E.g.:
* =C2=A0"Mitigating the attac= ks also relies on the client sending additional data about the interaction = to the token endpoint" (how does this mitigate the attacks? and what a= ttack exactly?).
* =C2=A0"a client may be confused simply=C2=A0be= cause it is receiving authorization responses from more than one=C2=A0autho= rization server" =C2=A0(why is the client confused?)
I w= ould like to see the attacks normatively described in the spec.

For my own knowledge: what are some of the use-cases that= are subject to these attacks? I'm not convinced every RP that talks to= more than 1 AS is at risk today. What are some risky situations that exist= which are mitigated by this draft?



On Fri, F= eb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:
>
> Option A: I agree with Mike that the complexity and implementation cos= t of Option B will make adoption harder, which was also a concern with the = first iteration of Option A.
>
> To be honest, I'm not sure most people would even understand why t= he complexity would be required and just forget about it. At least with the= simplicity of the most recent option A they don't have to care, just a= dd some simple parameters/checks.
>
> And for the record: I've also implemented option A in the mod_auth= _openidc [1] and lua-resty-openidc [2] clients for Apache and NGINX respect= ively.
>
> Hans.
>
> [1] https://github.com/pingidentity/mod_auth_= openidc
> [2] https://github.com/pingidentity/lua-resty= -openidc
>
>> On 2/19/16 9:18 PM, Mike Jones wrote:
>> Option A.=C2=A0 I have higher confidence that this specification s= olves the
>> problems because it was designed during a 4-day security meeting >> dedicated to this task by a group of over 20 OAuth security expert= s,
>> *including both sets of researchers in Germany who original= ly identified
>> the problem*.=C2=A0 This solution has also been implemented and in= terop
>> tested by Roland Hedberg, Brian Campbell, and I b= elieve others.=C2=A0 Note
>> that the reason I am advocating this specification is **not= ** because
>> I'm an editor of it; my role was to rec= ord in spec language what the
>> OAuth security experts designed together over the 4-day period in = Darmstadt.
>>
>> I=E2=80=99ll also note that even if Option B also solves the probl= em, it comes
>> at significant adoption costs and complexity not found in A.=C2=A0= In
>> particular, it requires that developers understand support a new = =E2=80=9CLink
>> Relation=E2=80=9D syntax not used elsewhere in OAuth.=C2=A0 As Nat= writes about his
>> own draft in
>> http://www.ietf.org/mail-ar= chive/web/oauth/current/msg15789.html - there
>> is not a standard JSON syntax for link relations.=C2=A0 He writes = =E2=80=9Cwe could
>> easily create a parallel to it=E2=80=9D.=C2=A0 I=E2=80=99d rather = we solve the problem using
>> standard mechanisms already employed in OAuth, rather than risk >> bifurcating OAuth in the developer community by unnecessarily
>> inventing/creating new syntax that is unfamiliar to developers and= that
>> many of them may reject using.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mik= e
>>
>> P.S.=C2=A0 Information about the OAuth security meeting can be fou= nd at
>> https:/= /docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/ed= it
>> and
>> https:/= /docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/ed= it
>> .
>>
>> -----Original Message-----
>> From: OAuth [mailto:oaut= h-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Friday, February 19, 2016 11:43 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call f= or
>> Adoption
>>
>> Early February I posted a mail to the list to make progress on the=
>> solution to the OAuth Authorization Server Mix-Up problem discover= ed
>> late last year.
>>
>> Here is my mail about the Authorization Server Mix-Up:
>>
>> http://www.ietf.org/mail-ar= chive/web/oauth/current/msg15336.html
>>
>> Here is my mail to the list that tries to summarize the discussion=
>> status and asked a few questions:
>>
>> http://www.ietf.org/mail-ar= chive/web/oauth/current/msg15697.html
>>
>> Unfortunately, my mail didn't lead to the intended success. Wh= ile there
>> was some feedback I wasn't getting the desired response.
>>
>> In order to move forward I believe we need a working group documen= t that
>> serves as a starting point for further work in the group*. We have= two
>> documents that provide similar functionality in an attempt to solv= e the
>> Authorization Server Mix-Up problem.
>>
>> So, here is the question for the group. Which document do you want= as a
>> starting point for work on this topic:
>>
>> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones a= nd John Bradley
>>
>> Link:
>>
>> https://tools.ietf.org/ht= ml/draft-jones-oauth-mix-up-mitigation-01
>>
>> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, No= v Matake and
>> Sascha Preibisch
>>
>> Link:
>>
>> https://tools.ietf.org/html/draft-s= akimura-oauth-meta-07
>>
>> Deadline for feedback is March, 4th.
>>
>> Ciao
>>
>> Hannes & Derek
>>
>> PS: (*) Regardless of the selected solution we will provide proper=
>> acknowledgement for those who contributed to the work.
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> --
> Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Te= chnical Architect
> hzandbelt@pingidentity.c= om | Ping Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--001a11369a06674b54052c2fad42-- From nobody Sat Feb 20 01:46:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8E1A3BA3 for ; Sat, 20 Feb 2016 01:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPiYWyqEAfsX for ; Sat, 20 Feb 2016 01:46:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5054A1A1BE5 for ; Sat, 20 Feb 2016 01:46:49 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LgZRV-1aCWd50bTR-00nwh0; Sat, 20 Feb 2016 10:46:42 +0100 To: William Denniss , "Phil Hunt (IDM)" References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56C8360C.8010203@gmx.net> Date: Sat, 20 Feb 2016 10:46:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CiaBpSqnAoJMDHv3bJ53cXEg6NpQ3StTr" X-Provags-ID: V03:K0:2tFXdpT5bERSOS2/Dkc8QanhONNpknxnO0AeOXyDt1Lsw06CjJh uyFmI94sGW4E1WXiV2E1Ln0LP0cRWLEKZVfS8+rM694NXptP17F97noR3kdECfo8GEAS2Ay 7ReuBukCcTlxSwbNTyNnpbfQZfDRc2wLK+K4977f3KGC3s4FgjF96FbBSgkxMKALjqPaerg yEOmSWzdMXoUXQNkcAgTQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:/tg89MnhD40=:UiGXv0ExQejAY4XmN2dsig L0gvM1H9YUJiLP7dYsGE+lYlbk7m9AafCNyxfy33TM0V9PWbZGajaRNqpM0RCCWbe5Vikgfjg 0OeebD01FOtAp0DXLh7CIVv/Z05qtcJZFO2PGhKbezD60x0PJ2L9LDYDdG8A9bV1wnIjBb10p FAZyCaIbTmB3iRnc1REvqs2ndhr365Xhx7+rL29Nd34qRejmQi4c9vBhrYm2oQ3Kh2F+bwP7l Z+lluSXbeUT1WYW8CLhciiuW3DfmNJ6DD/SsQNy/rCjK///2SwIgJatfDZkNUSouwf+1fmD+1 ftzzms/CEwYzzDUgZrz7UfjzJGMgRQ2BzXYAlqt39nIVRUGPL0FfuDGvpKo4VhE2iroF1J3Xo 09RmNuPas7P7Dxv4OeDyFZDdAZLUKJWYqa7sDrlhakcziyFtQOSp75XVi0m1KPyRZk6FSiQk2 wFnYDmjFNFpry22m+WqUwZOt3F3l570ZiK5625DfOL5955qmp2KAsRwTi9AsxvU3cKrkkhABa fy2Fmirq/Gyl7dqE3hTsAZdAmJnazCNKC5zFdUaLjQJ8y1PZNqgEfWcNFkvqCP4tszMdfss0I HleZT7BPI8iltEBLj1nMrsePPwXRkQzP4xqHHkXy+zsZ2QTZc0gFzLjJg9S8jUWEDYVqIHrJp w2yARZOEuMlOz4mE1qT9GMADj7YC3JFfQPLXnXZEFyt6x3vKqe+yMO6zMcmNqkS76He58bSWC hYGgzu8WSw7qHbas+Gp/Ay9ttq2SFyLecbpdgPbUxh7hPj3bYN3acQGAs6s= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 09:46:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CiaBpSqnAoJMDHv3bJ53cXEg6NpQ3StTr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just a quick reply to two of your remarks: On 02/20/2016 09:49 AM, William Denniss wrote: > The security researcher documents are only informative references I think they should be informative references since the motivate the reason for doing the work but there is nothing in these publications that raises interoperability concerns. I believe the solution documents need to be descriptive enough that they explain the threats so that a reader who does not read through the informative reference section still understands what's going on. > For my own knowledge: what are some of the use-cases that are subject > to these attacks? I'm not convinced every RP that talks to more than > 1 AS is at risk today. What are some risky situations that exist > which are mitigated by this draft? This is something I criticized in my review as well. IMHO the documents could do a better job in describing the threats and particularly the assumptions that need to hold in order for the attacks to work. Without those it will be difficult to inform readers when this is a concern and what level of risk this represents. Ciao Hannes --CiaBpSqnAoJMDHv3bJ53cXEg6NpQ3StTr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWyDYNAAoJEGhJURNOOiAta/oH/j8zUtIOLXuxHNWA9PRzESke JLhDKHyynPzO5lMuiS02/RLR7DDcBwb+JanPazr1j8HF8HV9dSEHnBWNeZQk1Ewu oDLCnhvLa3D1JtK65KVlVtIRLkjkeRWR9VHwOVcb19sYHxrlnVaBXrn0HCGUTB5K dPE02N+MqDfjtQCPovm4E1r0i49uUe0GvoZULVKhHmaX0LnvvXCFQ3pv1nUbAra5 o52QkNhB8RPdauXfj1r9PI7o5eZEkKJ0tZ95IH766iMjfUNomcZmzTPeXOzvS/il 1jv633m/mWWfIfIeX6wZmZnqnngXbe8sPOA+ci/pXLGRW7H2o72Foh6OGku8AbQ= =K1eZ -----END PGP SIGNATURE----- --CiaBpSqnAoJMDHv3bJ53cXEg6NpQ3StTr-- From nobody Sat Feb 20 01:52:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114981A86F6 for ; Sat, 20 Feb 2016 01:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxWpg5StWuJt for ; Sat, 20 Feb 2016 01:52:47 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687EE1A8034 for ; Sat, 20 Feb 2016 01:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bq5K1fQjdK2rS9HDSBO7yI3KixHRnlQb7zPaSBxqz+c=; b=GSfHSyWLM0APtowupyo2Dgt7eBhmgK8FqdkK0L/HrFU7JdmuOwGhnuplO3S7L0RTFX5BoiXj9Iw80lkrWs9mWTsytM9LXPsi9jDmvLwRyINopdXOi9IfcwC+RmMUh57A1F/3gCo/74FER8WmAtFNZPCByB5G7PYBpYyYoxWTaFk= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 09:52:43 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Sat, 20 Feb 2016 09:52:43 +0000 From: Mike Jones To: Hannes Tschofenig , William Denniss , "Phil Hunt (IDM)" Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRa02vcYDFrUX6M06+JVJIk0JwsZ8zyRTAgAALpwCAAI80gIAAPJQAgAAQIQCAAAA+UA== Date: Sat, 20 Feb 2016 09:52:43 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <56C8360C.8010203@gmx.net> In-Reply-To: <56C8360C.8010203@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 6f6bf752-80ed-4b95-29b3-08d339db9454 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:5UwnXNy9v7aWJud+kJvj6cwVX2LEtcaIyRTCa64IPB84Q994KdRg45nzkv0sK6VyOFUpLPV2zkxOhdbl3xLBn5wtmDeE7lfZfbSRSJo/sOlXHVfrinES0aH/fiCzArjDGA2TdTq4u3tF4WVJpH2k+g==; 24:JjcwLtQnFF5lH2Fyv++5ONsnugnYGtw4vfFFTuvWHPsgQfPTGB8N73cSr71joZiBD7fNfxhapnViZPIt/zhrKuuE8la7mDbsYpk3SE9mFas= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(479174004)(377454003)(5003600100002)(40100003)(3280700002)(1096002)(3846002)(10290500002)(586003)(4326007)(1220700001)(2950100001)(122556002)(92566002)(3660700001)(102836003)(2906002)(66066001)(54356999)(50986999)(77096005)(76176999)(93886004)(6116002)(2900100001)(8990500004)(86612001)(5008740100001)(5001960100002)(189998001)(19580395003)(5005710100001)(11100500001)(5004730100002)(10400500002)(99286002)(5002640100001)(19580405001)(33656002)(74316001)(86362001)(87936001)(5001770100001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 09:52:43.6036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 09:52:50 -0000 We can and will bring more of the threat descriptions into the full documen= t. For what it's worth, in the initial versions we referenced the German r= esearcher's threat descriptions but intentionally didn't try to repeat them= in detail in the spec, so that people would read their research publicatio= ns if they wanted to know more. The researchers did the hard work to disco= ver the problems and deserved credit for them. Have you read both of their publications? If not, do yourself a favor and = do. They're actually both very readable and quite informative. Cheers, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, February 20, 2016 1:47 AM To: William Denniss ; Phil Hunt (IDM) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Ad= option Just a quick reply to two of your remarks: On 02/20/2016 09:49 AM, William Denniss wrote: > The security researcher documents are only informative references I think they should be informative references since the motivate the reason= for doing the work but there is nothing in these publications that raises = interoperability concerns. I believe the solution documents need to be descriptive enough that they ex= plain the threats so that a reader who does not read through the informativ= e reference section still understands what's going on. > For my own knowledge: what are some of the use-cases that are subject=20 > to these attacks? I'm not convinced every RP that talks to more than > 1 AS is at risk today. What are some risky situations that exist which=20 > are mitigated by this draft? This is something I criticized in my review as well. IMHO the documents cou= ld do a better job in describing the threats and particularly the assumptio= ns that need to hold in order for the attacks to work. Without those it wil= l be difficult to inform readers when this is a concern and what level of r= isk this represents. Ciao Hannes From nobody Sat Feb 20 02:24:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DB31A87DB for ; Sat, 20 Feb 2016 02:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7I5kxhcbIjl for ; Sat, 20 Feb 2016 02:24:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AB91A88B4 for ; Sat, 20 Feb 2016 02:24:41 -0800 (PST) Received: from [192.168.10.140] ([195.149.218.208]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MbfnB-1aGus63Y7Z-00J47l; Sat, 20 Feb 2016 11:24:32 +0100 To: Mike Jones , William Denniss , "Phil Hunt (IDM)" References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <56C8360C.8010203@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56C83EEA.8000306@gmx.net> Date: Sat, 20 Feb 2016 11:24:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="60Ql5ENl6rgbX9tfT4S3ud2IKWwexUkMK" X-Provags-ID: V03:K0:qVqJdmIUSBrbCSvFnj4JlqhMYKCeB/UfmC0fy+G6IxAUGudqH2l 6NhmH1v9zlLXo5pKnihIoSEU3/8s3s+FfLyhTrzJWVl3icgMwuQvQQLfbSpVhTp30DJ3WhC OQq7PqbZwg164z7JFhYSK+ov3bbSfIEzZbMkoXXOzj43+G81Id7wr03JIRoUht06e8qUBeD rGlAVbLCG40IZW/ZSbDQg== X-UI-Out-Filterresults: notjunk:1;V01:K0:WfoOBeHAA5I=:GcL75PQAwylT/AOHh0Ol+l h9bSUjMV0jA07j4Pfmr1guTei1iD/bqhyBWhsc/66sGP5lArK4cQVE9L9M8YZqeNscdHjTwnN 2mKFEle7zmaGdWUo85P4KDgDIumV1h0BCGQFceCbHPqvq1tLzOZrX2/bYe+FP0q+KvwlBnSuy 2CGHvogiqSruK6bApng6PlhVT4EodEu/sMlJjqBHlkeORJWz5arSTXXmD8huQGss37pBGeEQW n9AF0GfnNIZDtcS9YiCpU5cvRsIsJinKmv0bG+IgUsF1SG9hdC8hJ7DkJ29+6SwLMiFZmzwHU GKmL2vf/bHgoZY9yL3In5atoZ1gzUYtFXRWr2NltOQdXrxpm89/rzwr34NyJUbzfzL91O9HTx wwUcBO1zWbpk3WM+k0LuiMe2TvtzlBHNd6DryO0CnvKcCi5iBZ8MvBwt2Tf7f7ZNqLcOc9vOd flzuXLYiBeAJwQPh/P8aTQi/dDQAI5upBewdMWIYfMv97kOArw2PshfRcR6hPBcAEGj2600zV Vh0f5994FIXfPD+MHFqwNnddOpVtRAsc4QU47sVzPc5DJqksYtReALZgxoNul2grqpMToV9Bn mqkTUanFgw4b7kAmXGuxOrqCsFMXzn1OrbFHRLPXxKvWypDu7OqRh3vKowQniAaQm+yrvX3B6 AXqohGCzPf3cgRYhW+47OyHnB8NDjMoLnV+AOB44b4om245P/pg1dkM9RqXnzKAz1Hsp/gEiZ i8wvOKHMNHdwqOTv+Ky+Hky8SFLq9130CQ2z6aAm27xO3EGJCUOmeq6ajW8= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 10:24:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --60Ql5ENl6rgbX9tfT4S3ud2IKWwexUkMK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, On 02/20/2016 10:52 AM, Mike Jones wrote: > Have you read both of their publications? If not, do yourself a > favor and do. They're actually both very readable and quite > informative. I have read both documents. In context of this discussion the question is whether we (a) require them to be read (in which case they should be a normative reference), or (b) suggest them to be read (since they provide additional background information). In this case they are an informative reference. I believe believe we want (b) for the OAuth WG document. While I encourage everyone to read the publications I also believe that there is lots of material in there that goes beyond the information our audience typically reads (such as the text about the formal analysis). There is probably also a middle-ground where we either copy relevant text from the papers into the draft or reference specific sections that are "must-read". One other issue: I actually thought that the threat that is outlined in the research paper is sufficiently well described but the second threat, which is called 'cut-and-paste attack', requires more work. I noted this in my summary mail to the list, see http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html Ciao Hannes --60Ql5ENl6rgbX9tfT4S3ud2IKWwexUkMK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWyD7rAAoJEGhJURNOOiAtmyoH/1NY+gBrwuyl+YBBld2net05 4dnS8xtTi+2bWw5pytrJDWisMEvTS3k6hIMFTRNcOXkxHSz1vfOitP5PAYwA91TX my8cEMCg2IfECo6fcxACNSKYz0BeBuMlHKdURRWyZX/5eXZz2wRbb4dyQDqffe9K k/37o4wzcSNnRsqWlQ+LFPH9ZJG7v3N3U4c9fouEq/83dfGmzJFSrGwW2lQevH2J cKmoMuNevLlQUMNKYAZ7g6QvaWOhTnBxPiosYkCYTfp0Wk5rarJu+JXOzsInsSUn Lh0fFyE8iJe0XwC3BdAso35vxM6na0ZTFtJpHlzCzOCGL8tdyCEQ0NDBgaVjvI0= =z2/Z -----END PGP SIGNATURE----- --60Ql5ENl6rgbX9tfT4S3ud2IKWwexUkMK-- From nobody Sat Feb 20 02:41:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474FA1A871B for ; Sat, 20 Feb 2016 02:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF7fB1WnXDWn for ; Sat, 20 Feb 2016 02:41:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708A51A86FA for ; Sat, 20 Feb 2016 02:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b5JC5SbqKfLfnLxzpRYJAte12SEBQoFZeX2t/TptzRg=; b=KkU3fEXXndMwbmpc+MuCaCnBTihbHvIUEkYH08ib/2dapo7J3wB77VlfmvHTpTXLvyBaG0S/l4PcFhoGCQtzNX/uAtFod9lxgHTr9f7qcrgvIE9q/xhCC9wRSwJ28jZkQVboNelDzBNQWF8VCb6+loBgb/sEqbjc08+KKHoWRZY= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 10:41:05 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.017; Sat, 20 Feb 2016 10:41:05 +0000 From: Mike Jones To: Hannes Tschofenig , William Denniss , "Phil Hunt (IDM)" Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRa02vcYDFrUX6M06+JVJIk0JwsZ8zyRTAgAALpwCAAI80gIAAPJQAgAAQIQCAAAA+UIAAClQAgAADvDA= Date: Sat, 20 Feb 2016 10:41:05 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <56C8360C.8010203@gmx.net> <56C83EEA.8000306@gmx.net> In-Reply-To: <56C83EEA.8000306@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 00f1d040-a825-4280-d798-08d339e255fa x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:JOZjEkggnFT/fpFlx1rIaDQmb3+chmu7jxCQ8rlh+PF9fMN3xdXhWr9AmfMgF9x6XKNl3PLzW12PLenfRa4LRy/6+MorBP57L62YHk07uWkh8Ap05dQgquKB0mdtipTBMAletPf3BWdfWB+SikRjwQ==; 24:iOwSk3o2wzJnMyMj8EjNJ8TM9qx7iNGQJaBmgOHTH58C+hKMxa9VVmBvwm72FAAA/GKG8Y+cN8/KljvJgiWwANjGqBB2NBWU6ay05+C75l8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(377454003)(13464003)(5002640100001)(76576001)(586003)(15975445007)(10290500002)(122556002)(1096002)(3846002)(66066001)(5003600100002)(10400500002)(76176999)(54356999)(5005710100001)(102836003)(87936001)(2906002)(8990500004)(1220700001)(50986999)(86362001)(2950100001)(3280700002)(33656002)(5004730100002)(3660700001)(86612001)(2900100001)(6116002)(4326007)(77096005)(74316001)(5001770100001)(11100500001)(92566002)(189998001)(19580405001)(5008740100001)(19580395003)(5001960100002)(99286002)(93886004)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 10:41:05.3516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 10:41:31 -0000 Suggesting that they be read is of course, the right long-term approach. B= ut as someone who spent 20+ years as a researcher before switching to digit= al identity, I was sensitive to not wanting to upstage their work by copyin= g too much of their material into our draft before their publications were = widely known. I'll of course commit to working the researchers and the wor= king group to create a self-contained concise description of the threats an= d mitigations in the working group document. Cheers, -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Saturday, February 20, 2016 2:25 AM To: Mike Jones ; William Denniss ; Phil Hunt (IDM) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Ad= option Hi Mike, On 02/20/2016 10:52 AM, Mike Jones wrote: > Have you read both of their publications? If not, do yourself a favor=20 > and do. They're actually both very readable and quite informative. I have read both documents. In context of this discussion the question is w= hether we (a) require them to be read (in which case they should be a normative refer= ence), or (b) suggest them to be read (since they provide additional background infor= mation). In this case they are an informative reference. I believe believe we want (b) for the OAuth WG document. While I encourage = everyone to read the publications I also believe that there is lots of mate= rial in there that goes beyond the information our audience typically reads= (such as the text about the formal analysis). There is probably also a middle-ground where we either copy relevant text f= rom the papers into the draft or reference specific sections that are "must= -read". One other issue: I actually thought that the threat that is outlined in the= research paper is sufficiently well described but the second threat, which= is called 'cut-and-paste attack', requires more work. I noted this in my summary mail to the list, see http://www.ietf.org/mail-a= rchive/web/oauth/current/msg15697.html Ciao Hannes From nobody Sat Feb 20 04:16:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CC91A1AD0 for ; Sat, 20 Feb 2016 04:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 VU18Z-XFT_iG for ; Sat, 20 Feb 2016 04:16:18 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6181A1A1F for ; Sat, 20 Feb 2016 04:16:18 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id b205so100004918wmb.1 for ; Sat, 20 Feb 2016 04:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=T7GHxOzIe0qq5ET9VG9QW9fRojESDup1hgRynufA7R4=; b=bp9Gnoe2Tf4Th8UyFC9R6vq6oGltUc/53XmGVcBCyCPEDc5VtoGqe/JfJg1KDVNvHX 9REKcEXq5DERIWpvno7LO93LNZSK9B1vZysq51iWhkpXeobo20QBL0m8xl3A01Ky+JiJ tRwDXurP6dzY+hJ7Lsre/50WQVbFkNdLyJ/iYzObK9FWQ9fG78RDy2BXOkoo/2+IB/vw mpuFi4Jcd6R/gG2Ii04jUxfqvonRogMOgixSxQt6m5ispL6k5hWsBSO6rUuTo3kGlPhs hUha2q/rGw8q+dapy881ftVcr6neaKdqWC2Muot3vBSvZ10D1k8jqJrD10jq6xJDnR1I 0kvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=T7GHxOzIe0qq5ET9VG9QW9fRojESDup1hgRynufA7R4=; b=gldIbjrjV91Tj2zmN9HeyXichHfnHYhLy+BltEYnEIShXTYiyNbgWLX3zxenydbpDb E14Kifuk2HB55EbWsIkNb/wIEV2S1TfrnsOrau0ewm6cElFjnJnSepCyeodKy05UcbI5 9hwiu2W0dFvfRC/4i5NalLtnYdaEklkWt16Fk4WocgsO5q0e8VFKwVOy2WQR3QVmB3GB 7Fde29fmhf4JLOray+Oj26pswTDfbmVGkdbZTOOOJ/9oYm5ANd5Ig2cMQ+NKFSLAwRDH aveFvs4mbukVoufSxCd2UNN/dhPipoyDaJZ3FfzQSU1QjhG1rO1RzlNog/IHcPJ32smN KoNw== X-Gm-Message-State: AG10YOQi7xIm/N+yWkqCNPwRjpFHOhdmSARtzov9l02j4X+fzAlc28stDlMeApkil99ziQ== X-Received: by 10.28.132.17 with SMTP id g17mr2457567wmd.63.1455970576612; Sat, 20 Feb 2016 04:16:16 -0800 (PST) Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id w17sm11829572wmw.5.2016.02.20.04.16.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 20 Feb 2016 04:16:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_09814914-CFA3-4257-BF5E-40E001299049"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Sat, 20 Feb 2016 13:16:12 +0100 Message-Id: <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> To: William Denniss X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 12:16:24 -0000 --Apple-Mail=_09814914-CFA3-4257-BF5E-40E001299049 Content-Type: multipart/alternative; boundary="Apple-Mail=_CF4EB04B-4E6B-4F7F-B1E3-865095CFC848" --Apple-Mail=_CF4EB04B-4E6B-4F7F-B1E3-865095CFC848 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline > On Feb 20, 2016, at 9:49 AM, William Denniss = wrote: >=20 > Maybe it's because I wasn't at the Darmstadt meeting so I don't have = the full context, but I don't find draft A = to = be all that clear. Here's my review feedback: >=20 > Regarding the text "a client may be confused simply because it is = receiving authorization responses from more than one authorization = server at the same redirection endpoint". Even if the client re-uses the = same redirection endpoint, shouldn't state solve this? All incoming = responses should have an outgoing request with a matching state that = would identify the authorization request and therefore authorization = server. If only that were the case. That is the nub of the problem people = think state works to do that, but it enables the attack not stops it. State contains where the client sends the request. The client assumes = any response following that is from the AS it sent the request to. =20 Most of the attacks documented take advantage of this by misdirecting = the request to a different AS than the one the client =E2=80=9Cthinks=E2=80= =9D it is making the request to. =20 This is done in two ways. One is by pointing at another AS=E2=80=99s = authorization endpoint as part of registration, and the other is by = redirecting and rewriting the authorization request. The client thinking it has a response from a AS based on state then uses = the associated token and RS endpoints. Those endpoints are wrong for = the AS that really returned the response. Thus the client becomes a = proxy for relaying responses from the target AS. Both mitigations attempt to mitigate this by having the AS return = something that can be compared with state to determine if the request = has been misdirected. In one case we return a logical identifier (Name) for the AS that is = compared to a name provided as part of client setup. This name can = optionally be used as the input to discovery to verify other meta-data = about the AS. In the second mitigation the URI of the token endpoint or resource = server is returned. They both provide a way for the client to determine if the stored state = is invalid because the response is coming from a different place than = the request went to. It was noted by the researchers that the OIDC flow =E2=80=9Ccode = id_token=E2=80=9D was not susceptible to this attack because the client = validates the issuer of the id_token and the client_id that the AS = thinks it is responding to (some of the attacks rewrite the client_id in = the request). For reference = http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation = = points 2 & 3 of the OIDC validation. Knowing that works based on researcher feedback, the first option allows = the two id_token claims to be returned from the Authorization endpoint = without forcing OAuth clients to support signed JWT. It also allows AS = to provide a issuer URI but allows clients to compare the strings = without forcing them to do discovery. Clients that do discovery can = use this value to bootstrap/validate that. This takes advantage of = validation that some clients already perform and applies it to the code = response. The second option from Nat allows the client to compare the = token_endpoint URI from configuration to the one in the response. A = difference would indicate that the AS is different, in a similar way to = the other option. =20 The difference is that the second option doesn=E2=80=99t include the = client_id and while I don=E2=80=99t have an attack against that off the = top of my head, it was felt that it is a open attack surface and should = be closed. =20 The other difference is I think more subtle and changes OAuth in the = second option (Nat probably argues that would be a good thing). OAuth to this point assumes that the client is in charge, that the = developer configures the endpoints etc via service documentation. In the authorization request or the AT request the AS has no information = about what RS is being used as part of the protocol. The second option changes that by providing link relationships where = each step provides meta data about where to use the result. The Authorization endpoint points to the token endpoint, the token = endpoint points to the resource server and the resource server points to = the Authorization endpoint. To get that to work for a number of uses = cases you probably need to tell the authorization endpoint and possibly = the token endpoint what resource or resources you want the scopes for. = A given AS might have more than one token endpoint (not common but not = precluded, but something that might happen in multi tenant or other = special cases), and if it is using JWT access tokens it may not even = know about the given RS. So to be able to give the meta-data for the next hop the endpoint = responding may need more information. The two mitigations are not incompatible, we could do both. I do however think that the second one may have architectural side = effects that we need to more fully discuss. =20 Adding link relation/follow your nose processing to OAuth may be a good = thing, but may have impacts that we have not fully thought through yet. >=20 >=20 > For the issue of dynamic discovery and the potential to insert a = malicious discovery document: can the recommendation be to use the = hybrid flow of Connect if you do discovery (and validate the issuer = before exchanging the code)? Do we need to invent something new for = this use-case? As above this would work , but we don;t want to force all OAuth clients = to have to deal with JWT. This would be a fix for Connect if we were = only concerned about that. >=20 > Regarding sections 5 & 6 ("Mitigation Data Sent to the Token = Endpoint"), this describes something that seems similar to what is = achieved by PKCE (RFC7636). Binding information to the authorization = code that must be presented to redeem the code is precisely what PKCE = does, and PKCE has additional security properties. With the PKCE S256 = challenge method, the authorization request and response can leak in = their entirety, and yet still the attacker couldn't exchange the = authorization code. Let's just recommend RFC7636 for this mitigation. >=20 Unfortunately PKCE makes the assumption that attacker cannot modify the = request. In this case the attacker can modify the request.=20 PKCE provides protection in cases where the attacker can=E2=80=99t = modify the PKCE challenge in the request.=20 If the attacker can modify the request then they make a new request in a = second browser to get the PKCE challenge and replace the one in the = request being modified by that one. I need to think about it a bit more but there might be a way to do it by = defining a new PKCE method.=20 If the code_challenge were a HASH of state || code_verifyer, that would = do both. =20 The server would need to store state and code_challange. The client = would just calculate the hash over both, but still send the same = code_verifier. ( optimization would be for the code_challange =3D=3D S256 (S256(state) = || code_verifier) that way the AS only needs to store the hash of = state) The attacker can=E2=80=99t change the state in the first request, or the = client will reject the response, and because the code_verifyer will be = different between the requests the AS would reject the second one = because the code_challange will be wrong. That is more complicated for the client, but would allow you to do it = with PKCE with no more crypto than PKCE S256 (the MTI) already requires. For Asymmetric PKCE the code_challange would be a JWK of the public key = and the code_verifier would be a JWS (S256(state) ) (You might want to include code in the JWT but I need to think that = through) So yes unless someone finds a flaw in that logic we may be able to = define some PKCE modes to mitigate against cut and paste. I didn=E2=80=99t think of defining a new PKCE mode at the time. You = should have been at the meeting:) > The security researcher documents are only informative references, and = yet the spec seems to rely on them normatively. E.g.: > * "Mitigating the attacks also relies on the client sending = additional data about the interaction to the token endpoint" (how does = this mitigate the attacks? and what attack exactly?). > * "a client may be confused simply because it is receiving = authorization responses from more than one authorization server" (why = is the client confused?) > I would like to see the attacks normatively described in the spec. >=20 > For my own knowledge: what are some of the use-cases that are subject = to these attacks? I'm not convinced every RP that talks to more than 1 = AS is at risk today. What are some risky situations that exist which are = mitigated by this draft? Any RP is at risk if one of the AS it talks to is compromised, it can = compromise all of the AS that the client talks to. That is just not a = good design. Hans did a proof of concept that only required access to the logs of one = AS to compromise all AS. John B. >=20 >=20 >=20 > On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) > wrote: > Option A >=20 > Phil >=20 > > On Feb 19, 2016, at 13:39, Hans Zandbelt > wrote: > > > > Option A: I agree with Mike that the complexity and implementation = cost of Option B will make adoption harder, which was also a concern = with the first iteration of Option A. > > > > To be honest, I'm not sure most people would even understand why the = complexity would be required and just forget about it. At least with the = simplicity of the most recent option A they don't have to care, just add = some simple parameters/checks. > > > > And for the record: I've also implemented option A in the = mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and = NGINX respectively. > > > > Hans. > > > > [1] https://github.com/pingidentity/mod_auth_openidc = > > [2] https://github.com/pingidentity/lua-resty-openidc = > > > >> On 2/19/16 9:18 PM, Mike Jones wrote: > >> Option A. I have higher confidence that this specification solves = the > >> problems because it was designed during a 4-day security meeting > >> dedicated to this task by a group of over 20 OAuth security = experts, > >> *including both sets of researchers in Germany who originally = identified > >> the problem*. This solution has also been implemented and interop > >> tested by Roland Hedberg, Brian Campbell, and I believe others. = Note > >> that the reason I am advocating this specification is **not** = because > >> I'm an editor of it; my role was to record in spec language what = the > >> OAuth security experts designed together over the 4-day period in = Darmstadt. > >> > >> I=E2=80=99ll also note that even if Option B also solves the = problem, it comes > >> at significant adoption costs and complexity not found in A. In > >> particular, it requires that developers understand support a new = =E2=80=9CLink > >> Relation=E2=80=9D syntax not used elsewhere in OAuth. As Nat = writes about his > >> own draft in > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html = - = there > >> is not a standard JSON syntax for link relations. He writes =E2=80=9C= we could > >> easily create a parallel to it=E2=80=9D. I=E2=80=99d rather we = solve the problem using > >> standard mechanisms already employed in OAuth, rather than risk > >> bifurcating OAuth in the developer community by unnecessarily > >> inventing/creating new syntax that is unfamiliar to developers and = that > >> many of them may reject using. > >> > >> -- Mike > >> > >> P.S. Information about the OAuth security meeting can be found at > >> = https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXz= GptU4/edit = > >> and > >> = https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakV= bA_sk/edit = > >> . > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig > >> Sent: Friday, February 19, 2016 11:43 AM > >> To: oauth@ietf.org > >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call = for > >> Adoption > >> > >> Early February I posted a mail to the list to make progress on the > >> solution to the OAuth Authorization Server Mix-Up problem = discovered > >> late last year. > >> > >> Here is my mail about the Authorization Server Mix-Up: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html = > >> > >> Here is my mail to the list that tries to summarize the discussion > >> status and asked a few questions: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html = > >> > >> Unfortunately, my mail didn't lead to the intended success. While = there > >> was some feedback I wasn't getting the desired response. > >> > >> In order to move forward I believe we need a working group document = that > >> serves as a starting point for further work in the group*. We have = two > >> documents that provide similar functionality in an attempt to solve = the > >> Authorization Server Mix-Up problem. > >> > >> So, here is the question for the group. Which document do you want = as a > >> starting point for work on this topic: > >> > >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John = Bradley > >> > >> Link: > >> > >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 = > >> > >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake = and > >> Sascha Preibisch > >> > >> Link: > >> > >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 = > >> > >> Deadline for feedback is March, 4th. > >> > >> Ciao > >> > >> Hannes & Derek > >> > >> PS: (*) Regardless of the selected solution we will provide proper > >> acknowledgement for those who contributed to the work. > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth = > > > > -- > > Hans Zandbelt | Sr. Technical Architect > > hzandbelt@pingidentity.com | = Ping Identity > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_CF4EB04B-4E6B-4F7F-B1E3-865095CFC848 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline
On Feb 20, 2016, at 9:49 AM, William Denniss = <wdenniss@google.com> wrote:

Maybe it's because I wasn't at the Darmstadt = meeting so I don't have the full context, but I don't find draft A to be all that clear. = Here's my review feedback:

Regarding the text "a client may be confused simply = because it is receiving authorization responses from more than one = authorization server at the same redirection endpoint". Even if the = client re-uses the same redirection endpoint, shouldn't state solve = this? All incoming responses should have an outgoing request with a = matching state that would identify the authorization request and = therefore authorization server.

If only that were the case.   That is the nub of = the problem people think state works to do that, but it enables the = attack not stops it.

State contains = where the client sends the request.   The client assumes any = response following that is from the AS it sent the request to. =  
Most of the attacks documented take advantage of this = by misdirecting the request to a different AS than the one the client = =E2=80=9Cthinks=E2=80=9D it is making the request to. =  

This is done in two ways. One = is by pointing at another AS=E2=80=99s authorization endpoint as part of = registration, and the other is by redirecting and rewriting the = authorization request.

The client = thinking it has a response from a AS based on state then uses the = associated token and RS endpoints.   Those endpoints are wrong for = the AS that really returned the response.   Thus the client becomes = a proxy for relaying responses from the target AS.

Both mitigations attempt to mitigate this by = having the AS return something that can be compared with state to = determine if the request has been misdirected.

In one case we return a logical identifier (Name) = for the AS that is compared to a name provided as part of client setup. =  This name can optionally be used as the input to discovery to = verify other meta-data about the AS.

In the second mitigation the URI of the token = endpoint or resource server is returned.

They both provide a way for the client to = determine if the stored state is invalid because the response is coming = from a different place than the request went to.

It was noted by the researchers that the OIDC flow = =E2=80=9Ccode id_token=E2=80=9D was not susceptible to this attack = because the client validates the issuer of the id_token and the = client_id that the AS thinks it is responding to (some of the attacks = rewrite the client_id in the request).

For reference http://openid.net/specs/openid-connect-core-1_0.html#IDTokenVal= idation points 2 & 3 of the OIDC validation.

Knowing that works based on researcher feedback, = the first option allows the two id_token claims to be returned from the = Authorization endpoint without forcing OAuth clients to support signed = JWT.   It also allows AS to provide a issuer URI but allows clients = to compare the strings without forcing them to do discovery.   = Clients that do discovery can use this value to bootstrap/validate that. =   This takes advantage of validation that some clients already = perform and applies it to the code response.

The second option from Nat allows the client to = compare the token_endpoint URI from configuration to the one in the = response.  A difference would indicate that the AS is different, in = a similar way to the other option.  

The difference is that the second option doesn=E2=80= =99t include the client_id and while I don=E2=80=99t have an attack = against that off the top of my head, it was felt that it is a open = attack surface and should be closed.  

The other difference is I think more subtle and = changes OAuth in the second option (Nat probably argues that would be a = good thing).
OAuth to this point assumes that the client is in = charge, that the developer configures the endpoints etc via service = documentation.
In the authorization request or the AT request = the AS has no information about what RS is being used as part of the = protocol.

The second option changes = that by providing link relationships where each step provides meta data = about where to use the result.
The Authorization endpoint = points to the token endpoint, the token endpoint points to the resource = server and the resource server points to the Authorization endpoint. =   To get that to work for a number of uses cases you probably need = to tell the authorization endpoint and possibly the token endpoint what = resource or resources you want the scopes for.    A given AS = might have more than one token endpoint (not common but not precluded, =  but something that might happen in multi tenant or other special = cases), and if it is using JWT access tokens it may not even know about = the given RS.

So to be able to give = the meta-data for the next hop the endpoint responding may need more = information.

The two mitigations are = not incompatible, we could do both.

I = do however think that the second one may have architectural side effects = that we need to more fully discuss.  
Adding link = relation/follow your nose processing to OAuth may be a good thing, but = may have impacts that we have not fully thought through = yet.



For the issue of = dynamic discovery and the potential to insert a malicious discovery = document: can the recommendation be to use the hybrid flow of Connect if = you do discovery (and validate the issuer before exchanging the = code)?  Do we need to invent something new for this use-case?

As = above this would work , but we don;t want to force all OAuth clients to = have to deal with JWT.   This would be a fix for Connect if we were = only concerned about that.


Regarding = sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint"), this = describes something that seems similar to what is achieved by PKCE = (RFC7636). Binding information to the authorization code that must be = presented to redeem the code is precisely what PKCE does, and PKCE has = additional security properties. With the PKCE S256 challenge method, the = authorization request and response can leak in their entirety, and yet = still the attacker couldn't exchange the authorization code. Let's just = recommend RFC7636 for this mitigation.

Unfortunately PKCE = makes the assumption that attacker cannot modify the request.  In = this case the attacker can modify the request. 

PKCE provides protection in cases where the = attacker can=E2=80=99t modify the PKCE challenge in the = request. 
If the attacker can modify the request then = they make a new request in a second browser to get the PKCE challenge = and replace the one in the request being modified by that = one.

I need to think about it a bit = more but there might be a way to do it by defining a new PKCE = method. 

If the code_challenge =  were a HASH of state || code_verifyer, that would do both. =   

The server would need = to store state and code_challange.  The client would just calculate = the hash over both, but still send the same code_verifier.
( = optimization would be for the code_challange =3D=3D S256 (S256(state) || = code_verifier)  that way the AS only needs to store the hash of = state)

The attacker can=E2=80=99t = change the state in the first request, or the client will reject the = response, and because the code_verifyer will be different between the = requests the AS would reject the second one because the code_challange = will be wrong.

That is more = complicated for the client, but would allow you to do it with PKCE with = no more crypto than PKCE S256 (the MTI) already requires.

For Asymmetric PKCE the code_challange would be a = JWK of the public key and the code_verifier would be a JWS (S256(state) = )
(You might want to include code in the JWT but I need to = think that through)

So yes unless = someone finds a flaw in that logic we may be able to define some PKCE = modes to mitigate against cut and paste.
I didn=E2=80=99t = think of defining a new PKCE mode at the time.  You should have = been at the meeting:)


The= security researcher documents are only informative references, and yet = the spec seems to rely on them normatively. E.g.:
* =  "Mitigating the attacks also relies on the client sending = additional data about the interaction to the token endpoint" (how does = this mitigate the attacks? and what attack exactly?).
*  "a = client may be confused simply because it is receiving authorization = responses from more than one authorization server"  (why is = the client confused?)
I would like = to see the attacks normatively described in the spec.

For = my own knowledge: what are some of the use-cases that are subject to = these attacks? I'm not convinced every RP that talks to more than 1 AS = is at risk today. What are some risky situations that exist which are = mitigated by this draft?

Any RP is at risk if one of the AS it talks to is = compromised, it can compromise all of the AS that the client talks to. =  That is just not a good design.

Hans did a proof of concept that only required = access to the logs of one AS to compromise all AS.

John B.


On Fri, = Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:
>
> Option A: I agree with Mike that the complexity and implementation = cost of Option B will make adoption harder, which was also a concern = with the first iteration of Option A.
>
> To be honest, I'm not sure most people would even understand why = the complexity would be required and just forget about it. At least with = the simplicity of the most recent option A they don't have to care, just = add some simple parameters/checks.
>
> And for the record: I've also implemented option A in the = mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and = NGINX respectively.
>
> Hans.
>
> [1] https://github.com/pingidentity/mod_auth_openidc
> [2] https://github.com/pingidentity/lua-resty-openidc
>
>> On 2/19/16 9:18 PM, Mike Jones wrote:
>> Option A.  I have higher confidence that this = specification solves the
>> problems because it was designed during a 4-day security = meeting
>> dedicated to this task by a group of over 20 OAuth security = experts,
>> *including both sets of researchers in Germany who = originally identified
>> the problem*.  This solution has also been implemented and = interop
>> tested by Roland Hedberg, Brian Campbell, and = I believe others.  Note
>> that the reason I am advocating this specification is = **not** because
>> I'm an editor of it; my role = was to record in spec language what the
>> OAuth security experts designed together over the 4-day period = in Darmstadt.
>>
>> I=E2=80=99ll also note that even if Option B also solves the = problem, it comes
>> at significant adoption costs and complexity not found in = A.  In
>> particular, it requires that developers understand support a = new =E2=80=9CLink
>> Relation=E2=80=9D syntax not used elsewhere in OAuth.  As = Nat writes about his
>> own draft in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.htm= l - there
>> is not a standard JSON syntax for link relations.  He = writes =E2=80=9Cwe could
>> easily create a parallel to it=E2=80=9D.  I=E2=80=99d = rather we solve the problem using
>> standard mechanisms already employed in OAuth, rather than = risk
>> bifurcating OAuth in the developer community by = unnecessarily
>> inventing/creating new syntax that is unfamiliar to developers = and that
>> many of them may reject using.
>>
>>                  =                     =                     =  -- Mike
>>
>> P.S.  Information about the OAuth security meeting can be = found at
>> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHA= lJ6kM5OyeXzGptU4/edit
>> and
>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_= EoSpO5NtakVbA_sk/edit
>> .
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Friday, February 19, 2016 11:43 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: = Call for
>> Adoption
>>
>> Early February I posted a mail to the list to make progress on = the
>> solution to the OAuth Authorization Server Mix-Up problem = discovered
>> late last year.
>>
>> Here is my mail about the Authorization Server Mix-Up:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm= l
>>
>> Here is my mail to the list that tries to summarize the = discussion
>> status and asked a few questions:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.htm= l
>>
>> Unfortunately, my mail didn't lead to the intended success. = While there
>> was some feedback I wasn't getting the desired response.
>>
>> In order to move forward I believe we need a working group = document that
>> serves as a starting point for further work in the group*. We = have two
>> documents that provide similar functionality in an attempt to = solve the
>> Authorization Server Mix-Up problem.
>>
>> So, here is the question for the group. Which document do you = want as a
>> starting point for work on this topic:
>>
>> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and = John Bradley
>>
>> Link:
>>
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation= -01
>>
>> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov = Matake and
>> Sascha Preibisch
>>
>> Link:
>>
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >>
>> Deadline for feedback is March, 4th.
>>
>> Ciao
>>
>> Hannes & Derek
>>
>> PS: (*) Regardless of the selected solution we will provide = proper
>> acknowledgement for those who contributed to the work.
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> Hans Zandbelt              | Sr. = Technical Architect
> hzandbelt@pingidentity.com | Ping Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

= --Apple-Mail=_CF4EB04B-4E6B-4F7F-B1E3-865095CFC848-- --Apple-Mail=_09814914-CFA3-4257-BF5E-40E001299049 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMjAxMjE2MTNaMCMGCSqGSIb3DQEJBDEWBBS22QHLWXvny9v4DSt4NnMA 8mWV3TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCJnT8N7XsQ51a8ASgo+ByNPsDw7TTsAvMf7HkVFht6LHijpPZoSdWI KFzWsqIo9CUczmTmV9CWVeo3OVqquOWAf+xzVijlCPPcmkyRsQZtRKHB0CSY90foR6CUfSMc+yO9 JCGJaJ55y9d+lcoHf3PcG4BzlDyoHjUwpHRZAIaWdDWhlkiMK4/TsoiG+ZS16W5DTxf/UCototMU WDe0rex44KkZGR/WiEVW/c7bOZH1w4GDs9VDYZ4eVvZznhVTFS+UrY48VXdyhl0b9POrKe7Hy4AI v8xd8a82jZ6i2jI9+QCDZ+dwtnqHvGF0E06RpAUDhL8WPpzafTZDMbfFQggjAAAAAAAA --Apple-Mail=_09814914-CFA3-4257-BF5E-40E001299049-- From nobody Sun Feb 21 22:12:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2D01B355A for ; Sun, 21 Feb 2016 22:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 rS5OlSHpSAe0 for ; Sun, 21 Feb 2016 22:11:57 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E851C1B354F for ; Sun, 21 Feb 2016 22:11:56 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s68so52200734qkh.3 for ; Sun, 21 Feb 2016 22:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=y9oz+XQYk/8vq66XddUQCMOic6oQNlT8Wz5WfnfBSU0=; b=Rejz34YFfiQvx/XjHnx3YrmFUVq3ZPVUF+mS2ieTK0OGEYbZ2OmEw4fvPFHorsoQyK SxylPt0FRU+sLkwmShttHBGhARssZMXQKl9VFXP7iYngc4i+pghJOaIRDztKOHTHz0JX l57YCVF00IdMyHbWL33yl5MoWoeyD95gm+NgfjmFPuukxjfRNYWl5/T9soSsyScfdm/k 6gPWA4+bMW2dm1Abh4i14lvNW4xFNfAifXUZ2uLkm6zdHj6m9UcClWaWhULwSeriPpJo tUkPNN5mCRsGe6Tp4cdeHtW9jmSrr8ATWj3VLDGB+Em4HV8mU3Bj/VrUkjNvLRQBQvPL ZXGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=y9oz+XQYk/8vq66XddUQCMOic6oQNlT8Wz5WfnfBSU0=; b=lvvKl3gNAsIgrmrMMWIet8o4aoM8ao8I4207O323y60lT1VnA8JBV26t5Azr5h+qMa WVaMZvY56FYZ4uZqVN319Ugm9DQaBcOLBbpufJCz9ASiA+FI1E+rwUbfMISEN/uqpxnf wL2CQ6B/YFpx3NzpqphzFkMsAu4R6ho+o8N1UTtjQM1qgFYTX+c4QCYj5a/4/CZyMBWI SasWyhuB/tKMNolwtjud+Am96k+pEEguH3xRt/BDZJ4quWRzrE/bKgr+VxGjf9Ga0G1U q09SlZQID4BX0QfLiLxoK627eP2WJctMUE/knOQvqnnrh0gV1G+mXu8ZvBGqEnjx/TR1 /uRQ== X-Gm-Message-State: AG10YOSzATPaAl8Y8Ry7mXNEeDNCGdDKp1SyM3yE2/2G1hmUvIXbmXsbD5KouOhTcs7lN/qtQa0aGRLbY4vhow== MIME-Version: 1.0 X-Received: by 10.55.19.12 with SMTP id d12mr19500698qkh.53.1456121515393; Sun, 21 Feb 2016 22:11:55 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sun, 21 Feb 2016 22:11:55 -0800 (PST) Date: Mon, 22 Feb 2016 07:11:55 +0100 Message-ID: From: Samuel Erdtman To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11400594acdb8d052c55b528 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 06:11:59 -0000 --001a11400594acdb8d052c55b528 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Here coms some review comments, In general I think this is a good document. //Samuel 2. Authorization Server Metadata token_endpoint, I would prefer if the requiredness of this parameter was put in the beginning instead of the end as with the other parameters. jwks_uri, I would like to change to recommended since this is not a parameter required by the base OAuth 2.0 framework similar to registration_endpoint jwks_uri, It would be nice with a referens to the definition of jwks_uri. jwks_uri, =E2=80=9CWhen both signing and encryption keys are made available= , a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage=E2=80=9D The text would be simpler if it just said that =E2=80=9Cuse=E2=80=9D always= was required. It would also be one less thing to argue about when it comes to interoperability if it was always required. response_types_supported, an example would be appreciated and maybe a referees to the response type definition response_types_supported, What is the difference between response_types_supported and grant_types_supported, with a quick look they seem very similar. Could it be enough with one of them? introspection_endpoint_auth_signing_alg_values_supported, revocation_endpoint_auth_signing_alg_values_supported and token_endpoint_auth_signing_alg_values_supported, it would be good with a reference to the definition of "private_key_jwt" and "client_secret_jwt" token_endpoint_auth_methods_supported, why not refer to IANA registry for "OAuth Token Endpoint Authentication Methods" under [IANA.OAuth.Parameters] in the same way as with introspection_endpoint_auth_signing_alg_values_supported and revocation_endpoint_auth_signing_alg_values_supported 3. Obtaining Authorization Server Discovery Metadata As also mentioned by Justin I think it is a bit confusing with the example opened-configuration as .well-known/ postfix could it be made clearer that it is ab example maybe by making "/.well-known/example-configuration" the primary example. 5. Compatibility Notes =E2=80=9Dhttp://openid.net/specs/connect/1.0/issuer" is only used in this s= ection, maybe it should be removed? --001a11400594acdb8d052c55b528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here coms some review comments, In = general I think this is a good document.

//Samuel<= /div>


2.=C2=A0 Authorization Server = Metadata

token_endpoint, I would prefer if the req= uiredness of this parameter was put in the beginning instead of the end as = with the other parameters.

jwks_uri, I would like = to change to recommended since this is not a parameter required by the base= OAuth 2.0 framework similar to registration_endpoint

<= div>jwks_uri, It would be nice with a referens to the definition of jwks_ur= i.

jwks_uri, =E2=80=9CWhen both signing and encryp= tion keys are made available, a "use" (public key use) parameter = value is REQUIRED for all keys in the referenced JWK Set to indicate each k= ey's intended usage=E2=80=9D
The text would be simpler if it = just said that =E2=80=9Cuse=E2=80=9D always was required. It would also be = one less thing to argue about when it comes to interoperability if it was a= lways required.

response_types_supported, an examp= le would be appreciated and maybe a referees to the response type definitio= n

response_types_supported, What is the difference= between response_types_supported and grant_types_supported, with a quick l= ook they seem very similar. Could it be enough with one of them?
=

introspection_endpoint_auth_signing_alg_value= s_supported,
revocation_endpoint_auth_signing_alg_values_supporte= d and=C2=A0
token_endpoint_auth_signing_alg_values_supported, it = would be good with a reference to the definition of "private_key_jwt&q= uot; and "client_secret_jwt"

token_endpo= int_auth_methods_supported, why not refer to IANA registry for "OAuth = Token Endpoint Authentication Methods" under [IANA.OAuth.Parameters] i= n the same way as with introspection_endpoint_auth_signing_alg_values_suppo= rted and revocation_endpoint_auth_signing_alg_values_supported


3.=C2=A0 Obtaining Authorization= Server Discovery Metadata
As also mentioned by Justin I think it= is a bit confusing with the example opened-configuration as .well-known/ p= ostfix could it be made clearer that it is ab example maybe by making "= ;/.well-known/example-configuration" the primary example.


5.=C2=A0 Compatibility Notes
=E2=80=9Dhttp= ://openid.net/specs/connect/1.0/issuer" is only used in this secti= on, maybe it should be removed?


--001a11400594acdb8d052c55b528-- From nobody Sun Feb 21 22:20:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623C21B357C for ; Sun, 21 Feb 2016 22:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 dIiYnmavbphn for ; Sun, 21 Feb 2016 22:20:41 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 737D91B357B for ; Sun, 21 Feb 2016 22:20:41 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id y89so104530613qge.2 for ; Sun, 21 Feb 2016 22:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ifm86cs7b7oUoRgtCGGeh9wdDHEqAYg4o77l2COymfY=; b=K5zoYv/Brm+WZJ3uKTWkGgwP9RK8QL338FFSsBiQB6mkn/sdn1u87dHYXc9CRFzIT6 D1YkfVYlVXrNf+J+mPNSaji76aGQZ4/DaFAWYvcWlbJBTV26ugGNK4woqKCD2GKaZbps JZcjWqKNbUehfYveJyFrmt1BAMsrdx+yi+45eypMS0lM+nG2/peGOt9zmJNuMwONuBxJ ixkOJ7lF5BJKWIiEKyyQEMaFMRacrzmO1+A/dNMzOyXGgw9QMKIRrUsVUwOOyQpaN0lj 3GcB/1l1xy2L1pzCD5SPOUFgIrD6oD0reBrYqO1KBgbxMTdibEkVctlLpkM89a3Eq25U y4ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ifm86cs7b7oUoRgtCGGeh9wdDHEqAYg4o77l2COymfY=; b=a4LliJnZyTyW92ac1rCnIYoZAbK4K6AR94f+2oEUlyiJDZPc+BzghG1+YWlL+RbLK+ VXA5Uxp0mchsIW4yUcuU3dPLrT9FMt7sOgH3ff4IryYYwOqW18PcaeE05FvG8V+RR8o5 ehIoJGbM54jegHMfAbjbbremuMj5YvIC0qqYtprnAj/TgZaxhXNv/ZpHRReeFPdCnD/Q +48XikEsCd6btzkZJBnSVQL5eQioAy3Hbjl+jXsgtPAtajU8ldVuXEM1kdzmh8D2ydxk uQ9CDvU+E0lqLemKhvzbDPcPZSi96S3plKdfQeSIj3VY1hQuvv1pqxG+0lQIJO3ATZVb ylCg== X-Gm-Message-State: AG10YOTLQ4PtBnMRiVhmiNm9pIWYoikR/yxbf0HWMSyELTqHljM4J8aa7Y/tWiZlovT/EPqTZ7jqY2MZ/7JHBw== MIME-Version: 1.0 X-Received: by 10.140.147.4 with SMTP id 4mr34546347qht.93.1456122040540; Sun, 21 Feb 2016 22:20:40 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sun, 21 Feb 2016 22:20:40 -0800 (PST) In-Reply-To: References: Date: Mon, 22 Feb 2016 07:20:40 +0100 Message-ID: From: Samuel Erdtman To: Justin Richer Content-Type: multipart/alternative; boundary=001a11445230fa1460052c55d4e0 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 06:20:43 -0000 --001a11445230fa1460052c55d4e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I agree that the user of =E2=80=9C/.well-known/openid-configuration=E2=80= =9D is confusing and that it would be preferable with something else, but it is written as an example not necessarily a default. However to use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D mi= ght be problematic if as written different applications needs different content in the discovery endpoint. (3. Obtaining Authorization Server Discovery Metadata) //Samuel On Fri, Feb 19, 2016 at 10:59 PM, Justin Richer wrote: > The newly-trimmed OAuth Discovery document is helpful and moving in the > right direction. It does, however, still have too many vestiges of its > OpenID Connect origins. One issue in particular still really bothers me: > the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the dis= covery portion. Is > this an OAuth discovery document, or an OpenID Connect one? There is > absolutely no compelling reason to tie the URL to the OIDC discovery > mechanism. > > I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2= =80=9D as the > default discovery location, and state that the document MAY also be > reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the= server also > provides OpenID Connect on the same domain. Other applications SHOULD use > the same parameter names to describe OAuth endpoints and functions inside > their service-specific discovery document. > > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11445230fa1460052c55d4e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I agree that the user of =E2=80=9C/.well-known/openid-configuration=E2=80=9D is=C2=A0confusing=C2=A0and that it would be preferable with some= thing else, but it is=C2=A0written as an example not=C2=A0necessarily a def= ault.

However to use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D might be problematic if as written differe= nt applications needs different content in the discovery endpoint. (3.=C2= =A0 Obtaining Authorization Server Discovery Metadata)

//Samuel
=
On Fri, Feb 19, 2016 at 10:59 PM, Justin Ric= her <jricher@mit.edu> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the ri= ght direction. It does, however, still have too many vestiges of its OpenID= Connect origins. One issue in particular still really bothers me: the use = of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery por= tion. Is this an OAuth discovery document, or an OpenID Connect one? There = is absolutely no compelling reason to tie the URL to the OIDC discovery mec= hanism.

I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2= =80=9D as the default discovery location, and state that the document MAY a= lso be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D i= f the server also provides OpenID Connect on the same domain. Other applica= tions SHOULD use the same parameter names to describe OAuth endpoints and f= unctions inside their service-specific discovery document.

=C2=A0=E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--001a11445230fa1460052c55d4e0-- From nobody Mon Feb 22 00:22:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3761ACEBB for ; Mon, 22 Feb 2016 00:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.108 X-Spam-Level: *** X-Spam-Status: No, score=3.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Jz7i98NfdD3l for ; Mon, 22 Feb 2016 00:22:12 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E51ACEDE for ; Mon, 22 Feb 2016 00:22:11 -0800 (PST) Received: from nriea04.index.or.jp (unknown [172.19.246.39]) by nrifs02.index.or.jp (Postfix) with SMTP id EFC3B196877; Mon, 22 Feb 2016 17:22:10 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp (unknown) with ESMTP id u1M8MAJ2009011; Mon, 22 Feb 2016 17:22:10 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1M8MAjY064685; Mon, 22 Feb 2016 17:22:10 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u1M8MA5f064684; Mon, 22 Feb 2016 17:22:10 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u1M8MAZ1064681; Mon, 22 Feb 2016 17:22:10 +0900 From: "Nat Sakimura" To: "'John Bradley'" , "'William Denniss'" References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> In-Reply-To: <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> Date: Mon, 22 Feb 2016 17:22:10 +0900 Message-ID: <05af01d16d4a$20230af0$606920d0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B0_01D16D95.901699D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHIN4/Puv2zCIwoSufeBP+WwUtTKwL5RbkwAl3bNncB8IKD9QJ1xCpiAW927hqe8H17AA== Content-Language: ja x-mailadviser: 20141126 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 08:22:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05B0_01D16D95.901699D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable [case1] Code phishing + cut-n-paste attack=20 [case1a] through BadAS to GoodAS redirect [case1b] through tampering the unprotected client access response [case1c] through the server log [case2] Token phishing (in case of implicit flow).=20 [case3] Code and Client credential phishing =20 All of these seem to involve the tampering of the unprotected = communication.=20 If we can secure all the communication, the problem would be solved for = all the variants and for those that we still do not know. One way of = doing it is to use OAuth JAR and authorization response that includes ID = Token, but that=E2=80=99s not possible in many cases as I understand.=20 We have to accommodate a measure that is proportionate to the risks.=20 =20 The risk impact of [case1] is that the code is stolen, and it is used = against the client to =E2=80=9Clogin=E2=80=9D to the client. The = attacker will not have an access to the access token. Is that right? If = that is the case, is this a case that we are really concerned of? Is it = not out of scope for OAuth? If so, we can punt this case to something = like a login protocol such as OpenID Connect. It also has the notion of = =E2=80=9Cissuer=E2=80=9D baked in, so there will be less conflict to use = the mix-up draft.=20 =20 The risk impact of [case2] is more OAuth specific. The token is stolen = as the token is going to be sent to a rogue resource, and the resource = can use that to obtain the resource that was supposed to be only = available to the proper client.=20 =20 The risk impact of [case3] is the most grave among these three. Now the = attacker can create his own client that impersonates the compromised = client.=20 =20 OAuth-mix-up --------------------------- OAuth-mix-up draft gives one way of addressing [case2] by introducing a = new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D = to RFC6749. It also returns client_id and verifies it in 4.2, but if the = BadAS has assigned a same client_id to the client, it does not help.=20 =20 By comparing the issuer stored in the session (the draft should be = explicit about it) with the issuer in the response, the client can find = out that the party he is getting the response from is not the one he = sent a request to, that communication was compromised/tampered with, = provided that the response is not tampered by the attacker in-browser.=20 =20 Note that the response may still be tampered (e.g., by MITB) so that the = issuer can be re-written, in which case the mitigation does not work, = but IMHO, we do not have to worry about it here, as with MITB, you can = do worse things easier.=20 =20 One of the issue with this approach is that the central notion of = =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the = authorization server that the client received when it registered at the = authorization server=E2=80=9D, but in most existing pure OAuth cases, = there is no such thing, so you cannot compare. This means that you would = have to re-register, and if you are doing that, the per-AS redirect_uri = seems to be a much simpler solution.=20 =20 Also note that this is not a general framework for finding out tainted = communication, so it may have other holes.=20 =20 OAuth-meta ------------------- OAuth-meta is not designed as a specific fix to the problem. Rather, it = was designed as a general framework of providing the meta-data to the = responses by leveraging RFC5988 registry. It just happens to mitigate = this particular case.=20 =20 Again, it is not a general framework for finding out tainted = communication, so it may have other holes.=20 =20 Per AS Redirect URI -------------------------------- This does not involve wire protocol changes. It just adds requirements = on the redirect uri. This by far is the simplest solution for [case2] = (and [case1]), IMHO.=20 =20 Again, it is not a general framework for finding out tainted = communication, so it may have other holes. =20 (Extended) PKCE --------------------------------- To begin with, it works only with code flow. There has to be something = else to deal with implicit flow.=20 =20 PKCE binds the authorization request/response to the token request.=20 If used with a confidential client, it seems to mitigate the = vulnerability.=20 John points out that it is not the case. I must be missing something = here=E2=80=A6 but my logic goes like:=20 =20 =20 1. The good client creates code_challenge-v and = code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + = code_challenge-v + state to the BadAS Authz EP.=20 2. BadAS as a client prepares a code_verifier-b and = code_challenge-b=3DS256(code_verifer-b).=20 3. BadAS redirects to GoodAS with the client_id-v + code_challenge-b = + state-v. =20 4. GoodAS stores the code_challenge-b.=20 5. GoodAS returns code-v + state-v to the client=E2=80=99s redirect = uri.=20 6. The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished.=20 =20 Now the attacker tries to use the code-v and code_verifier-v.=20 =20 ### Case A:=20 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he does = not have client secret for the good client, so it fails.=20 =20 ### Case B:=20 8. The BadAS as a client sends client_id-b + code-v + = code_verifier-b + secret-b etc. to GoodAS.=20 9. GoodAS verifies the code_verifier-b is associated with code-v, = but that code-v is not associated with client_id-b, so the token request = fails.=20 =20 ### Case C: cut-n-paste 10. The attacker launches cut-n-paste attack by replacing the code-b = with code-v.=20 11. The verifiers does not match, so fails.=20 =20 Please let me know what I am missing.=20 =20 Nat =20 =20 =20 =20 =20 =20 -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. =20 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Saturday, February 20, 2016 9:16 PM To: William Denniss Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for = Adoption =20 Inline On Feb 20, 2016, at 9:49 AM, William Denniss > wrote: =20 Maybe it's because I wasn't at the Darmstadt meeting so I don't have the = full context, but I don't find draft A = to = be all that clear. Here's my review feedback: =20 Regarding the text "a client may be confused simply because it is = receiving authorization responses from more than one authorization = server at the same redirection endpoint". Even if the client re-uses the = same redirection endpoint, shouldn't state solve this? All incoming = responses should have an outgoing request with a matching state that = would identify the authorization request and therefore authorization = server. =20 If only that were the case. That is the nub of the problem people = think state works to do that, but it enables the attack not stops it. =20 State contains where the client sends the request. The client assumes = any response following that is from the AS it sent the request to. =20 Most of the attacks documented take advantage of this by misdirecting = the request to a different AS than the one the client = =E2=80=9Cthinks=E2=80=9D it is making the request to. =20 =20 This is done in two ways. One is by pointing at another AS=E2=80=99s = authorization endpoint as part of registration, and the other is by = redirecting and rewriting the authorization request. =20 The client thinking it has a response from a AS based on state then uses = the associated token and RS endpoints. Those endpoints are wrong for = the AS that really returned the response. Thus the client becomes a = proxy for relaying responses from the target AS. =20 Both mitigations attempt to mitigate this by having the AS return = something that can be compared with state to determine if the request = has been misdirected. =20 In one case we return a logical identifier (Name) for the AS that is = compared to a name provided as part of client setup. This name can = optionally be used as the input to discovery to verify other meta-data = about the AS. =20 In the second mitigation the URI of the token endpoint or resource = server is returned. =20 They both provide a way for the client to determine if the stored state = is invalid because the response is coming from a different place than = the request went to. =20 It was noted by the researchers that the OIDC flow =E2=80=9Ccode = id_token=E2=80=9D was not susceptible to this attack because the client = validates the issuer of the id_token and the client_id that the AS = thinks it is responding to (some of the attacks rewrite the client_id in = the request). =20 For reference = http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation = points 2 & 3 of the OIDC validation. =20 Knowing that works based on researcher feedback, the first option allows = the two id_token claims to be returned from the Authorization endpoint = without forcing OAuth clients to support signed JWT. It also allows AS = to provide a issuer URI but allows clients to compare the strings = without forcing them to do discovery. Clients that do discovery can = use this value to bootstrap/validate that. This takes advantage of = validation that some clients already perform and applies it to the code = response. =20 The second option from Nat allows the client to compare the = token_endpoint URI from configuration to the one in the response. A = difference would indicate that the AS is different, in a similar way to = the other option. =20 =20 The difference is that the second option doesn=E2=80=99t include the = client_id and while I don=E2=80=99t have an attack against that off the = top of my head, it was felt that it is a open attack surface and should = be closed. =20 =20 The other difference is I think more subtle and changes OAuth in the = second option (Nat probably argues that would be a good thing). OAuth to this point assumes that the client is in charge, that the = developer configures the endpoints etc via service documentation. In the authorization request or the AT request the AS has no information = about what RS is being used as part of the protocol. =20 The second option changes that by providing link relationships where = each step provides meta data about where to use the result. The Authorization endpoint points to the token endpoint, the token = endpoint points to the resource server and the resource server points to = the Authorization endpoint. To get that to work for a number of uses = cases you probably need to tell the authorization endpoint and possibly = the token endpoint what resource or resources you want the scopes for. = A given AS might have more than one token endpoint (not common but not = precluded, but something that might happen in multi tenant or other = special cases), and if it is using JWT access tokens it may not even = know about the given RS. =20 So to be able to give the meta-data for the next hop the endpoint = responding may need more information. =20 The two mitigations are not incompatible, we could do both. =20 I do however think that the second one may have architectural side = effects that we need to more fully discuss. =20 Adding link relation/follow your nose processing to OAuth may be a good = thing, but may have impacts that we have not fully thought through yet. =20 =20 =20 For the issue of dynamic discovery and the potential to insert a = malicious discovery document: can the recommendation be to use the = hybrid flow of Connect if you do discovery (and validate the issuer = before exchanging the code)? Do we need to invent something new for = this use-case? =20 As above this would work , but we don;t want to force all OAuth clients = to have to deal with JWT. This would be a fix for Connect if we were = only concerned about that. =20 Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint"), = this describes something that seems similar to what is achieved by PKCE = (RFC7636). Binding information to the authorization code that must be = presented to redeem the code is precisely what PKCE does, and PKCE has = additional security properties. With the PKCE S256 challenge method, the = authorization request and response can leak in their entirety, and yet = still the attacker couldn't exchange the authorization code. Let's just = recommend RFC7636 for this mitigation. =20 Unfortunately PKCE makes the assumption that attacker cannot modify the = request. In this case the attacker can modify the request.=20 =20 PKCE provides protection in cases where the attacker can=E2=80=99t = modify the PKCE challenge in the request.=20 If the attacker can modify the request then they make a new request in a = second browser to get the PKCE challenge and replace the one in the = request being modified by that one. =20 I need to think about it a bit more but there might be a way to do it by = defining a new PKCE method.=20 =20 If the code_challenge were a HASH of state || code_verifyer, that would = do both. =20 =20 The server would need to store state and code_challange. The client = would just calculate the hash over both, but still send the same = code_verifier. ( optimization would be for the code_challange =3D=3D S256 (S256(state) = || code_verifier) that way the AS only needs to store the hash of = state) =20 The attacker can=E2=80=99t change the state in the first request, or the = client will reject the response, and because the code_verifyer will be = different between the requests the AS would reject the second one = because the code_challange will be wrong. =20 That is more complicated for the client, but would allow you to do it = with PKCE with no more crypto than PKCE S256 (the MTI) already requires. =20 For Asymmetric PKCE the code_challange would be a JWK of the public key = and the code_verifier would be a JWS (S256(state) ) (You might want to include code in the JWT but I need to think that = through) =20 So yes unless someone finds a flaw in that logic we may be able to = define some PKCE modes to mitigate against cut and paste. I didn=E2=80=99t think of defining a new PKCE mode at the time. You = should have been at the meeting:) =20 The security researcher documents are only informative references, and = yet the spec seems to rely on them normatively. E.g.: * "Mitigating the attacks also relies on the client sending additional = data about the interaction to the token endpoint" (how does this = mitigate the attacks? and what attack exactly?). * "a client may be confused simply because it is receiving = authorization responses from more than one authorization server" (why = is the client confused?) I would like to see the attacks normatively described in the spec. =20 For my own knowledge: what are some of the use-cases that are subject to = these attacks? I'm not convinced every RP that talks to more than 1 AS = is at risk today. What are some risky situations that exist which are = mitigated by this draft? =20 Any RP is at risk if one of the AS it talks to is compromised, it can = compromise all of the AS that the client talks to. That is just not a = good design. =20 Hans did a proof of concept that only required access to the logs of one = AS to compromise all AS. =20 John B. =20 =20 =20 On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) > wrote: Option A Phil > On Feb 19, 2016, at 13:39, Hans Zandbelt = wrote: > > Option A: I agree with Mike that the complexity and implementation = cost of Option B will make adoption harder, which was also a concern = with the first iteration of Option A. > > To be honest, I'm not sure most people would even understand why the = complexity would be required and just forget about it. At least with the = simplicity of the most recent option A they don't have to care, just add = some simple parameters/checks. > > And for the record: I've also implemented option A in the = mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and = NGINX respectively. > > Hans. > > [1] https://github.com/pingidentity/mod_auth_openidc > [2] https://github.com/pingidentity/lua-resty-openidc > >> On 2/19/16 9:18 PM, Mike Jones wrote: >> Option A. I have higher confidence that this specification solves = the >> problems because it was designed during a 4-day security meeting >> dedicated to this task by a group of over 20 OAuth security experts, >> *including both sets of researchers in Germany who originally = identified >> the problem*. This solution has also been implemented and interop >> tested by Roland Hedberg, Brian Campbell, and I believe others. Note >> that the reason I am advocating this specification is **not** because >> I'm an editor of it; my role was to record in spec language what the >> OAuth security experts designed together over the 4-day period in = Darmstadt. >> >> I=E2=80=99ll also note that even if Option B also solves the problem, = it comes >> at significant adoption costs and complexity not found in A. In >> particular, it requires that developers understand support a new = =E2=80=9CLink >> Relation=E2=80=9D syntax not used elsewhere in OAuth. As Nat writes = about his >> own draft in >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - = there >> is not a standard JSON syntax for link relations. He writes = =E2=80=9Cwe could >> easily create a parallel to it=E2=80=9D. I=E2=80=99d rather we solve = the problem using >> standard mechanisms already employed in OAuth, rather than risk >> bifurcating OAuth in the developer community by unnecessarily >> inventing/creating new syntax that is unfamiliar to developers and = that >> many of them may reject using. >> >> -- Mike >> >> P.S. Information about the OAuth security meeting can be found at >> = https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeX= zGptU4/edit >> and >> = https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5Ntak= VbA_sk/edit >> . >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >> Sent: Friday, February 19, 2016 11:43 AM >> To: oauth@ietf.org =20 >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for >> Adoption >> >> Early February I posted a mail to the list to make progress on the >> solution to the OAuth Authorization Server Mix-Up problem discovered >> late last year. >> >> Here is my mail about the Authorization Server Mix-Up: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >> >> Here is my mail to the list that tries to summarize the discussion >> status and asked a few questions: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >> >> Unfortunately, my mail didn't lead to the intended success. While = there >> was some feedback I wasn't getting the desired response. >> >> In order to move forward I believe we need a working group document = that >> serves as a starting point for further work in the group*. We have = two >> documents that provide similar functionality in an attempt to solve = the >> Authorization Server Mix-Up problem. >> >> So, here is the question for the group. Which document do you want as = a >> starting point for work on this topic: >> >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John = Bradley >> >> Link: >> >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >> >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake = and >> Sascha Preibisch >> >> Link: >> >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >> >> Deadline for feedback is March, 4th. >> >> Ciao >> >> Hannes & Derek >> >> PS: (*) Regardless of the selected solution we will provide proper >> acknowledgement for those who contributed to the work. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/oauth > > -- > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping = Identity > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org =20 > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_05B0_01D16D95.901699D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

[= case1] Code phishing + cut-n-paste attack

=C2= =A0=C2=A0[case1a] through BadAS to GoodAS = redirect

=C2= =A0 [case1b] through tampering the unprotected client access = response

=C2= =A0 [case1c] through the server log

[= case2] Token phishing (in case of implicit flow). =

[= case3] Code and Client credential phishing

<= o:p> 

A= ll of these seem to involve the tampering of the unprotected = communication.

I= f we can secure all the communication, the problem would be solved for = all the variants and for those that we still do not know. One way of = doing it is to use OAuth JAR and authorization response that includes ID = Token, but that=E2=80=99s not possible in many cases as I understand. =

W= e have to accommodate a measure that is proportionate to the risks. =

<= o:p> 

T= he risk impact of [case1] is that the code is stolen, and it is used = against the client to =E2=80=9Clogin=E2=80=9D to the client. The = attacker will not have an access to the access token. Is that right? If = that is the case, is this a case that we are really concerned of? Is it = not out of scope for OAuth? If so, we can punt this case to something = like a login protocol such as OpenID Connect. It also has the notion of = =E2=80=9Cissuer=E2=80=9D baked in, so there will be less conflict to use = the mix-up draft.

<= o:p> 

T= he risk impact of [case2] is more OAuth specific. The token is stolen as = the token is going to be sent to a rogue resource, and the resource can = use that to obtain the resource that was supposed to be only available = to the proper client.

<= o:p> 

T= he risk impact of [case3] is the most grave among these three. Now the = attacker can create his own client that impersonates the compromised = client.

<= o:p> 

O= Auth-mix-up

-= --------------------------

O= Auth-mix-up draft gives one way of addressing [case2] by introducing a = new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D = to RFC6749. It also returns client_id and verifies it in 4.2, but if the = BadAS has assigned a same client_id to the client, it does not help. =

<= o:p> 

B= y comparing the issuer stored in the session (the draft should be = explicit about it) with the issuer in the response, the client can find = out that the party he is getting the response from is not the one he = sent a request to, that communication was compromised/tampered with, = provided that the response is not tampered by the attacker in-browser. =

<= o:p> 

N= ote that the response may still be tampered (e.g., by MITB) so that the = issuer can be re-written, in which case the mitigation does not work, = but IMHO, we do not have to worry about it here, as with MITB, you can = do worse things easier.

<= o:p> 

O= ne of the issue with this approach is that the central notion of = =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the = authorization server that the client received when it registered at the = authorization server=E2=80=9D, but in most existing pure OAuth cases, = there is no such thing, so you cannot compare. This means that you would = have to re-register, and if you are doing that, the per-AS redirect_uri = seems to be a much simpler solution.

<= o:p> 

A= lso note that this is not a general framework for finding out tainted = communication, so it may have other holes.

<= o:p> 

O= Auth-meta

-= ------------------

O= Auth-meta is not designed as a specific fix to the problem. Rather, it = was designed as a general framework of providing the meta-data to the = responses by leveraging RFC5988 registry. It just happens to mitigate = this particular case.

<= o:p> 

A= gain, it is not a general framework for finding out tainted = communication, so it may have other holes.

<= o:p> 

P= er AS Redirect URI

-= -------------------------------

T= his does not involve wire protocol changes. It just adds requirements on = the redirect uri. This by far is the simplest solution for [case2] (and = [case1]), IMHO.

<= o:p> 

A= gain, it is not a general framework for finding out tainted = communication, so it may have other holes.

<= o:p> 

(= Extended) PKCE

-= --------------------------------

T= o begin with, it works only with code flow. There has to be something = else to deal with implicit flow.

<= o:p> 

P= KCE binds the authorization request/response to the token request. =

I= f used with a confidential client, it seems to mitigate the = vulnerability.

J= ohn points out that it is not the case. I must be missing something = here=E2=80=A6 but my logic goes like:

<= o:p> 

<= o:p> 

<= span style=3D'mso-list:Ignore'>1.     T= he good client creates code_challenge-v and = code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + = code_challenge-v + state to the BadAS Authz EP.

<= span style=3D'mso-list:Ignore'>2.     B= adAS as a client prepares a code_verifier-b and = code_challenge-b=3DS256(code_verifer-b).

<= span style=3D'mso-list:Ignore'>3.     B= adAS redirects to GoodAS with the client_id-v + code_challenge-b + = state-v.=C2=A0

<= span style=3D'mso-list:Ignore'>4.     G= oodAS stores the code_challenge-b.

<= span style=3D'mso-list:Ignore'>5.     G= oodAS returns code-v + state-v to the client=E2=80=99s redirect uri. =

<= span style=3D'mso-list:Ignore'>6.     T= he client finds the AS from the state and sends code-v + code_verifier-v = + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v = is phished.

<= o:p> 

N= ow the attacker tries to use the code-v and code_verifier-v. =

<= o:p> 

#= ## Case A:

<= span style=3D'mso-list:Ignore'>7.     T= he BadAS as a client sends client_id-v + =E2=80=A6 but he does not have = client secret for the good client, so it fails.

<= o:p> 

#= ## Case B:

<= span style=3D'mso-list:Ignore'>8.     T= he BadAS as a client sends client_id-b + code-v + code_verifier-b + = secret-b etc. to GoodAS.

<= span style=3D'mso-list:Ignore'>9.     G= oodAS verifies the code_verifier-b is associated with code-v, but that = code-v is not associated with client_id-b, so the token request fails. =

<= o:p> 

#= ## Case C: cut-n-paste

<= span style=3D'mso-list:Ignore'>10.  T= he attacker launches cut-n-paste attack by replacing the code-b with = code-v.

<= span style=3D'mso-list:Ignore'>11.  T= he verifiers does not match, so fails.

<= o:p> 

P= lease let me know what I am missing.

<= o:p> 

N= at

<= o:p> 

<= o:p> 

<= o:p> 

<= o:p> 

<= o:p> 

 

--=

PLEASE READ :This = e-mail is confidential and intended for the

named recipient = only. If you are not an intended recipient,

please notify the = sender=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Saturday, February 20, 2016 9:16 = PM
To: William Denniss
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] Fixing the = Authorization Server Mix-Up: Call for = Adoption

 

Inline

On Feb 20, 2016, at 9:49 AM, = William Denniss <wdenniss@google.com> = wrote:

 

Maybe it's because I wasn't at the = Darmstadt meeting so I don't have the full context, but I don't find draft A to be all that clear. Here's my = review feedback:

 

Regarding the text "a client = may be confused simply because it is receiving authorization responses = from more than one authorization server at the same redirection = endpoint". Even if the client re-uses the same redirection = endpoint, shouldn't state solve this? All incoming responses should have = an outgoing request with a matching state that would identify the = authorization request and therefore authorization = server.

 

If only that were the case.   = That is the nub of the problem people think state works to do that, but = it enables the attack not stops it.

 

State contains where the client = sends the request.   The client assumes any response following that = is from the AS it sent the request to. =  

Most of the attacks documented take advantage of this by = misdirecting the request to a different AS than the one the client = =E2=80=9Cthinks=E2=80=9D it is making the request to. =  

 

This is done in two ways. One is by = pointing at another AS=E2=80=99s authorization endpoint as part of = registration, and the other is by redirecting and rewriting the = authorization request.

 

The client thinking it has a = response from a AS based on state then uses the associated token and RS = endpoints.   Those endpoints are wrong for the AS that really = returned the response.   Thus the client becomes a proxy for = relaying responses from the target = AS.

 

Both mitigations attempt to = mitigate this by having the AS return something that can be compared = with state to determine if the request has been = misdirected.

 

In one case we return a logical = identifier (Name) for the AS that is compared to a name provided as part = of client setup.  This name can optionally be used as the input to = discovery to verify other meta-data about the = AS.

 

In the second mitigation the URI of = the token endpoint or resource server is = returned.

 

They both provide a way for the = client to determine if the stored state is invalid because the response = is coming from a different place than the request went = to.

 

It was noted by the researchers = that the OIDC flow =E2=80=9Ccode id_token=E2=80=9D was not susceptible = to this attack because the client validates the issuer of the id_token = and the client_id that the AS thinks it is responding to (some of the = attacks rewrite the client_id in the = request).

 

For reference http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValida= tion points 2 & 3 of the OIDC = validation.

 

Knowing that works based on = researcher feedback, the first option allows the two id_token claims to = be returned from the Authorization endpoint without forcing OAuth = clients to support signed JWT.   It also allows AS to provide a = issuer URI but allows clients to compare the strings without forcing = them to do discovery.   Clients that do discovery can use this = value to bootstrap/validate that.   This takes advantage of = validation that some clients already perform and applies it to the code = response.

 

The second option from Nat allows = the client to compare the token_endpoint URI from configuration to the = one in the response.  A difference would indicate that the AS is = different, in a similar way to the other option. =  

 

The difference is that the second = option doesn=E2=80=99t include the client_id and while I don=E2=80=99t = have an attack against that off the top of my head, it was felt that it = is a open attack surface and should be closed. =  

 

The other difference is I think = more subtle and changes OAuth in the second option (Nat probably argues = that would be a good thing).

OAuth to this point assumes that = the client is in charge, that the developer configures the endpoints etc = via service documentation.

In the authorization request or the = AT request the AS has no information about what RS is being used as part = of the protocol.

 

The second option changes that by = providing link relationships where each step provides meta data about = where to use the result.

The Authorization endpoint points = to the token endpoint, the token endpoint points to the resource server = and the resource server points to the Authorization endpoint.   To = get that to work for a number of uses cases you probably need to tell = the authorization endpoint and possibly the token endpoint what resource = or resources you want the scopes for.    A given AS might have = more than one token endpoint (not common but not precluded,  but = something that might happen in multi tenant or other special cases), and = if it is using JWT access tokens it may not even know about the given = RS.

 

So to be able to give the meta-data = for the next hop the endpoint responding may need more = information.

 

The two mitigations are not = incompatible, we could do both.

 

I do however think that the second = one may have architectural side effects that we need to more fully = discuss.  

Adding link relation/follow your = nose processing to OAuth may be a good thing, but may have impacts that = we have not fully thought through = yet.

 

 
 

For the issue of dynamic discovery = and the potential to insert a malicious discovery document: can the = recommendation be to use the hybrid flow of Connect if you do discovery = (and validate the issuer before exchanging the code)?  Do we need = to invent something new for this = use-case?

 

As above this would work , but we = don;t want to force all OAuth clients to have to deal with JWT.   = This would be a fix for Connect if we were only concerned about = that.



 

Regarding sections 5 & 6 = ("Mitigation Data Sent to the Token Endpoint"), this describes = something that seems similar to what is achieved by PKCE (RFC7636). = Binding information to the authorization code that must be presented to = redeem the code is precisely what PKCE does, and PKCE has additional = security properties. With the PKCE S256 challenge method, the = authorization request and response can leak in their entirety, and yet = still the attacker couldn't exchange the authorization code. Let's just = recommend RFC7636 for this = mitigation.

 

Unfortunately PKCE = makes the assumption that attacker cannot modify the request.  In = this case the attacker can modify the = request. 

 

PKCE provides protection in cases = where the attacker can=E2=80=99t modify the PKCE challenge in the = request. 

If the attacker can modify the = request then they make a new request in a second browser to get the PKCE = challenge and replace the one in the request being modified by that = one.

 

I need to think about it a bit more = but there might be a way to do it by defining a new PKCE = method. 

 

If the code_challenge  were a = HASH of state || code_verifyer, that would do both. =   

 

The server would need to store = state and code_challange.  The client would just calculate the hash = over both, but still send the same = code_verifier.

( optimization would be for the = code_challange =3D=3D S256 (S256(state) || code_verifier)  that way = the AS only needs to store the hash of = state)

 

The attacker can=E2=80=99t change = the state in the first request, or the client will reject the response, = and because the code_verifyer will be different between the requests the = AS would reject the second one because the code_challange will be = wrong.

 

That is more complicated for the = client, but would allow you to do it with PKCE with no more crypto than = PKCE S256 (the MTI) already requires.

 

For Asymmetric PKCE the = code_challange would be a JWK of the public key and the code_verifier = would be a JWS (S256(state) )

(You might want to include code in = the JWT but I need to think that = through)

 

So yes unless someone finds a flaw = in that logic we may be able to define some PKCE modes to mitigate = against cut and paste.

I didn=E2=80=99t think of defining = a new PKCE mode at the time.  You should have been at the = meeting:)

 



<= p class=3DMsoNormal>The security researcher documents = are only informative references, and yet the spec seems to rely on them = normatively. E.g.:

*  "Mitigating the = attacks also relies on the client sending additional data about the = interaction to the token endpoint" (how does this mitigate the = attacks? and what attack exactly?).

*  "a client may be = confused simply because it is receiving authorization responses = from more than one authorization server"  (why is the = client confused?)

I would like to see the attacks = normatively described in the spec.

 

For my own knowledge: what are some = of the use-cases that are subject to these attacks? I'm not convinced = every RP that talks to more than 1 AS is at risk today. What are some = risky situations that exist which are mitigated by this = draft?

 

Any RP is at risk if one of the AS = it talks to is compromised, it can compromise all of the AS that the = client talks to.  That is just not a good = design.

 

Hans did a proof of concept that = only required access to the logs of one AS to compromise all = AS.

 

John = B.

 

 

 

On Fri, Feb 19, 2016 at 9:12 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> = wrote:

Option A

Phil

> On Feb 19, 2016, at 13:39, = Hans Zandbelt <hzandbelt@pingidentity.com= > wrote:
>
> Option A: I agree with Mike that the = complexity and implementation cost of Option B will make adoption = harder, which was also a concern with the first iteration of Option = A.
>
> To be honest, I'm not sure most people would even = understand why the complexity would be required and just forget about = it. At least with the simplicity of the most recent option A they don't = have to care, just add some simple parameters/checks.
>
> = And for the record: I've also implemented option A in the = mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and = NGINX respectively.
>
> Hans.
>
> [1] https://github.com/pingidentity/mod_auth_openidc> [2] https://github.com/pingidentity/lua-resty-openidc>
>> On 2/19/16 9:18 PM, Mike Jones wrote:
>> = Option A.  I have higher confidence that this specification solves = the
>> problems because it was designed during a 4-day security = meeting
>> dedicated to this task by a group of over 20 OAuth = security experts,
>> *including both sets of researchers in = Germany who originally identified
>> the problem*.  This = solution has also been implemented and interop
>> tested by = Roland Hedberg, Brian Campbell, and I believe others.  = Note
>> that the reason I am advocating this specification is = **not** because

>> I'm an editor of it; my = role was to record in spec language what the
>> OAuth security = experts designed together over the 4-day period in = Darmstadt.
>>
>> I=E2=80=99ll also note that even if = Option B also solves the problem, it comes
>> at significant = adoption costs and complexity not found in A.  In
>> = particular, it requires that developers understand support a new = =E2=80=9CLink
>> Relation=E2=80=9D syntax not used elsewhere in = OAuth.  As Nat writes about his
>> own draft = in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5789.html - there
>> is not a standard JSON syntax for link = relations.  He writes =E2=80=9Cwe could
>> easily create a = parallel to it=E2=80=9D.  I=E2=80=99d rather we solve the problem = using
>> standard mechanisms already employed in OAuth, rather = than risk
>> bifurcating OAuth in the developer community by = unnecessarily
>> inventing/creating new syntax that is = unfamiliar to developers and that
>> many of them may reject = using.
>>
>>            =                     =                     =        -- Mike
>>
>> P.S.  = Information about the OAuth security meeting can be found at
>> = https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZ= RhkmfmHAlJ6kM5OyeXzGptU4/edit
>> and
>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PU= pNRpi_u_EoSpO5NtakVbA_sk/edit
>> .
>>
>> = -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Hannes Tschofenig
>> Sent: Friday, February 19, 2016 = 11:43 AM
>> To: oauth@ietf.org
>> Subject: = [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
>> = Adoption
>>
>> Early February I posted a mail to the = list to make progress on the
>> solution to the OAuth = Authorization Server Mix-Up problem discovered
>> late last = year.
>>
>> Here is my mail about the Authorization = Server Mix-Up:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5336.html
>>
>> Here is my mail to the list that = tries to summarize the discussion
>> status and asked a few = questions:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5697.html
>>
>> Unfortunately, my mail didn't lead = to the intended success. While there
>> was some feedback I = wasn't getting the desired response.
>>
>> In order to = move forward I believe we need a working group document that
>> = serves as a starting point for further work in the group*. We have = two
>> documents that provide similar functionality in an = attempt to solve the
>> Authorization Server Mix-Up = problem.
>>
>> So, here is the question for the group. = Which document do you want as a
>> starting point for work on = this topic:
>>
>> -- Option A: 'OAuth 2.0 Mix-Up = Mitigation' by Mike Jones and John Bradley
>>
>> = Link:
>>
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mi= tigation-01
>>
>> -- Option B: 'OAuth Response = Metadata' by Nat Sakimura, Nov Matake and
>> Sascha = Preibisch
>>
>> Link:
>>
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-0= 7
>>
>> Deadline for feedback is March, = 4th.
>>
>> Ciao
>>
>> Hannes & = Derek
>>
>> PS: (*) Regardless of the selected = solution we will provide proper
>> acknowledgement for those = who contributed to the = work.
>>
>>
>>

>> = _______________________________________________
>> OAuth = mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=
> --
> Hans Zandbelt          =     | Sr. Technical Architect
> hzandbelt@pingidentity.com= | Ping Identity
>
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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

 

------=_NextPart_000_05B0_01D16D95.901699D0-- From nobody Mon Feb 22 01:44:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3631B2F0E for ; Mon, 22 Feb 2016 01:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lveDpsNpZKdz for ; Mon, 22 Feb 2016 01:44:28 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 D5C9C1B2EEB for ; Mon, 22 Feb 2016 01:44:27 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id of3so78596762lbc.1 for ; Mon, 22 Feb 2016 01:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=FDOAyR9pj8XVGr4Eh+E4x/hoJlOzVi7VjWJC52g6SXo=; b=BPHxaUDdNWo+hAeE/VmPwjOPC3ZLaxmAmzyEl7AC09EUuTEM9Lmxn2x753V0WAL+AB hzV78cT3tKTsFBXs/HF1pZnqgPGHpezNhc1fkZw270YFX8e1c/tbZUlKOgHkSeRis8+d Tj1ByAJSDRW1Nz8CbZzcCmeRa9mcTnCpwMLGgpbWTLIocUDqC17rKDZh4AavaeYiZGMr 6Pz8Mqtsh62NgdaIyuNO5l9o/0+YVtFEAwsLhLb1cRyUwY6VgNdUmPYO1uPlHwbW/wN8 PCbQmkvQHlxktiiuOCiyVxh515kJRFhLXnk1khWHhpcz8mAwHub5d3b9uZhLHbiVGLiD 0O3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=FDOAyR9pj8XVGr4Eh+E4x/hoJlOzVi7VjWJC52g6SXo=; b=O/RyjZGxbkKPIh/IVtcYJdIJYauR0hfhYSqLT/cDa44fFuOZHY59EESIllO0JGkkWs rulXnYWRPpU1QSgqtOtFMOhuGR3UfGy2SY8J5G28UMRecPT+GuCcASMzQMsNKDur4+n0 OwD2i0XReng/3+05jOlZgJ2Q6Yi2XoqZqOknHdS8/qM85dOrpKDDdszCzMskF+Y2Vi9/ EdPFwV+7QtORMnHz2/EP27w3AAEXMn/F45PHzzFPXdBIHuO/0bkoGTGyvLS6yAd/N4lv 6dUf6mxLtQYQTfMqNdltBYAhlotZILlQyo2PHYjDgTrWzIuGW9vzaECs9CnZEAJu56TO W4tA== X-Gm-Message-State: AG10YOTXOFq/SFy80SFyB2JM3phqw6e9Gx2FErXbvTggplUx6b3Vxzl4jaWfa2T3HYx/g9kcByd5iVStrTkzPQ== X-Received: by 10.112.35.162 with SMTP id i2mr9589611lbj.107.1456134266152; Mon, 22 Feb 2016 01:44:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Broyer Date: Mon, 22 Feb 2016 09:44:16 +0000 Message-ID: To: Justin Richer , "" Content-Type: multipart/alternative; boundary=001a11c36b66adf063052c58adac Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 09:44:30 -0000 --001a11c36b66adf063052c58adac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Couldn't the document only describe the metadata? I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration". The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect). With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed (well, except if there are several ASs each with different scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?) On Fri, Feb 19, 2016 at 10:59 PM Justin Richer wrote: > The newly-trimmed OAuth Discovery document is helpful and moving in the > right direction. It does, however, still have too many vestiges of its > OpenID Connect origins. One issue in particular still really bothers me: > the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the dis= covery portion. Is > this an OAuth discovery document, or an OpenID Connect one? There is > absolutely no compelling reason to tie the URL to the OIDC discovery > mechanism. > > I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2= =80=9D as the > default discovery location, and state that the document MAY also be > reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the= server also > provides OpenID Connect on the same domain. Other applications SHOULD use > the same parameter names to describe OAuth endpoints and functions inside > their service-specific discovery document. > > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c36b66adf063052c58adac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Couldn't the document only describe the metadata?
= I quite like the idea of=C2=A0draft-sakimura-oauth-meta if you really want = to do discovery, and leave it open to implementers / to other specs to defi= ne a .well-known URL for "auto-configuration".
The meta= data described here would then either be used as-is, at any URL, returned a= s=C2=A0draft-sakimura-oauth-meta metadata at the RS; or as a basis for othe= r metadata specs (like OpenID Connect).
With=C2=A0draft-sakimura-oa= uth-meta's "duri" and the "scope" attribute of WWW-= Authenticate response header, you have everything you need to proceed (well= , except if there are several ASs each with different scopes; sounds like a= n edge-case to me though; maybe RFC6750 should instead be updated with such= a parameter such that an RS could return several WWW-Authenticate: Bearer,= each with its own "scope" and "duri" value?)

On Fri, Feb 19, 2016 at 10:59 PM = Justin Richer <jricher@mit.edu>= ; wrote:
The newly-trimmed OAuth Di= scovery document is helpful and moving in the right direction. It does, how= ever, still have too many vestiges of its OpenID Connect origins. One issue= in particular still really bothers me: the use of =E2=80=9C/.well-known/op= enid-configuration=E2=80=9D in the discovery portion. Is this an OAuth disc= overy document, or an OpenID Connect one? There is absolutely no compelling= reason to tie the URL to the OIDC discovery mechanism.

I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2= =80=9D as the default discovery location, and state that the document MAY a= lso be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D i= f the server also provides OpenID Connect on the same domain. Other applica= tions SHOULD use the same parameter names to describe OAuth endpoints and f= unctions inside their service-specific discovery document.

=C2=A0=E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11c36b66adf063052c58adac-- From nobody Mon Feb 22 03:57:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AE21A001B for ; Mon, 22 Feb 2016 03:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBQ2Mrf1snr0 for ; Mon, 22 Feb 2016 03:57:08 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04881A001A for ; Mon, 22 Feb 2016 03:57:07 -0800 (PST) X-AuditID: 1209190e-c13ff70000002722-b6-56caf792882f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E6.83.10018.297FAC65; Mon, 22 Feb 2016 06:57:06 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1MBv5bN001622; Mon, 22 Feb 2016 06:57:05 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1MBv3OL028769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Feb 2016 06:57:05 -0500 To: Thomas Broyer , "" References: From: Justin Richer Message-ID: <56CAF78E.3060607@mit.edu> Date: Mon, 22 Feb 2016 06:57:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050302090601090900010105" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nojvp+6kwg/1X+SxOvn3FZnH830Vm ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj7u9PjAXzLSvaNx1kb2Bs0+pi5OSQEDCR mHO+i6mLkYtDSKCNSaJz5gEWCGcjo0TL2h42COc2k8Szo/8YQVqEgVoeTp3GCmKLCHhLNGy/ xQhR1Mgo0XdzPhtIgk1AVWL6mhYmEJtXQE3iyb9vYDYLUPzQux3sILaoQIzE8XfnGCFqBCVO znzCAmJzCgRKLF90GayGWSBMovdDE/MERr5ZSMpmIUlB2GYS8zY/hLLlJZq3zgayOYBsNYll rUrIwgsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbopaaUbmIEhTCnJN8Oxq8HlQ4x CnAwKvHwajCdChNiTSwrrsw9xCjJwaQkyts8GSjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhLft AVCONyWxsiq1KB8mJc3BoiTOG3PzaJiQQHpiSWp2ampBahFMVoaDQ0mCN/QbUKNgUWp6akVa Zk4JQpqJgxNkOA/QcAaQGt7igsTc4sx0iPwpRkUpcV5dkIQASCKjNA+uF5RiEt4eNn3FKA70 ijCvHkgVDzA9wXW/AhrMBDT49jawwSWJCCmpBkb219tCS/avdTg73dNmhuUe9yWyv17sCJ3N tXHBKgXOx60L9zRPPr+r4aLXtQcXqqOK85zKDvaXCD6QVyj5KCZ/WCKlSn1VgNQivYddtz1O sv6Pu7p8nsEiyevxOSZLTnGdjZcNsv2eJppfzJGsH52btCvy0tktooIMMx0cqlQnCV7l2M34 56USS3FGoqEWc1FxIgDwxEbqDAMAAA== Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 11:57:11 -0000 This is a multi-part message in MIME format. --------------050302090601090900010105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I think you can really do both parts in the document without harm. Specifying a ".well-known" location doesn't preclude you from including the same metadata elsewhere as well, such as with oauth-meta or with a service-specific discovery document (like openid-configuration). But it would be nice to have a generic authorization server discovery endpoint that I can build for a domain so I don't have to always find somewhere to put it. -- Justin On 2/22/2016 4:44 AM, Thomas Broyer wrote: > Couldn't the document only describe the metadata? > I quite like the idea of draft-sakimura-oauth-meta if you really want > to do discovery, and leave it open to implementers / to other specs to > define a .well-known URL for "auto-configuration". > The metadata described here would then either be used as-is, at any > URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a > basis for other metadata specs (like OpenID Connect). > With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of > WWW-Authenticate response header, you have everything you need to > proceed (well, except if there are several ASs each with different > scopes; sounds like an edge-case to me though; maybe RFC6750 should > instead be updated with such a parameter such that an RS could return > several WWW-Authenticate: Bearer, each with its own "scope" and "duri" > value?) > > On Fri, Feb 19, 2016 at 10:59 PM Justin Richer > wrote: > > The newly-trimmed OAuth Discovery document is helpful and moving > in the right direction. It does, however, still have too many > vestiges of its OpenID Connect origins. One issue in particular > still really bothers me: the use of > “/.well-known/openid-configuration†in the discovery portion. Is > this an OAuth discovery document, or an OpenID Connect one? There > is absolutely no compelling reason to tie the URL to the OIDC > discovery mechanism. > > I propose that we use “/.well-known/oauth-authorization-server†as > the default discovery location, and state that the document MAY > also be reachable from “/.well-known/openid-configuration†if the > server also provides OpenID Connect on the same domain. Other > applications SHOULD use the same parameter names to describe OAuth > endpoints and functions inside their service-specific discovery > document. > > — Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------050302090601090900010105 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think you can really do both parts in the document without harm. Specifying a ".well-known" location doesn't preclude you from including the same metadata elsewhere as well, such as with oauth-meta or with a service-specific discovery document (like openid-configuration). But it would be nice to have a generic authorization server discovery endpoint that I can build for a domain so I don't have to always find somewhere to put it.

 -- Justin

On 2/22/2016 4:44 AM, Thomas Broyer wrote:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed (well, except if there are several ASs each with different scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration†in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

I propose that we use “/.well-known/oauth-authorization-server†as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration†if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.

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

--------------050302090601090900010105-- From nobody Mon Feb 22 04:08:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64B71A039C for ; Mon, 22 Feb 2016 04:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 r_y59EORDLnu for ; Mon, 22 Feb 2016 04:08:45 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CED1A039E for ; Mon, 22 Feb 2016 04:08:40 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id g62so160460534wme.0 for ; Mon, 22 Feb 2016 04:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=6ekQcQcLidRWR1s+Z7Zhw4uFbRvrmNKAU4uF2x5zbcw=; b=Tnhh4NCQ9lG3P00FIUbk2J/gVrMthXNhDhARWukuJ7+gcaMPMyiMIDnmX8bCkcF8lV xkbTqPdsGdqlUvBOMnutFRakM1wM+xbD2S2LJ3YulVN1F5DIFM8Wuk//FX5N/0a9Eqm5 8PnTMJCoA+MNgjAkNrLkggLKLfvG5/ztO8E/N2AgO9cLpQaYWCLmwz9vqHGMTIzn48vT plf0iVNjdvIbeVBSJE2WiyAO/uETcTFLdrzyUFHBPp8w2hrgo0hYMJon+n4BhmtRQRP8 d/PTX761JQaPyFwYyA7ykDDmZ8tThG+3k5Kg8fAzoWVp4IkcC37KZ9qDc1E+C8YXBDrW tqfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=6ekQcQcLidRWR1s+Z7Zhw4uFbRvrmNKAU4uF2x5zbcw=; b=SIJsgSLCQnYKI5FyDYWj5VXeZBks70ffctG0B7qU3oYgcCBbxzoQiHQacZro4G71uf txdoPCCwQsK0LeLyi/XI+H2BPBXDjXZ4CoHzyA/xRkPnxmRLZEtp96RZPfp+acH/0j4U IiaSt7EtymL82WK0FA89KCzxM+LqEXMOM4/4TKHj7qpu/6Dd+DVicFcsoJQTNvGNiAte 4z9fonV9gfit/4O3cX4yzfmIHa2ghQmK7fMCJvucMks2ymg9kO92jGq1LWSU4NspTxdy K8l20cPKtmtsHsZvdnVbmHCwxeJ8Skh/a74f0oRHUez/AlPi6CwCGRwGXrVz1VoJtdGX GaDw== X-Gm-Message-State: AG10YORpc9ge1uiYJ2tSj5USLQOlm7JPRyDrJBTzI7NWxaWZU5iQKv2SxQwWdwMaPqlYYA== X-Received: by 10.28.92.13 with SMTP id q13mr11389766wmb.43.1456142919228; Mon, 22 Feb 2016 04:08:39 -0800 (PST) Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id b5sm20828983wmh.15.2016.02.22.04.08.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Feb 2016 04:08:37 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BD93B3C4-7E00-49D5-B884-246CD4110786"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <05af01d16d4a$20230af0$606920d0$@nri.co.jp> Date: Mon, 22 Feb 2016 13:08:35 +0100 Message-Id: <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> To: Nat Sakimura X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 12:08:54 -0000 --Apple-Mail=_BD93B3C4-7E00-49D5-B884-246CD4110786 Content-Type: multipart/alternative; boundary="Apple-Mail=_B50948B7-C090-44B0-A72E-AC3284EBAFCC" --Apple-Mail=_B50948B7-C090-44B0-A72E-AC3284EBAFCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline > On Feb 22, 2016, at 9:22 AM, Nat Sakimura = wrote: >=20 > [case1] Code phishing + cut-n-paste attack=C2=A0 <> > [case1a] through BadAS to GoodAS redirect > [case1b] through tampering the unprotected client access response > [case1c] through the server log > [case2] Token phishing (in case of implicit flow).=20 > [case3] Code and Client credential phishing > =20 > All of these seem to involve the tampering of the unprotected = communication.=20 > If we can secure all the communication, the problem would be solved = for all the variants and for those that we still do not know. One way of = doing it is to use OAuth JAR and authorization response that includes ID = Token, but that=E2=80=99s not possible in many cases as I understand.=20 > We have to accommodate a measure that is proportionate to the risks.=20= > =20 > The risk impact of [case1] is that the code is stolen, and it is used = against the client to =E2=80=9Clogin=E2=80=9D to the client. The = attacker will not have an access to the access token. Is that right? If = that is the case, is this a case that we are really concerned of? Is it = not out of scope for OAuth? If so, we can punt this case to something = like a login protocol such as OpenID Connect. It also has the notion of = =E2=80=9Cissuer=E2=80=9D baked in, so there will be less conflict to use = the mix-up draft.=20 In this case with OAuth the information protected by the AT can still be = stolen. While the attacker doesn=E2=80=99t get the AT directly it gets = control of a client that has the AT. If I link my Flikr account to = your private Flikr feed, you as the Resource owner is still compromised. = Arguing that OAuth didn=E2=80=99t leak the token is not a good = argument. OAuth needs to protect against this. > =20 > The risk impact of [case2] is more OAuth specific. The token is stolen = as the token is going to be sent to a rogue resource, and the resource = can use that to obtain the resource that was supposed to be only = available to the proper client.=20 > =20 > The risk impact of [case3] is the most grave among these three. Now = the attacker can create his own client that impersonates the compromised = client.=20 > =20 > OAuth-mix-up > --------------------------- > OAuth-mix-up draft gives one way of addressing [case2] by introducing = a new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D = to RFC6749. It also returns client_id and verifies it in 4.2, but if the = BadAS has assigned a same client_id to the client, it does not help.=20 Client_id are not guaranteed to be unique. They need to be name spaced = by the AS. In OAuth currently we have no name for the AS this makes = that difficult, the client can use the authorization endpoint URI, but = that logic may well break in multi tenant situations. Having a clear = issuer string makes it easier for the client. =20 > =20 > By comparing the issuer stored in the session (the draft should be = explicit about it) with the issuer in the response, the client can find = out that the party he is getting the response from is not the one he = sent a request to, that communication was compromised/tampered with, = provided that the response is not tampered by the attacker in-browser.=20= Yes > =20 > Note that the response may still be tampered (e.g., by MITB) so that = the issuer can be re-written, in which case the mitigation does not = work, but IMHO, we do not have to worry about it here, as with MITB, you = can do worse things easier.=20 Yes > =20 > One of the issue with this approach is that the central notion of = =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the = authorization server that the client received when it registered at the = authorization server=E2=80=9D, but in most existing pure OAuth cases, = there is no such thing, so you cannot compare. This means that you would = have to re-register, and if you are doing that, the per-AS redirect_uri = seems to be a much simpler solution.=20 The client developers I have talked to really hate per AS redirect URI = as being too awkward for deployments. =20 The client would not need to re register to add a issuer URI to its = client_id record. That is one of the ways to do it. > =20 > Also note that this is not a general framework for finding out tainted = communication, so it may have other holes.=20 > =20 > OAuth-meta > ------------------- > OAuth-meta is not designed as a specific fix to the problem. Rather, = it was designed as a general framework of providing the meta-data to the = responses by leveraging RFC5988 registry. It just happens to mitigate = this particular case.=20 > =20 > Again, it is not a general framework for finding out tainted = communication, so it may have other holes.=20 Without sending the resource in the request, the Authorization endpoint, = and token endpoints are not necessarily going to be able to return the = correct next hop. My biggest concern is that this potentially moves some of the client = logic into the AS. I don=E2=80=99t know that that is a bad thing but = it feels to me like a real change to OAuth as it currently is. I think = we need to really think about this change, and how it will impact OAuth = overall. =20 I see this as potentially complimentary OAuth mix up returning a logical = name for the AS. > =20 > Per AS Redirect URI > -------------------------------- > This does not involve wire protocol changes. It just adds requirements = on the redirect uri. This by far is the simplest solution for [case2] = (and [case1]), IMHO.=20 > =20 > Again, it is not a general framework for finding out tainted = communication, so it may have other holes. This is probably the hardest for the client developer and for the = deployer. Yes it is simplest from a spec point of view.=20 We need more developer feedback on this. > =20 > (Extended) PKCE > --------------------------------- > To begin with, it works only with code flow. There has to be something = else to deal with implicit flow.=20 > =20 > PKCE binds the authorization request/response to the token request.=20 > If used with a confidential client, it seems to mitigate the = vulnerability.=20 > John points out that it is not the case. I must be missing something = here=E2=80=A6 but my logic goes like:=20 > =20 > =20 > 1. The good client creates code_challenge-v and = code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + = code_challenge-v + state to the BadAS Authz EP.=20 > 2. BadAS as a client prepares a code_verifier-b and = code_challenge-b=3DS256(code_verifer-b).=20 > 3. BadAS redirects to GoodAS with the client_id-v + = code_challenge-b + state-v. =20 > 4. GoodAS stores the code_challenge-b.=20 > 5. GoodAS returns code-v + state-v to the client=E2=80=99s = redirect uri.=20 > 6. The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished.=20 > =20 > Now the attacker tries to use the code-v and code_verifier-v.=20 > =20 > ### Case A: > 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he does = not have client secret for the good client, so it fails.=20 > =20 > ### Case B:=20 > 8. The BadAS as a client sends client_id-b + code-v + = code_verifier-b + secret-b etc. to GoodAS.=20 > 9. GoodAS verifies the code_verifier-b is associated with code-v, = but that code-v is not associated with client_id-b, so the token request = fails.=20 > =20 > ### Case C: cut-n-paste > 10. The attacker launches cut-n-paste attack by replacing the code-b = with code-v.=20 > 11. The verifiers does not match, so fails.=20 > =20 > Please let me know what I am missing.=20 In a step 0 the attacker has the good client create another request in = the attackers user agent to get state-0 and code_challange-0 Step 2 is not required. Step 3 Bad AS redirects to good AS with client_id_v + state-v + = code_challenge-0 Step 4 GoodAS stores code_challenge-0 Step 5 GoodAS returns code-v + state-v to the clients redirect_uri Step 6 The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished.=20 Case C1 : cut and paste 10. The attacker launches cut-n-paste attack by inserting code-v into a = response using state-0 11. The client sends code-v and based on state-0 it sends = code_verifyer-0 to the good AS token endpoint. 12. The GoodAS verifies that code-verifyer-0 is correct for = code_challange-0 that it bound to code in step 4 13. The GoodAS receives RT + AT. 14. The attacker has now used the client to bind the users resource to = it=E2=80=99s account and is transferring money or looking at your data. This could be 3rd party financial app like Mint as an example or photos = or any other PII that could then be used to escalate identity theft. This variation of the attack combining cut and paste with confused = client was not mentioned in the research papers. I found it looking to see if PKCE could be used to mitigate the confused = client attack. As I mentioned in a response to William, while the current PKCE = Challenge methods only make the attack harder by forcing the attacker to = get the client to make a step 0 request to get a code_challenge to use = in the request, we could define a new challenge method that would be = effective. That would remove the need to have a separate mechanism to prevent cut = and paste. The problem is that the PKCE challenge is independent of state so = becomes vulnerable to the confused client. What we would need to do is include state in the challenge so that if = the AS receives mismatched state and code_challange in step 3 the = verification of code verifier will fail. Effectively combining the cut = and paste mitigation with PKCE. I haven=E2=80=99t had time to write this up, but if the code_challenge = =3D=3D SHA256 (SHA256(state) || token_endpoint URI || = Authorization_endpoint URI || client_id || code-veriyer) , then the = attacker could not change state, client_id, or token_endpoint = independently of code_challenge. (note I am using a hash of state to = make storage size deterministic for the AS on the grounds that the = client already needs to be able to do the hash) (Some attacks change = the client_id in the request so I am including it in the hash) This is slightly more complicated than than S256, but not that much. I = wish I had thought of this when we were doing PKCE. Hit me with the = stupid stick, my fault. I don=E2=80=99t know if it stops all the confused client attacks though. If the client is confidential then it gives up it=E2=80=99s client = secret assuming compromised registration, so we can=E2=80=99t really = count on that for symmetric client authentication. By including the token endpoint in the comparison if the client is = sending the code to the attacker the client will use a different token = endpoint_uri in to calculate the code_challenge than the GoodAS will use = to verify it. This would stop both cut and paste as well as stopping = the attacker from using the code if they get it. The attacker can=E2=80=99= t get Secret for state-0, so it can=E2=80=99t create code_challenge that = would be valid. This stops the registration attack where the client gets a bad AS = discovery endpoint that has all the Good AS info including dynamic = registration endpoint but the bad AS token endpoint. The bad AS would = get the token, client_secret and code_verier, but will fail pkce = verification because the token endpoint will be wrong. The attack where the client registers with the good AS but with bad = token endpoint and Authorization endpoint gives the attacker the ability = to change the code_challenge that the Good AS is going to see. It = would need to make a new challenge using state and the GoodAS token = endpoint and it=E2=80=99s client_id. =20 To do that it needs the code_verifier to use to calculate the hash to = use as the code_challenge value. As long as the client is not tricked = into accepting a replay of the authentication response we should be = safe. The client would need to do replay protection on the = code_verifier values before it makes a request to the token endpoint. =20= The BadAS could however make up a new code_challenge and code_verifier = and use that in the request. For this one the AS would need to do pull = discovery on the client to get a key, or the AS needs to return = something in the response. This attack can completely proxy all the = endpoints as far as the client is concerned and is taking advantage of = the AS saying you are granting permission to site X based on the = redirect URI. =20 I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a client = from being used as a redirector back to the attacker unless you also = returned the code_challenge in the response from the authorization = endpoint. Hypothetically if we returned code_challenge in the response from the = authorization endpoint and have a new PKCE challenge method we might = find it covers all of the attacks. We would need to put some serious analysis into this to see if it really = covers all the attacks.=20 It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D = response_type or steeling the access token by impersonating the RS.=20 I think the correct way to stop the problem with access tokens is by = audience restricting them. =20 To do that the client needs to provide an audience in it=E2=80=99s = request and the AS needs to include that in the AT. I included the Authorization_endpoint URI in the hash to detect if the = auth request may have been tampered with to change the audience for the = AT. For implicit we could have a version of PKCE where the AS returns a = parameter with S256( client_id || authorization_endpoint URI || resource = endpoint URI) to verify the request was not tampered with, and that = would allow the AT to be properly audience restricted.=20 This would be a completely new approach not involving discovery, logical = names for AS, or link relations. Effectively this code_challenge method becomes a signature over parts of = the request and the implicit audience of the token_endpoint URI. =20 People keep asking why PKCE doesn=E2=80=99t stop these attacks, and it = won=E2=80=99t with the current PKCE methods, however a new method along = the lines I sketched out may let it work, or I could be completely = wrong. Too bad I don=E2=80=99t think I will make RSA to go over this in person. John B. > =20 > Nat > =20 > =20 > =20 > =20 > =20 > =20 > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Saturday, February 20, 2016 9:16 PM > To: William Denniss > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call = for Adoption > =20 > Inline >> On Feb 20, 2016, at 9:49 AM, William Denniss = wrote: >> =20 >> Maybe it's because I wasn't at the Darmstadt meeting so I don't have = the full context, but I don't find draft A to be all that clear. Here's = my review feedback: >> =20 >> Regarding the text "a client may be confused simply because it is = receiving authorization responses from more than one authorization = server at the same redirection endpoint". Even if the client re-uses the = same redirection endpoint, shouldn't state solve this? All incoming = responses should have an outgoing request with a matching state that = would identify the authorization request and therefore authorization = server. > =20 > If only that were the case. That is the nub of the problem people = think state works to do that, but it enables the attack not stops it. > =20 > State contains where the client sends the request. The client = assumes any response following that is from the AS it sent the request = to. =20 > Most of the attacks documented take advantage of this by misdirecting = the request to a different AS than the one the client =E2=80=9Cthinks=E2=80= =9D it is making the request to. =20 > =20 > This is done in two ways. One is by pointing at another AS=E2=80=99s = authorization endpoint as part of registration, and the other is by = redirecting and rewriting the authorization request. > =20 > The client thinking it has a response from a AS based on state then = uses the associated token and RS endpoints. Those endpoints are wrong = for the AS that really returned the response. Thus the client becomes = a proxy for relaying responses from the target AS. > =20 > Both mitigations attempt to mitigate this by having the AS return = something that can be compared with state to determine if the request = has been misdirected. > =20 > In one case we return a logical identifier (Name) for the AS that is = compared to a name provided as part of client setup. This name can = optionally be used as the input to discovery to verify other meta-data = about the AS. > =20 > In the second mitigation the URI of the token endpoint or resource = server is returned. > =20 > They both provide a way for the client to determine if the stored = state is invalid because the response is coming from a different place = than the request went to. > =20 > It was noted by the researchers that the OIDC flow =E2=80=9Ccode = id_token=E2=80=9D was not susceptible to this attack because the client = validates the issuer of the id_token and the client_id that the AS = thinks it is responding to (some of the attacks rewrite the client_id in = the request). > =20 > For reference = http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation = points 2 & 3 of the OIDC validation. > =20 > Knowing that works based on researcher feedback, the first option = allows the two id_token claims to be returned from the Authorization = endpoint without forcing OAuth clients to support signed JWT. It also = allows AS to provide a issuer URI but allows clients to compare the = strings without forcing them to do discovery. Clients that do = discovery can use this value to bootstrap/validate that. This takes = advantage of validation that some clients already perform and applies it = to the code response. > =20 > The second option from Nat allows the client to compare the = token_endpoint URI from configuration to the one in the response. A = difference would indicate that the AS is different, in a similar way to = the other option. =20 > =20 > The difference is that the second option doesn=E2=80=99t include the = client_id and while I don=E2=80=99t have an attack against that off the = top of my head, it was felt that it is a open attack surface and should = be closed. =20 > =20 > The other difference is I think more subtle and changes OAuth in the = second option (Nat probably argues that would be a good thing). > OAuth to this point assumes that the client is in charge, that the = developer configures the endpoints etc via service documentation. > In the authorization request or the AT request the AS has no = information about what RS is being used as part of the protocol. > =20 > The second option changes that by providing link relationships where = each step provides meta data about where to use the result. > The Authorization endpoint points to the token endpoint, the token = endpoint points to the resource server and the resource server points to = the Authorization endpoint. To get that to work for a number of uses = cases you probably need to tell the authorization endpoint and possibly = the token endpoint what resource or resources you want the scopes for. = A given AS might have more than one token endpoint (not common but not = precluded, but something that might happen in multi tenant or other = special cases), and if it is using JWT access tokens it may not even = know about the given RS. > =20 > So to be able to give the meta-data for the next hop the endpoint = responding may need more information. > =20 > The two mitigations are not incompatible, we could do both. > =20 > I do however think that the second one may have architectural side = effects that we need to more fully discuss. =20 > Adding link relation/follow your nose processing to OAuth may be a = good thing, but may have impacts that we have not fully thought through = yet. > =20 >> =20 >> =20 >> For the issue of dynamic discovery and the potential to insert a = malicious discovery document: can the recommendation be to use the = hybrid flow of Connect if you do discovery (and validate the issuer = before exchanging the code)? Do we need to invent something new for = this use-case? > =20 > As above this would work , but we don;t want to force all OAuth = clients to have to deal with JWT. This would be a fix for Connect if = we were only concerned about that. >=20 >=20 >> =20 >> Regarding sections 5 & 6 ("Mitigation Data Sent to the Token = Endpoint"), this describes something that seems similar to what is = achieved by PKCE (RFC7636). Binding information to the authorization = code that must be presented to redeem the code is precisely what PKCE = does, and PKCE has additional security properties. With the PKCE S256 = challenge method, the authorization request and response can leak in = their entirety, and yet still the attacker couldn't exchange the = authorization code. Let's just recommend RFC7636 for this mitigation. >> =20 > Unfortunately PKCE makes the assumption that attacker cannot modify = the request. In this case the attacker can modify the request.=20 > =20 > PKCE provides protection in cases where the attacker can=E2=80=99t = modify the PKCE challenge in the request.=20 > If the attacker can modify the request then they make a new request in = a second browser to get the PKCE challenge and replace the one in the = request being modified by that one. > =20 > I need to think about it a bit more but there might be a way to do it = by defining a new PKCE method.=20 > =20 > If the code_challenge were a HASH of state || code_verifyer, that = would do both. =20 > =20 > The server would need to store state and code_challange. The client = would just calculate the hash over both, but still send the same = code_verifier. > ( optimization would be for the code_challange =3D=3D S256 = (S256(state) || code_verifier) that way the AS only needs to store the = hash of state) > =20 > The attacker can=E2=80=99t change the state in the first request, or = the client will reject the response, and because the code_verifyer will = be different between the requests the AS would reject the second one = because the code_challange will be wrong. > =20 > That is more complicated for the client, but would allow you to do it = with PKCE with no more crypto than PKCE S256 (the MTI) already requires. > =20 > For Asymmetric PKCE the code_challange would be a JWK of the public = key and the code_verifier would be a JWS (S256(state) ) > (You might want to include code in the JWT but I need to think that = through) > =20 > So yes unless someone finds a flaw in that logic we may be able to = define some PKCE modes to mitigate against cut and paste. > I didn=E2=80=99t think of defining a new PKCE mode at the time. You = should have been at the meeting:) > =20 >=20 >=20 >> The security researcher documents are only informative references, = and yet the spec seems to rely on them normatively. E.g.: >> * "Mitigating the attacks also relies on the client sending = additional data about the interaction to the token endpoint" (how does = this mitigate the attacks? and what attack exactly?). >> * "a client may be confused simply because it is receiving = authorization responses from more than one authorization server" (why = is the client confused?) >> I would like to see the attacks normatively described in the spec. >> =20 >> For my own knowledge: what are some of the use-cases that are subject = to these attacks? I'm not convinced every RP that talks to more than 1 = AS is at risk today. What are some risky situations that exist which are = mitigated by this draft? > =20 > Any RP is at risk if one of the AS it talks to is compromised, it can = compromise all of the AS that the client talks to. That is just not a = good design. > =20 > Hans did a proof of concept that only required access to the logs of = one AS to compromise all AS. > =20 > John B. >> =20 >> =20 >> =20 >> On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) = wrote: >>> Option A >>>=20 >>> Phil >>>=20 >>> > On Feb 19, 2016, at 13:39, Hans Zandbelt = wrote: >>> > >>> > Option A: I agree with Mike that the complexity and implementation = cost of Option B will make adoption harder, which was also a concern = with the first iteration of Option A. >>> > >>> > To be honest, I'm not sure most people would even understand why = the complexity would be required and just forget about it. At least with = the simplicity of the most recent option A they don't have to care, just = add some simple parameters/checks. >>> > >>> > And for the record: I've also implemented option A in the = mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and = NGINX respectively. >>> > >>> > Hans. >>> > >>> > [1] https://github.com/pingidentity/mod_auth_openidc >>> > [2] https://github.com/pingidentity/lua-resty-openidc >>> > >>> >> On 2/19/16 9:18 PM, Mike Jones wrote: >>> >> Option A. I have higher confidence that this specification = solves the >>> >> problems because it was designed during a 4-day security meeting >>> >> dedicated to this task by a group of over 20 OAuth security = experts, >>> >> *including both sets of researchers in Germany who originally = identified >>> >> the problem*. This solution has also been implemented and = interop >>> >> tested by Roland Hedberg, Brian Campbell, and I believe others. = Note >>> >> that the reason I am advocating this specification is **not** = because >>> >> I'm an editor of it; my role was to record in spec language what = the >>> >> OAuth security experts designed together over the 4-day period in = Darmstadt. >>> >> >>> >> I=E2=80=99ll also note that even if Option B also solves the = problem, it comes >>> >> at significant adoption costs and complexity not found in A. In >>> >> particular, it requires that developers understand support a new = =E2=80=9CLink >>> >> Relation=E2=80=9D syntax not used elsewhere in OAuth. As Nat = writes about his >>> >> own draft in >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html = - there >>> >> is not a standard JSON syntax for link relations. He writes = =E2=80=9Cwe could >>> >> easily create a parallel to it=E2=80=9D. I=E2=80=99d rather we = solve the problem using >>> >> standard mechanisms already employed in OAuth, rather than risk >>> >> bifurcating OAuth in the developer community by unnecessarily >>> >> inventing/creating new syntax that is unfamiliar to developers = and that >>> >> many of them may reject using. >>> >> >>> >> -- Mike >>> >> >>> >> P.S. Information about the OAuth security meeting can be found = at >>> >> = https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXz= GptU4/edit >>> >> and >>> >> = https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakV= bA_sk/edit >>> >> . >>> >> >>> >> -----Original Message----- >>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig >>> >> Sent: Friday, February 19, 2016 11:43 AM >>> >> To: oauth@ietf.org >>> >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call = for >>> >> Adoption >>> >> >>> >> Early February I posted a mail to the list to make progress on = the >>> >> solution to the OAuth Authorization Server Mix-Up problem = discovered >>> >> late last year. >>> >> >>> >> Here is my mail about the Authorization Server Mix-Up: >>> >> >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >>> >> >>> >> Here is my mail to the list that tries to summarize the = discussion >>> >> status and asked a few questions: >>> >> >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >>> >> >>> >> Unfortunately, my mail didn't lead to the intended success. While = there >>> >> was some feedback I wasn't getting the desired response. >>> >> >>> >> In order to move forward I believe we need a working group = document that >>> >> serves as a starting point for further work in the group*. We = have two >>> >> documents that provide similar functionality in an attempt to = solve the >>> >> Authorization Server Mix-Up problem. >>> >> >>> >> So, here is the question for the group. Which document do you = want as a >>> >> starting point for work on this topic: >>> >> >>> >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John = Bradley >>> >> >>> >> Link: >>> >> >>> >> = https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >>> >> >>> >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov = Matake and >>> >> Sascha Preibisch >>> >> >>> >> Link: >>> >> >>> >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >>> >> >>> >> Deadline for feedback is March, 4th. >>> >> >>> >> Ciao >>> >> >>> >> Hannes & Derek >>> >> >>> >> PS: (*) Regardless of the selected solution we will provide = proper >>> >> acknowledgement for those who contributed to the work. >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > -- >>> > Hans Zandbelt | Sr. Technical Architect >>> > hzandbelt@pingidentity.com | Ping Identity >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_B50948B7-C090-44B0-A72E-AC3284EBAFCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline

On Feb 22, 2016, at 9:22 AM, = Nat Sakimura <n-sakimura@nri.co.jp> wrote:

[case1] Code phishing + cut-n-paste attack 
  [case1a] through BadAS = to GoodAS redirect
  [case1b] through tampering = the unprotected client access response
  [case1c] through the server log
[case2] Token phishing (in case of implicit = flow). 
[case3] Code and Client credential phishing
 
All of these = seem to involve the tampering of the unprotected communication. 
If we can secure all the communication, the = problem would be solved for all the variants and for those that we still = do not know. One way of doing it is to use OAuth JAR and authorization = response that includes ID Token, but that=E2=80=99s not possible in many = cases as I understand. 
We have to accommodate a measure that is = proportionate to the risks. 
 
The risk impact = of [case1] is that the code is stolen, and it is used against the client = to =E2=80=9Clogin=E2=80=9D to the client. The attacker will not have an = access to the access token. Is that right? If that is the case, is this = a case that we are really concerned of? Is it not out of scope for = OAuth? If so, we can punt this case to something like a login protocol = such as OpenID Connect. It also has the notion of =E2=80=9Cissuer=E2=80=9D= baked in, so there will be less conflict to use the mix-up draft. 

In this case with OAuth the = information protected by the AT can still be stolen.  While the = attacker doesn=E2=80=99t get the AT directly it gets control of a client = that has the AT.   If I link my Flikr account to your private Flikr = feed, you as the Resource owner is still compromised.   Arguing = that OAuth didn=E2=80=99t leak the token is not a good argument.   = OAuth needs to protect against this.

 
The risk impact = of [case2] is more OAuth specific. The token is stolen as the token is = going to be sent to a rogue resource, and the resource can use that to = obtain the resource that was supposed to be only available to the proper = client. 
 
The risk impact = of [case3] is the most grave among these three. Now the attacker can = create his own client that impersonates the compromised client. 
 
OAuth-mix-up
---------------------------
OAuth-mix-up draft gives one way of addressing = [case2] by introducing a new concept of =E2=80=9Cissuer=E2=80=9D and = =E2=80=9Cdiscovery=E2=80=9D to RFC6749. It also returns client_id and = verifies it in 4.2, but if the BadAS has assigned a same client_id to = the client, it does not help. 

Client_id are not guaranteed to be = unique.  They need to be name spaced by the AS.   In OAuth = currently we have no name for the AS this makes that difficult, the = client can use the authorization endpoint URI, but that logic may well = break in multi tenant situations.   Having a clear issuer string = makes it easier for the client.  
 
By comparing the = issuer stored in the session (the draft should be explicit about it) = with the issuer in the response, the client can find out that the party = he is getting the response from is not the one he sent a request to, = that communication was compromised/tampered with, provided that the = response is not tampered by the attacker in-browser. 

Yes
 
Note that the = response may still be tampered (e.g., by MITB) so that the issuer can be = re-written, in which case the mitigation does not work, but IMHO, we do = not have to worry about it here, as with MITB, you can do worse things = easier. 

Yes
 
One of the issue = with this approach is that the central notion of =E2=80=9Cissuer=E2=80=9D = is new to the existing servers and clients. The verification rule in 4.1 = states =E2=80=9CCompare the issuer URL for the authorization server that = the client received when it registered at the authorization server=E2=80=9D= , but in most existing pure OAuth cases, there is no such thing, so you = cannot compare. This means that you would have to re-register, and if = you are doing that, the per-AS redirect_uri seems to be a much simpler = solution. 

The client developers I have talked = to really hate per AS redirect URI as being too awkward for deployments. =  

The client would not need to = re register to add a issuer URI to its client_id record.   That is = one of the ways to do it.
 
Also note that = this is not a general framework for finding out tainted communication, = so it may have other holes. 
 
OAuth-meta
-------------------
OAuth-meta is not designed as a specific fix to = the problem. Rather, it was designed as a general framework of providing = the meta-data to the responses by leveraging RFC5988 registry. It just = happens to mitigate this particular case. 
 
Again, it is not = a general framework for finding out tainted communication, so it may = have other holes. 

Without sending the resource in the = request, the Authorization endpoint, and token endpoints are not = necessarily going to be able to return the correct next = hop.

My biggest concern is that this = potentially moves some of the client logic into the AS.   I don=E2=80= =99t know that that is a bad thing but it feels to me like a real change = to OAuth as it currently is.   I think we need to really think = about this change, and how it will impact OAuth overall. =  

I see this as potentially = complimentary OAuth mix up returning a logical name for the = AS.

 
Per AS Redirect URI
--------------------------------
This does not involve wire protocol changes. It = just adds requirements on the redirect uri. This by far is the simplest = solution for [case2] (and [case1]), IMHO. 
 
Again, it is not = a general framework for finding out tainted communication, so it may = have other holes.

This is probably the hardest for the client developer = and for the deployer.  Yes it is simplest from a spec point of = view. 
We need more developer feedback on = this.

 
(Extended) PKCE
---------------------------------
To begin with, it works only with code flow. There = has to be something else to deal with implicit flow. 
 
PKCE binds the = authorization request/response to the token request. 
If used with a confidential client, it seems to = mitigate the vulnerability. 
John points out that it is not the case. I must be = missing something here=E2=80=A6 but my logic goes like: 
 
 
1.     The good client creates = code_challenge-v and code_verifier-v=3DS256(code_challenge-v) and sends = the client_id-v + code_challenge-v + state to the BadAS Authz EP. 
2.     BadAS as a client prepares a = code_verifier-b and code_challenge-b=3DS256(code_verifer-b). 
3.     BadAS redirects to GoodAS with the = client_id-v + code_challenge-b + state-v.  
4.     GoodAS stores the = code_challenge-b. 
5.     GoodAS returns code-v + state-v to = the client=E2=80=99s redirect uri. 
6.     The client finds the AS from the = state and sends code-v + code_verifier-v + secret-b to the BadAS token = endpoint. Now, code-v and code_verifer-v is phished. 
 
Now the attacker = tries to use the code-v and code_verifier-v. 
 
### Case = A:
7.     The BadAS as a client sends = client_id-v + =E2=80=A6 but he does not have client secret for the good = client, so it fails. 
 
### Case B: 
8.     The BadAS as a client sends = client_id-b + code-v + code_verifier-b + secret-b etc. to GoodAS. 
9.     GoodAS verifies the code_verifier-b = is associated with code-v, but that code-v is not associated with = client_id-b, so the token request fails. 
 
### Case C: = cut-n-paste
10.  The attacker launches cut-n-paste = attack by replacing the code-b with code-v. 
11.  The verifiers does not match, so = fails. 
 
Please let me = know what I am missing. 

In a step 0 the attacker has the good = client create another request in the attackers user agent to get state-0 = and code_challange-0

Step 2 is not = required.
Step 3 Bad AS redirects to good AS with client_id_v = + state-v + code_challenge-0
Step 4 GoodAS stores = code_challenge-0
Step 5 GoodAS returns code-v + state-v to the = clients redirect_uri
Step 6 The client finds the AS from the state and sends = code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, = code-v and code_verifer-v is phished. 

Case C1 :  cut and paste
10.  The attacker launches cut-n-paste attack by inserting code-v = into a response using state-0
11. The client = sends code-v and based on state-0 it sends code_verifyer-0 to the good = AS token endpoint.
12. The GoodAS = verifies that code-verifyer-0 is correct for code_challange-0 that it = bound to code in step 4
13. The GoodAS = receives RT + AT.
14. The = attacker has now used the client to bind the users resource to it=E2=80=99= s account and is transferring money or looking at your = data.

This could be = 3rd party financial app like Mint as an example or photos or any other = PII that could then be used to escalate identity theft.

This variation = of the attack combining cut and paste with confused client was not = mentioned in the research papers.

I found it = looking to see if PKCE could be used to mitigate the confused client = attack.

As I mentioned in a response to = William, while the current PKCE Challenge methods only make the attack = harder by forcing the attacker to get the client to make a step 0 = request to get a code_challenge to use in the request,  we could = define a new challenge method that would be effective.

That would remove the need to have a separate mechanism to = prevent cut and paste.

The problem is that the PKCE = challenge is independent of state so becomes vulnerable to the confused = client.

What we would need to do is include state in the challenge so = that if the AS receives mismatched state and code_challange in step 3 = the verification of code verifier will fail. Effectively combining = the cut and paste mitigation with PKCE.

I haven=E2=80=99t had = time to write this up, but if the code_challenge =3D=3D SHA256 = (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || = client_id || code-veriyer) ,  then the attacker could not = change state, client_id, or token_endpoint  independently of = code_challenge.  (note I am using a hash of state to = make storage size deterministic for the AS on the grounds that the = client already needs to be able to do the hash) (Some attacks =  change the client_id in the request so I am including it in = the hash)

This is slightly more complicated = than than S256, but not that much.  I wish I had thought of this = when we were doing PKCE.   Hit me with the stupid stick, my = fault.

I don=E2=80=99t know if it stops all the confused client = attacks though.

If the client is confidential then it = gives up it=E2=80=99s client secret assuming compromised registration, = so we can=E2=80=99t really count on that for symmetric = client authentication.

By including the token endpoint in = the comparison if the client is sending the code to the attacker the = client will use a different token endpoint_uri in to calculate the = code_challenge than the GoodAS will use to verify it.    This = would stop both cut and paste as well as stopping the attacker from = using the code if they get it.   The attacker can=E2=80=99t get = Secret for state-0, so it can=E2=80=99t create code_challenge that would = be valid.

This stops the registration attack = where the client gets a bad AS discovery endpoint that has all the Good = AS info including dynamic registration endpoint but the bad AS = token endpoint.   The bad AS would get the token, client_secret and = code_verier, but will fail pkce verification because the token = endpoint will be wrong.

The attack where the client registers = with the good AS but with bad token endpoint and Authorization endpoint = gives the attacker the ability to change the code_challenge that = the Good AS is going to see.   It would need to make a new = challenge using state and the GoodAS token endpoint and it=E2=80=99s = client_id.   
To do that it needs the = code_verifier to use to calculate the hash to use as the code_challenge = value.  As long as the client is not tricked into accepting a = replay of the authentication response we should be safe.  The = client would need to do replay protection on the code_verifier values = before it makes a request to the token endpoint.  

The BadAS could however make up a new = code_challenge and code_verifier and use that in the request. For = this one the AS would need to do pull discovery on the client to get a = key, or the AS needs to return something in the response.  This = attack can completely proxy all the endpoints as far as the client is = concerned and is taking advantage of the AS saying you are granting = permission to site X based on the redirect URI.  

I can=E2=80=99t see PKCE on it=E2=80=99s own being able = to stop a client from being used as a redirector back to the attacker = unless you also returned the code_challenge in the response from the = authorization endpoint.

Hypothetically if we returned = code_challenge in the response from the authorization endpoint and have = a new PKCE challenge method we might find it covers all of the = attacks.

We would need to put some serious analysis = into this to see if it really covers all the attacks. 

It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80= =9D response_type or steeling the access token by impersonating the = RS. 

I think the correct way to stop the = problem with access tokens is by audience restricting them. =  
To = do that the client needs to provide an audience in it=E2=80=99s request = and the AS needs to include that in the AT.

I included the Authorization_endpoint URI in the hash to = detect if the auth request may have been tampered with to change the = audience for the AT.

For implicit we could have a version of = PKCE where the AS returns a parameter with S256( client_id || = authorization_endpoint URI || resource endpoint URI) to verify the = request was not tampered with, and that would allow the AT to be = properly audience restricted. 


This would be a completely new approach not involving = discovery, logical names for AS, or link relations.

Effectively this code_challenge method becomes a = signature over parts of the request and the implicit audience of = the token_endpoint URI.  

People keep asking = why PKCE doesn=E2=80=99t stop these attacks, and it won=E2=80=99t with = the current PKCE methods,  however a new method along the lines I = sketched out may let it work, or I could be completely wrong.

Too bad I don=E2=80=99t think I will make RSA to go over = this in person.


John B.



 
Nat
 
 
 
 
 
 
--
PLEASE READ :This = e-mail is confidential and intended for the
named = recipient only. If you are not an intended recipient,
please= notify the sender  and delete this e-mail.
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of John Bradley
Sent: Saturday, February 20, = 2016 9:16 PM
To: William Denniss
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] = Fixing the Authorization Server Mix-Up: Call for Adoption
 
Inline
On= Feb 20, 2016, at 9:49 AM, William Denniss <wdenniss@google.com>= wrote:
 
Maybe it's because I wasn't = at the Darmstadt meeting so I don't have the full context, but I don't = find draft A to be all that clear. Here's my review = feedback:
 
Regarding the text "a = client may be confused simply because it is receiving authorization = responses from more than one authorization server at the same = redirection endpoint". Even if the client re-uses the same redirection = endpoint, shouldn't state solve this? All incoming responses should = have an outgoing request with a matching state that would identify = the authorization request and therefore authorization server.
 
If only that were the case. =   That is the nub of the problem people think state works to do = that, but it enables the attack not stops it.
 State contains where the client sends the request.   = The client assumes any response following that is from the AS it = sent the request to.  
Most of the attacks = documented take advantage of this by misdirecting the request to a = different AS than the one the client =E2=80=9Cthinks=E2=80=9D it is = making the request to.  
 
This is = done in two ways. One is by pointing at another AS=E2=80=99s = authorization endpoint as part of registration, and the other is by = redirecting and rewriting the authorization request.
 
The client thinking it has a response = from a AS based on state then uses the associated token and RS = endpoints.   Those endpoints are wrong for the AS that really = returned the response.   Thus the client becomes a proxy for = relaying responses from the target AS.
 
Both mitigations attempt to mitigate this by having the AS = return something that can be compared with state to determine = if the request has been misdirected.
 
In one case we return a logical identifier (Name) for the AS = that is compared to a name provided as part of client setup. =  This name can optionally be used as the input to discovery to = verify other meta-data about the AS.
 
In= the second mitigation the URI of the token endpoint or resource server = is returned.
 
They both provide a way = for the client to determine if the stored state is invalid because the = response is coming from a different place than the request went = to.
 
It was noted by the researchers = that the OIDC flow =E2=80=9Ccode id_token=E2=80=9D was not susceptible = to this attack because the client validates the issuer of the = id_token and the client_id that the AS thinks it is responding to (some = of the attacks rewrite the client_id in the request).
 
For reference http://openid.net/specs/openid-connect-core-1_0.html#IDTokenVal= idation points 2 & 3 of the OIDC validation.
 
Knowing that works based on researcher = feedback, the first option allows the two id_token claims to be returned = from the Authorization endpoint without forcing OAuth clients to = support signed JWT.   It also allows AS to provide a issuer URI = but allows clients to compare the strings without forcing them to = do discovery.   Clients that do discovery can use this value = to bootstrap/validate that.   This takes advantage of = validation that some clients already perform and applies it to the = code response.
 
The second option = from Nat allows the client to compare the token_endpoint URI from = configuration to the one in the response.  A difference would = indicate that the AS is different, in a similar way to the other option. =  
 
The difference is that the = second option doesn=E2=80=99t include the client_id and while I don=E2=80=99= t have an attack against that off the top of my head, it was felt = that it is a open attack surface and should be closed.  
 
The other difference is I think more = subtle and changes OAuth in the second option (Nat probably argues that = would be a good thing).
OAuth to this point assumes = that the client is in charge, that the developer configures the = endpoints etc via service documentation.
In the = authorization request or the AT request the AS has no information about = what RS is being used as part of the protocol.
 
The second option changes that by = providing link relationships where each step provides meta data about = where to use the result.
The Authorization endpoint = points to the token endpoint, the token endpoint points to the resource = server and the resource server points to the Authorization = endpoint.   To get that to work for a number of uses cases you = probably need to tell the authorization endpoint and possibly the = token endpoint what resource or resources you want the scopes for. =    A given AS might have more than one token endpoint = (not common but not precluded,  but something that might happen in = multi tenant or other special cases), and if it is using JWT access = tokens it may not even know about the given RS.
 
So to be able to give the meta-data for the next hop the = endpoint responding may need more information.
 
The two mitigations are not incompatible, we could do = both.
 
I do however think that the = second one may have architectural side effects that we need to more = fully discuss.  
Adding link relation/follow your = nose processing to OAuth may be a good thing, but may have impacts that = we have not fully thought through yet.
 
 
 
For = the issue of dynamic discovery and the potential to insert a malicious = discovery document: can the recommendation be to use the hybrid = flow of Connect if you do discovery (and validate the issuer before = exchanging the code)?  Do we need to invent something new for = this use-case?
 
As above = this would work , but we don;t want to force all OAuth clients to have = to deal with JWT.   This would be a fix for Connect if we were = only concerned about that.


 
Regarding sections 5 & = 6 ("Mitigation Data Sent to the Token Endpoint"), this describes = something that seems similar to what is achieved by PKCE (RFC7636). = Binding information to the authorization code that must be presented to = redeem the code is precisely what PKCE does, and PKCE has = additional security properties. With the PKCE S256 challenge method, = the authorization request and response can leak in their entirety, = and yet still the attacker couldn't exchange the = authorization code. Let's just recommend RFC7636 for this = mitigation.
 
Unfortunately = PKCE makes the assumption that attacker cannot modify the request. =  In this case the attacker can modify the request. 
 
PKCE provides protection in cases where = the attacker can=E2=80=99t modify the PKCE challenge in the = request. 
If the attacker can modify the request then = they make a new request in a second browser to get the PKCE challenge = and replace the one in the request being modified by that one.
 
I need to think about it a bit more but = there might be a way to do it by defining a new PKCE method. 
 
If the code_challenge  were a HASH = of state || code_verifyer, that would do both.   
 
The server would need to store state and = code_challange.  The client would just calculate the hash over = both, but still send the same code_verifier.
( = optimization would be for the code_challange =3D=3D S256 (S256(state) || = code_verifier)  that way the AS only needs to store the hash = of state)
 
The attacker can=E2=80=99t = change the state in the first request, or the client will reject the = response, and because the code_verifyer will be different between = the requests the AS would reject the second one because the = code_challange will be wrong.
 
That is = more complicated for the client, but would allow you to do it with PKCE = with no more crypto than PKCE S256 (the MTI) already requires.
 
For Asymmetric PKCE the code_challange = would be a JWK of the public key and the code_verifier would be a = JWS (S256(state) )
(You might want to include code in = the JWT but I need to think that through)
 
So yes unless someone finds a flaw in that logic we may be = able to define some PKCE modes to mitigate against cut = and paste.
I didn=E2=80=99t think of defining a new = PKCE mode at the time.  You should have been at the meeting:)
 


The security researcher documents are only informative = references, and yet the spec seems to rely on them = normatively. E.g.:
*  "Mitigating the attacks = also relies on the client sending additional data about the interaction = to the token endpoint" (how does this mitigate the attacks? and = what attack exactly?).
*  "a client may be confused = simply because it is receiving authorization responses from more than = one authorization server"  (why is the client confused?)
I would like to see the attacks normatively described in the = spec.
 
For my own knowledge: what are = some of the use-cases that are subject to these attacks? I'm not = convinced every RP that talks to more than 1 AS is at risk today. = What are some risky situations that exist which are mitigated by this = draft?
 
Any RP is at risk = if one of the AS it talks to is compromised, it can compromise all of = the AS that the client talks to.  That is just not a good = design.
 
Hans did a proof of concept = that only required access to the logs of one AS to compromise all AS.
 
John B.
 
 
 
On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Option = A

Phil

> On = Feb 19, 2016, at 13:39, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:
>> Option A: I agree with Mike that the complexity and = implementation cost of Option B will make adoption harder, = which was also a concern with the first iteration of Option A.
>
> To be honest, I'm not sure most = people would even understand why the complexity would be required and = just forget about it. At least with the simplicity of the most = recent option A they don't have to care, just add some = simple parameters/checks.
>
> And = for the record: I've also implemented option A in the mod_auth_openidc = [1] and lua-resty-openidc [2] clients for Apache and NGINX = respectively.
>
> Hans.
>
> [1] https://github.com/pingidentity/mod_auth_openidc
> [2] https://github.com/pingidentity/lua-resty-openidc
>
>> On 2/19/16 9:18 PM, Mike Jones = wrote:
>> Option A.  I have higher confidence = that this specification solves the
>> problems = because it was designed during a 4-day security meeting
>> dedicated to this task by a group of over 20 OAuth = security experts,
>> *including both sets of = researchers in Germany who originally identified
>> = the problem*.  This solution has also been implemented and = interop
>> tested by Roland Hedberg, Brian Campbell, = and I believe others.  Note
>> that the reason = I am advocating this specification is **not** because
>> I'm an editor of it; my role was to record in spec = language what the
>> OAuth security experts designed = together over the 4-day period in Darmstadt.
>>
>> I=E2=80=99ll also note that even if Option B also = solves the problem, it comes
>> at significant = adoption costs and complexity not found in A.  In
>> particular, it requires that developers understand = support a new =E2=80=9CLink
>> Relation=E2=80=9D = syntax not used elsewhere in OAuth.  As Nat writes about his
>> own draft in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.htm= l - there
>> is not a standard JSON syntax = for link relations.  He writes =E2=80=9Cwe could
>> easily create a parallel to it=E2=80=9D.  I=E2=80= =99d rather we solve the problem using
>> standard = mechanisms already employed in OAuth, rather than risk
>> bifurcating OAuth in the developer community by = unnecessarily
>> inventing/creating new syntax that = is unfamiliar to developers and that
>> many of them = may reject using.
>>
>>   =                     =                     =                 -- Mike
>>
>> P.S.  Information about = the OAuth security meeting can be found at
>> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHA= lJ6kM5OyeXzGptU4/edit
>> and
>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_= EoSpO5NtakVbA_sk/edit
>> .
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
>> Sent: Friday, February 19, 2016 11:43 = AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] = Fixing the Authorization Server Mix-Up: Call for
>> = Adoption
>>
>> Early February I = posted a mail to the list to make progress on the
>> = solution to the OAuth Authorization Server Mix-Up problem discovered
>> late last year.
>>
>> Here is my mail about the Authorization Server = Mix-Up:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm= l
>>
>> Here is my mail to = the list that tries to summarize the discussion
>> = status and asked a few questions:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.htm= l
>>
>> Unfortunately, my = mail didn't lead to the intended success. While there
>> was some feedback I wasn't getting the desired = response.
>>
>> In order to move = forward I believe we need a working group document that
>> serves as a starting point for further work in the = group*. We have two
>> documents that provide = similar functionality in an attempt to solve the
>> = Authorization Server Mix-Up problem.
>>
>> So, here is the question for the group. Which = document do you want as a
>> starting point for work = on this topic:
>>
>> -- Option = A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley
>>
>> Link:
>>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation= -01
>>
>> -- Option B: = 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
>> Sascha Preibisch
>>
>> Link:
>>
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07>>
>> Deadline for feedback is = March, 4th.
>>
>> Ciao
>>
>> Hannes & Derek
>>
>> PS: (*) Regardless of the = selected solution we will provide proper
>> = acknowledgement for those who contributed to the work.
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> --
> Hans Zandbelt =              | Sr. Technical = Architect
> hzandbelt@pingidentity.com | Ping Identity
>
> = _______________________________________________
> OAuth = mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

= --Apple-Mail=_B50948B7-C090-44B0-A72E-AC3284EBAFCC-- --Apple-Mail=_BD93B3C4-7E00-49D5-B884-246CD4110786 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMjIxMjA4MzZaMCMGCSqGSIb3DQEJBDEWBBQokslvIRnlCAwhEifE5nbc UvV52jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBLAZHMakgCdo1Nqo6qJTdjb8Ly9rTskwXw8+a+P1x7pxBq2kWKLcfd ynBMyvY1yLP5mu7FRG1RoGOoLkc10SqoiX7A1DcTU4xElNbMTg8E8kflCERrEP5ibF1p0rJaETot fK72TdJWwZwNYkIc/l7iFwpY6FFX82lINL1yOqsNW5LGEyHMqGdPnUCmR/MN+ldZOEa46FyzehnK b8MoHMqXUElRN5oecZotGx9fkmIuqZ5mExW8utvyTXl60kacH70zDOc3clPtd5I6bh9gLygvfKXs FY2nCF29qRmpQUeq0NV39Efa8B7YrONqZNSOHqXgT4+JWO+4Z9iucuOnjMj5AAAAAAAA --Apple-Mail=_BD93B3C4-7E00-49D5-B884-246CD4110786-- From nobody Mon Feb 22 21:56:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D410B1A1ADF for ; Mon, 22 Feb 2016 21:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 LIiokhV9J6E5 for ; Mon, 22 Feb 2016 21:56:35 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 130681ACD8A for ; Mon, 22 Feb 2016 21:56:35 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id gc3so185461248obb.3 for ; Mon, 22 Feb 2016 21:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p7R70CQ7iVDSm65mBW+MJnVscDHzFntJev8hIwb+e+8=; b=Ejt5yOdpXllzcVwL8nC+d5ozfkfwS4RQg3O/bkPK/uZ993TDKBFIwSbEhg/Rvv0aQL T9nKGh3iio6PWMzhizA7s97az1on31euwgZwntAJX4KJn8JejD4I5HmqQj+q41e2/uUR ti/ciLShGdFBgfCi20lw9r+Y1lvzWp5aL+6XYG+xUNjwkb9nlMKRHzcUkvUywkYsdcE2 MBfjZBpEpPmveUb8lVHoVtNGYc880QPMqzwpdtNihuiJ/aTPsHDjELvW7emN6CgPTsK5 OYfd8/uFMHNcZR/jHLGcwle0Hz6VcOZse4PVfz74gvORupfNv4HxQrTM/yesnAaIo0Z5 nYOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p7R70CQ7iVDSm65mBW+MJnVscDHzFntJev8hIwb+e+8=; b=LW8b2QcKggVCUvoEDovT1V1a/fwci78cXAvVSotu00wKXUgIfEgpS9ra3sRx1++pry Y9a8qXc1HB6SYq+DJeUO0YllnJ4V/E4VeYpCDRGLmkyP5jULsf+TB+ePRB8m9wFMC8Fc iSVLDGISYotZkOxZKn4jZeidiTsF0XbtbVlWvZzS6qmSlT7CGK9hPmeKGgK9eq03lVuo tM2mvkmuwRlUwwLPHy5hezjfOByYbA+szvhXGR6UR3iSmoksKhu5FK/IOiEfGElY7vK+ B/uX7Zax5HONb8DGS93dDNC7njESwx+l/2RZPEcdRzow4UyhMpTzV4H9tf+x4gz72rk/ URmg== X-Gm-Message-State: AG10YOTtX8p7tb0PgsvNmhX+wSXPGADLqeGOypf5QayNYxpAbT4bw3LUhEHPlbFk0fWRpipzRq3fMH2DBkWhQm5H X-Received: by 10.182.247.67 with SMTP id yc3mr19977536obc.57.1456206994226; Mon, 22 Feb 2016 21:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.79.233 with HTTP; Mon, 22 Feb 2016 21:56:14 -0800 (PST) In-Reply-To: <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> From: William Denniss Date: Mon, 22 Feb 2016 21:56:14 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e0158b2549c9d8d052c699cb8 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 05:56:46 -0000 --089e0158b2549c9d8d052c699cb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the very detailed answers John. I like the idea of adding a new challenge method to PKCE. This is the sort of thing PKCE was designed for, so reusing that and adding a bit of logic to the code generation/verification methods, as opposed to more extensions to the OAuth protocol seems wise. Pity we didn't think of it at the time, and yes I wish I could have attended the Darmstadt meeting. IETF95 should be a good chance to hash out some of these things though (no pun intended)! I agree with the assumption that from a client ease of implementation perspective, they may wish to re-use the redirection endpoint. It's not the best approach, but I fear it may be hard forcing people to change. Regarding "Without sending the resource in the request, the Authorization endpoint, and token endpoints are not necessarily going to be able to return the correct next hop." I'm inclined to agree, but I'll note that the metadata spec can be used without the resource server bits: I do think that the AS should know the token endpoint and be able to return that (it's equiv to issuer -> discovery anyway), and I've always felt that this was a pretty elegant idea (mix up mitigation or not). I also think that perhaps the two drafts can remain separate as they are not directly trying to solve the same problem. I strongly believe that the mix-up spec needs to normatively state the attacks that are being mitigated. I've read the research papers (which I agree should remain "informative"), yet this spec doesn't mitigate all the issues (or does it?). It's really hard as a reviewer to verify that the "Mix Up Mitigation" draft actually mitigates what it claims to, when it doesn't clearly state what the issue is in normative terms. I also wonder if the spec could be re-titled and focus on use-case that it solves (supporting multiple ASes without using Connect), rather than the attack it mitigates. I like that the metadata draft is targeted to solve a particular use-case, while mitigating some attacks the process. On Mon, Feb 22, 2016 at 4:08 AM, John Bradley wrote: > Inline > > On Feb 22, 2016, at 9:22 AM, Nat Sakimura wrote: > > [case1] Code phishing + cut-n-paste attack > [case1a] through BadAS to GoodAS redirect > [case1b] through tampering the unprotected client access response > [case1c] through the server log > [case2] Token phishing (in case of implicit flow). > [case3] Code and Client credential phishing > > All of these seem to involve the tampering of the unprotected > communication. > If we can secure all the communication, the problem would be solved for > all the variants and for those that we still do not know. One way of doin= g > it is to use OAuth JAR and authorization response that includes ID Token, > but that=E2=80=99s not possible in many cases as I understand. > We have to accommodate a measure that is proportionate to the risks. > > The risk impact of [case1] is that the code is stolen, and it is used > against the client to =E2=80=9Clogin=E2=80=9D to the client. The attacker= will not have an > access to the access token. Is that right? If that is the case, is this a > case that we are really concerned of? Is it not out of scope for OAuth? I= f > so, we can punt this case to something like a login protocol such as Open= ID > Connect. It also has the notion of =E2=80=9Cissuer=E2=80=9D baked in, so = there will be less > conflict to use the mix-up draft. > > > In this case with OAuth the information protected by the AT can still be > stolen. While the attacker doesn=E2=80=99t get the AT directly it gets c= ontrol of > a client that has the AT. If I link my Flikr account to your private > Flikr feed, you as the Resource owner is still compromised. Arguing tha= t > OAuth didn=E2=80=99t leak the token is not a good argument. OAuth needs= to > protect against this. > > > The risk impact of [case2] is more OAuth specific. The token is stolen as > the token is going to be sent to a rogue resource, and the resource can u= se > that to obtain the resource that was supposed to be only available to the > proper client. > > The risk impact of [case3] is the most grave among these three. Now the > attacker can create his own client that impersonates the compromised clie= nt. > > > OAuth-mix-up > --------------------------- > OAuth-mix-up draft gives one way of addressing [case2] by introducing a > new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D t= o RFC6749. It also returns > client_id and verifies it in 4.2, but if the BadAS has assigned a same > client_id to the client, it does not help. > > > Client_id are not guaranteed to be unique. They need to be name spaced b= y > the AS. In OAuth currently we have no name for the AS this makes that > difficult, the client can use the authorization endpoint URI, but that > logic may well break in multi tenant situations. Having a clear issuer > string makes it easier for the client. > > > By comparing the issuer stored in the session (the draft should be > explicit about it) with the issuer in the response, the client can find o= ut > that the party he is getting the response from is not the one he sent a > request to, that communication was compromised/tampered with, provided th= at > the response is not tampered by the attacker in-browser. > > > Yes > > > Note that the response may still be tampered (e.g., by MITB) so that the > issuer can be re-written, in which case the mitigation does not work, but > IMHO, we do not have to worry about it here, as with MITB, you can do wor= se > things easier. > > > Yes > > > One of the issue with this approach is that the central notion of =E2=80= =9Cissuer=E2=80=9D > is new to the existing servers and clients. The verification rule in 4.1 > states =E2=80=9CCompare the issuer URL for the authorization server that = the client > received when it registered at the authorization server=E2=80=9D, but in = most > existing pure OAuth cases, there is no such thing, so you cannot compare. > This means that you would have to re-register, and if you are doing that, > the per-AS redirect_uri seems to be a much simpler solution. > > > The client developers I have talked to really hate per AS redirect URI as > being too awkward for deployments. > > The client would not need to re register to add a issuer URI to its > client_id record. That is one of the ways to do it. > > > Also note that this is not a general framework for finding out tainted > communication, so it may have other holes. > > OAuth-meta > ------------------- > OAuth-meta is not designed as a specific fix to the problem. Rather, it > was designed as a general framework of providing the meta-data to the > responses by leveraging RFC5988 registry. It just happens to mitigate thi= s > particular case. > > Again, it is not a general framework for finding out tainted > communication, so it may have other holes. > > > Without sending the resource in the request, the Authorization endpoint, > and token endpoints are not necessarily going to be able to return the > correct next hop. > > My biggest concern is that this potentially moves some of the client logi= c > into the AS. I don=E2=80=99t know that that is a bad thing but it feels= to me > like a real change to OAuth as it currently is. I think we need to real= ly > think about this change, and how it will impact OAuth overall. > > I see this as potentially complimentary OAuth mix up returning a logical > name for the AS. > > > Per AS Redirect URI > -------------------------------- > This does not involve wire protocol changes. It just adds requirements on > the redirect uri. This by far is the simplest solution for [case2] (and > [case1]), IMHO. > > Again, it is not a general framework for finding out tainted > communication, so it may have other holes. > > > This is probably the hardest for the client developer and for the > deployer. Yes it is simplest from a spec point of view. > We need more developer feedback on this. > > > (Extended) PKCE > --------------------------------- > To begin with, it works only with code flow. There has to be something > else to deal with implicit flow. > > PKCE binds the authorization request/response to the token request. > If used with a confidential client, it seems to mitigate the vulnerabilit= y. > > John points out that it is not the case. I must be missing something here= =E2=80=A6 > but my logic goes like: > > > 1. The good client creates code_challenge-v and > code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + > code_challenge-v + state to the BadAS Authz EP. > 2. BadAS as a client prepares a code_verifier-b and > code_challenge-b=3DS256(code_verifer-b). > 3. BadAS redirects to GoodAS with the client_id-v + code_challenge-b > + state-v. > 4. GoodAS stores the code_challenge-b. > 5. GoodAS returns code-v + state-v to the client=E2=80=99s redirect u= ri. > 6. The client finds the AS from the state and sends code-v + > code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and > code_verifer-v is phished. > > Now the attacker tries to use the code-v and code_verifier-v. > > ### Case A: > 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he does no= t have > client secret for the good client, so it fails. > > ### Case B: > 8. The BadAS as a client sends client_id-b + code-v + code_verifier-b > + secret-b etc. to GoodAS. > 9. GoodAS verifies the code_verifier-b is associated with code-v, but > that code-v is not associated with client_id-b, so the token request fail= s. > > > ### Case C: cut-n-paste > 10. The attacker launches cut-n-paste attack by replacing the code-b > with code-v. > 11. The verifiers does not match, so fails. > > Please let me know what I am missing. > > > In a step 0 the attacker has the good client create another request in th= e > attackers user agent to get state-0 and code_challange-0 > > Step 2 is not required. > Step 3 Bad AS redirects to good AS with client_id_v + state-v + > code_challenge-0 > Step 4 GoodAS stores code_challenge-0 > Step 5 GoodAS returns code-v + state-v to the clients redirect_uri > Step 6 The client finds the AS from the state and sends code-v + > code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and > code_verifer-v is phished. > > Case C1 : cut and paste > 10. The attacker launches cut-n-paste attack by inserting code-v into a > response using state-0 > 11. The client sends code-v and based on state-0 it sends code_verifyer-0 > to the good AS token endpoint. > 12. The GoodAS verifies that code-verifyer-0 is correct for > code_challange-0 that it bound to code in step 4 > 13. The GoodAS receives RT + AT. > 14. The attacker has now used the client to bind the users resource to > it=E2=80=99s account and is transferring money or looking at your data. > > This could be 3rd party financial app like Mint as an example or photos o= r > any other PII that could then be used to escalate identity theft. > > This variation of the attack combining cut and paste with confused client > was not mentioned in the research papers. > > I found it looking to see if PKCE could be used to mitigate the confused > client attack. > > As I mentioned in a response to William, while the current PKCE Challenge > methods only make the attack harder by forcing the attacker to get > the client to make a step 0 request to get a code_challenge to use in the > request, we could define a new challenge method that would be effective. > > That would remove the need to have a separate mechanism to prevent cut an= d > paste. > > The problem is that the PKCE challenge is independent of state so becomes > vulnerable to the confused client. > > What we would need to do is include state in the challenge so that if the > AS receives mismatched state and code_challange in step 3 the verificatio= n > of code verifier will fail. Effectively combining the cut and paste > mitigation with PKCE. > > I haven=E2=80=99t had time to write this up, but if the code_challenge = =3D=3D SHA256 > (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || > client_id || code-veriyer) , then the attacker could not change state, > client_id, or token_endpoint independently of code_challenge. (note I a= m > using a hash of state to make storage size deterministic for the AS on th= e > grounds that the client already needs to be able to do the hash) (Some > attacks change the client_id in the request so I am including it in the > hash) > > This is slightly more complicated than than S256, but not that much. I > wish I had thought of this when we were doing PKCE. Hit me with > the stupid stick, my fault. > > I don=E2=80=99t know if it stops all the confused client attacks though. > > If the client is confidential then it gives up it=E2=80=99s client secret= assuming > compromised registration, so we can=E2=80=99t really count on that for sy= mmetric > client authentication. > > By including the token endpoint in the comparison if the client is sendin= g > the code to the attacker the client will use a different token endpoint_u= ri > in to calculate the code_challenge than the GoodAS will use to verify it. > This would stop both cut and paste as well as stopping the attacker from > using the code if they get it. The attacker can=E2=80=99t get Secret fo= r state-0, > so it can=E2=80=99t create code_challenge that would be valid. > > This stops the registration attack where the client gets a bad AS > discovery endpoint that has all the Good AS info including dynamic > registration endpoint but the bad AS token endpoint. The bad AS would g= et > the token, client_secret and code_verier, but will fail pkce verification > because the token endpoint will be wrong. > > The attack where the client registers with the good AS but with bad token > endpoint and Authorization endpoint gives the attacker the ability > to change the code_challenge that the Good AS is going to see. It would > need to make a new challenge using state and the GoodAS token endpoint an= d > it=E2=80=99s client_id. > To do that it needs the code_verifier to use to calculate the hash to use > as the code_challenge value. As long as the client is not tricked into > accepting a replay of the authentication response we should be safe. The > client would need to do replay protection on the code_verifier values > before it makes a request to the token endpoint. > > The BadAS could however make up a new code_challenge and code_verifier > and use that in the request. For this one the AS would need to do pull > discovery on the client to get a key, or the AS needs to return something > in the response. This attack can completely proxy all the endpoints as f= ar > as the client is concerned and is taking advantage of the AS saying you a= re > granting permission to site X based on the redirect URI. > > I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a client = from being used > as a redirector back to the attacker unless you also returned the > code_challenge in the response from the authorization endpoint. > > Hypothetically if we returned code_challenge in the response from the > authorization endpoint and have a new PKCE challenge method we might find > it covers all of the attacks. > > We would need to put some serious analysis into this to see if it really > covers all the attacks. > > It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D response_t= ype or steeling the > access token by impersonating the RS. > > I think the correct way to stop the problem with access tokens is by > audience restricting them. > To do that the client needs to provide an audience in it=E2=80=99s reques= t and the > AS needs to include that in the AT. > > I included the Authorization_endpoint URI in the hash to detect if the > auth request may have been tampered with to change the audience for the A= T. > > For implicit we could have a version of PKCE where the AS returns a > parameter with S256( client_id || authorization_endpoint URI || resource > endpoint URI) to verify the request was not tampered with, and that would > allow the AT to be properly audience restricted. > > > This would be a completely new approach not involving discovery, logical > names for AS, or link relations. > > Effectively this code_challenge method becomes a signature over parts of > the request and the implicit audience of the token_endpoint URI. > > People keep asking why PKCE doesn=E2=80=99t stop these attacks, and it wo= n=E2=80=99t with > the current PKCE methods, however a new method along the lines I sketche= d > out may let it work, or I could be completely wrong. > > Too bad I don=E2=80=99t think I will make RSA to go over this in person. > > > John B. > > > > > Nat > > > > > > > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > From: OAuth [mailto:oauth-bounces@ietf.org ] On > Behalf Of John Bradley > Sent: Saturday, February 20, 2016 9:16 PM > To: William Denniss > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for > Adoption > > Inline > > On Feb 20, 2016, at 9:49 AM, William Denniss wrote: > > Maybe it's because I wasn't at the Darmstadt meeting so I don't have the > full context, but I don't find draft A to be all that clear. Here's my > review feedback: > > Regarding the text "a client may be confused simply because it is > receiving authorization responses from more than one authorization server > at the same redirection endpoint". Even if the client re-uses the same > redirection endpoint, shouldn't state solve this? All incoming responses > should have an outgoing request with a matching state that would identify > the authorization request and therefore authorization server. > > > If only that were the case. That is the nub of the problem people think > state works to do that, but it enables the attack not stops it. > > State contains where the client sends the request. The client assumes > any response following that is from the AS it sent the request to. > Most of the attacks documented take advantage of this by misdirecting the > request to a different AS than the one the client =E2=80=9Cthinks=E2=80= =9D it is making the > request to. > > This is done in two ways. One is by pointing at another AS=E2=80=99s auth= orization > endpoint as part of registration, and the other is by redirecting and > rewriting the authorization request. > > The client thinking it has a response from a AS based on state then uses > the associated token and RS endpoints. Those endpoints are wrong for th= e > AS that really returned the response. Thus the client becomes a proxy f= or > relaying responses from the target AS. > > Both mitigations attempt to mitigate this by having the AS return > something that can be compared with state to determine if the request has > been misdirected. > > In one case we return a logical identifier (Name) for the AS that is > compared to a name provided as part of client setup. This name can > optionally be used as the input to discovery to verify other meta-data > about the AS. > > In the second mitigation the URI of the token endpoint or resource server > is returned. > > They both provide a way for the client to determine if the stored state i= s > invalid because the response is coming from a different place than the > request went to. > > It was noted by the researchers that the OIDC flow =E2=80=9Ccode id_token= =E2=80=9D was not > susceptible to this attack because the client validates the issuer of the > id_token and the client_id that the AS thinks it is responding to (some o= f > the attacks rewrite the client_id in the request). > > For reference > http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation po= ints > 2 & 3 of the OIDC validation. > > Knowing that works based on researcher feedback, the first option allows > the two id_token claims to be returned from the Authorization endpoint > without forcing OAuth clients to support signed JWT. It also allows AS = to > provide a issuer URI but allows clients to compare the strings without > forcing them to do discovery. Clients that do discovery can use this > value to bootstrap/validate that. This takes advantage of validation th= at > some clients already perform and applies it to the code response. > > The second option from Nat allows the client to compare the token_endpoin= t > URI from configuration to the one in the response. A difference would > indicate that the AS is different, in a similar way to the other option. > > The difference is that the second option doesn=E2=80=99t include the clie= nt_id and > while I don=E2=80=99t have an attack against that off the top of my head,= it was > felt that it is a open attack surface and should be closed. > > The other difference is I think more subtle and changes OAuth in the > second option (Nat probably argues that would be a good thing). > OAuth to this point assumes that the client is in charge, that the > developer configures the endpoints etc via service documentation. > In the authorization request or the AT request the AS has no information > about what RS is being used as part of the protocol. > > The second option changes that by providing link relationships where each > step provides meta data about where to use the result. > The Authorization endpoint points to the token endpoint, the token > endpoint points to the resource server and the resource server points to > the Authorization endpoint. To get that to work for a number of uses > cases you probably need to tell the authorization endpoint and possibly t= he > token endpoint what resource or resources you want the scopes for. A > given AS might have more than one token endpoint (not common but not > precluded, but something that might happen in multi tenant or other > special cases), and if it is using JWT access tokens it may not even know > about the given RS. > > So to be able to give the meta-data for the next hop the endpoint > responding may need more information. > > The two mitigations are not incompatible, we could do both. > > I do however think that the second one may have architectural side effect= s > that we need to more fully discuss. > Adding link relation/follow your nose processing to OAuth may be a good > thing, but may have impacts that we have not fully thought through yet. > > > > > For the issue of dynamic discovery and the potential to insert a maliciou= s > discovery document: can the recommendation be to use the hybrid flow of > Connect if you do discovery (and validate the issuer before exchanging th= e > code)? Do we need to invent something new for this use-case? > > > As above this would work , but we don;t want to force all OAuth clients t= o > have to deal with JWT. This would be a fix for Connect if we were only > concerned about that. > > > > Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint"), > this describes something that seems similar to what is achieved by PKCE > (RFC7636). Binding information to the authorization code that must be > presented to redeem the code is precisely what PKCE does, and PKCE has > additional security properties. With the PKCE S256 challenge method, > the authorization request and response can leak in their entirety, and ye= t > still the attacker couldn't exchange the authorization code. Let's just > recommend RFC7636 for this mitigation. > > > Unfortunately PKCE makes the assumption that attacker cannot modify the > request. In this case the attacker can modify the request. > > PKCE provides protection in cases where the attacker can=E2=80=99t modify= the PKCE > challenge in the request. > If the attacker can modify the request then they make a new request in a > second browser to get the PKCE challenge and replace the one in the reque= st > being modified by that one. > > I need to think about it a bit more but there might be a way to do it by > defining a new PKCE method. > > If the code_challenge were a HASH of state || code_verifyer, that would > do both. > > The server would need to store state and code_challange. The client woul= d > just calculate the hash over both, but still send the same code_verifier. > ( optimization would be for the code_challange =3D=3D S256 (S256(state) |= | > code_verifier) that way the AS only needs to store the hash of state) > > The attacker can=E2=80=99t change the state in the first request, or the = client > will reject the response, and because the code_verifyer will be different > between the requests the AS would reject the second one because the > code_challange will be wrong. > > That is more complicated for the client, but would allow you to do it wit= h > PKCE with no more crypto than PKCE S256 (the MTI) already requires. > > For Asymmetric PKCE the code_challange would be a JWK of the public key > and the code_verifier would be a JWS (S256(state) ) > (You might want to include code in the JWT but I need to think that > through) > > So yes unless someone finds a flaw in that logic we may be able to define > some PKCE modes to mitigate against cut and paste. > I didn=E2=80=99t think of defining a new PKCE mode at the time. You shou= ld have > been at the meeting:) > > > > The security researcher documents are only informative references, and ye= t > the spec seems to rely on them normatively. E.g.: > * "Mitigating the attacks also relies on the client sending additional > data about the interaction to the token endpoint" (how does this mitigate > the attacks? and what attack exactly?). > * "a client may be confused simply because it is receiving authorization > responses from more than one authorization server" (why is the client > confused?) > I would like to see the attacks normatively described in the spec. > > For my own knowledge: what are some of the use-cases that are subject to > these attacks? I'm not convinced every RP that talks to more than 1 AS is > at risk today. What are some risky situations that exist which are > mitigated by this draft? > > > Any RP is at risk if one of the AS it talks to is compromised, it can > compromise all of the AS that the client talks to. That is just not a go= od > design. > > Hans did a proof of concept that only required access to the logs of one > AS to compromise all AS. > > John B. > > > > > On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) > wrote: > > Option A > > Phil > > > On Feb 19, 2016, at 13:39, Hans Zandbelt > wrote: > > > > Option A: I agree with Mike that the complexity and implementation cost > of Option B will make adoption harder, which was also a concern with the > first iteration of Option A. > > > > To be honest, I'm not sure most people would even understand why the > complexity would be required and just forget about it. At least with the > simplicity of the most recent option A they don't have to care, just add > some simple parameters/checks. > > > > And for the record: I've also implemented option A in the > mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and NGI= NX > respectively. > > > > Hans. > > > > [1] https://github.com/pingidentity/mod_auth_openidc > > [2] https://github.com/pingidentity/lua-resty-openidc > > > >> On 2/19/16 9:18 PM, Mike Jones wrote: > >> Option A. I have higher confidence that this specification solves the > >> problems because it was designed during a 4-day security meeting > >> dedicated to this task by a group of over 20 OAuth security experts, > >> *including both sets of researchers in Germany who originally identifi= ed > >> the problem*. This solution has also been implemented and interop > >> tested by Roland Hedberg, Brian Campbell, and I believe others. Note > >> that the reason I am advocating this specification is **not** because > >> I'm an editor of it; my role was to record in spec language what the > >> OAuth security experts designed together over the 4-day period in > Darmstadt. > >> > >> I=E2=80=99ll also note that even if Option B also solves the problem, = it comes > >> at significant adoption costs and complexity not found in A. In > >> particular, it requires that developers understand support a new =E2= =80=9CLink > >> Relation=E2=80=9D syntax not used elsewhere in OAuth. As Nat writes a= bout his > >> own draft in > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - > there > >> is not a standard JSON syntax for link relations. He writes =E2=80=9C= we could > >> easily create a parallel to it=E2=80=9D. I=E2=80=99d rather we solve = the problem using > >> standard mechanisms already employed in OAuth, rather than risk > >> bifurcating OAuth in the developer community by unnecessarily > >> inventing/creating new syntax that is unfamiliar to developers and tha= t > >> many of them may reject using. > >> > >> -- Mike > >> > >> P.S. Information about the OAuth security meeting can be found at > >> > https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeX= zGptU4/edit > >> and > >> > https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5Ntak= VbA_sk/edit > >> . > >> > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org ] > On Behalf Of Hannes Tschofenig > >> Sent: Friday, February 19, 2016 11:43 AM > >> To: oauth@ietf.org > >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for > >> Adoption > >> > >> Early February I posted a mail to the list to make progress on the > >> solution to the OAuth Authorization Server Mix-Up problem discovered > >> late last year. > >> > >> Here is my mail about the Authorization Server Mix-Up: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html > >> > >> Here is my mail to the list that tries to summarize the discussion > >> status and asked a few questions: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html > >> > >> Unfortunately, my mail didn't lead to the intended success. While ther= e > >> was some feedback I wasn't getting the desired response. > >> > >> In order to move forward I believe we need a working group document th= at > >> serves as a starting point for further work in the group*. We have two > >> documents that provide similar functionality in an attempt to solve th= e > >> Authorization Server Mix-Up problem. > >> > >> So, here is the question for the group. Which document do you want as = a > >> starting point for work on this topic: > >> > >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John > Bradley > >> > >> Link: > >> > >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 > >> > >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and > >> Sascha Preibisch > >> > >> Link: > >> > >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 > >> > >> Deadline for feedback is March, 4th. > >> > >> Ciao > >> > >> Hannes & Derek > >> > >> PS: (*) Regardless of the selected solution we will provide proper > >> acknowledgement for those who contributed to the work. > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Hans Zandbelt | Sr. Technical Architect > > hzandbelt@pingidentity.com | Ping Identity > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e0158b2549c9d8d052c699cb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the very detailed answers John. I like the i= dea of adding a new challenge method to PKCE. This is the sort of thing PKC= E was designed for, so reusing that and adding a bit of logic to the code g= eneration/verification methods, as opposed to more extensions to the OAuth = protocol seems wise. Pity we didn't think of it at the time, and yes I = wish I could have attended the Darmstadt meeting. IETF95 should be a good c= hance to hash out some of these things though (no pun intended)!

I agree with the assumption that from a client ease of implementat= ion perspective, they may wish to re-use the redirection endpoint. It's= not the best approach, but I fear it may be hard forcing people to change.=

Regarding "Without sending the resource in t= he request, the Authorization endpoint, and token endpoints are not necessa= rily going to be able to return the correct next hop." =C2=A0I'm i= nclined to agree, but I'll note that the metadata spec can be used with= out the resource server bits: I do think that the AS should know the token = endpoint and be able to return that (it's equiv to issuer -> discove= ry anyway), and I've always felt that this was a pretty elegant idea (m= ix up mitigation or not).=C2=A0 I also think that perhaps the two drafts ca= n remain separate as they are not directly trying to solve the same problem= .

I strongly believe that the mix-up spec needs to= normatively state the attacks that are being mitigated. I've read the = research papers (which I agree should remain "informative"), yet = this spec doesn't mitigate all the issues (or does it?). It's reall= y hard as a reviewer to verify that the "Mix Up Mitigation" draft= actually mitigates what it claims to, when it doesn't clearly state wh= at the issue is in normative terms.

I also wonder = if the spec could be re-titled and focus on use-case that it solves (suppor= ting multiple ASes without using Connect), rather than the attack it mitiga= tes. I like that the metadata draft is targeted to solve a particular use-c= ase, while mitigating some attacks the process.

On Mon, Feb 22, 2016 at 4:08 AM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Inline

On Feb 22, 2016, at 9:22 AM, Nat= Sakimura <n-s= akimura@nri.co.jp> wrote:

= =C2=A0=C2=A0[case1a] through BadAS to GoodAS redirect<= u>
=C2=A0 [case1b] through tampering the unprotected = client access response
=C2=A0 [case1c] through the= server log
[case2] Token phishing (in case of imp= licit flow).=C2=A0
[case3] Code and C= lient credential phishing
=C2=A0
All of these seem to involve the tampering of the unprotected commu= nication.=C2=A0
If we can secure all = the communication, the problem would be solved for all the variants and for= those that we still do not know. One way of doing it is to use OAuth JAR a= nd authorization response that includes ID Token, but that=E2=80=99s not po= ssible in many cases as I understand.=C2=A0
We have to accommodate a measure that is proportionate to the risks.= =C2=A0
=C2=A0
The risk impact of [case1] is that the code is stolen, and it is used aga= inst the client to =E2=80=9Clogin=E2=80=9D to the client. The attacker will= not have an access to the access token. Is that right? If that is the case= , is this a case that we are really concerned of? Is it not out of scope fo= r OAuth? If so, we can punt this case to something like a login protocol su= ch as OpenID Connect. It also has the notion of =E2=80=9Cissuer=E2=80=9D ba= ked in, so there will be less conflict to use the mix-up draft.=C2=A0=

In this = case with OAuth the information protected by the AT can still be stolen.=C2= =A0 While the attacker doesn=E2=80=99t get the AT directly it gets control = of a client that has the AT. =C2=A0 If I link my Flikr account to your priv= ate Flikr feed, you as the Resource owner is still compromised. =C2=A0 Argu= ing that OAuth didn=E2=80=99t leak the token is not a good argument. =C2=A0= OAuth needs to protect against this.

=C2=A0
The risk impact of [case2] is more OAuth specific. The token is stolen as= the token is going to be sent to a rogue resource, and the resource can us= e that to obtain the resource that was supposed to be only available to the= proper client.=C2=A0
=C2=A0
The risk impact of [case3] is the most grave among these t= hree. Now the attacker can create his own client that impersonates the comp= romised client.=C2=A0
=C2=A0
OAuth-mix-up
--------------------= -------
OAuth-mix-up draft gives one way of addres= sing [case2] by introducing a new concept of =E2=80=9Cissuer=E2=80=9D and = =E2=80=9Cdiscovery=E2=80=9D to RFC6749. It also returns client_id and verif= ies it in 4.2, but if the BadAS has assigned a same client_id to the client= , it does not help.=C2=A0

Client_id are not guaranteed to be unique.=C2=A0 The= y need to be name spaced by the AS. =C2=A0 In OAuth currently we have no na= me for the AS this makes that difficult, the client can use the authorizati= on endpoint URI, but that logic may well break in multi tenant situations. = =C2=A0 Having a clear issuer string makes it easier for the client. =C2=A0<= span class=3D"">
<= /u>=C2=A0
By comparing the issuer stored in the session (= the draft should be explicit about it) with the issuer in the response, the= client can find out that the party he is getting the response from is not = the one he sent a request to, that communication was compromised/tampered w= ith, provided that the response is not tampered by the attacker in-browser.= =C2=A0

Yes
<= /div>
=C2=A0
Note that the response may still be tam= pered (e.g., by MITB) so that the issuer can be re-written, in which case t= he mitigation does not work, but IMHO, we do not have to worry about it her= e, as with MITB, you can do worse things easier.=C2=A0<= /div>

Yes
=C2=A0
One of the issue with this approach is that the central notion o= f =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the aut= horization server that the client received when it registered at the author= ization server=E2=80=9D, but in most existing pure OAuth cases, there is no= such thing, so you cannot compare. This means that you would have to re-re= gister, and if you are doing that, the per-AS redirect_uri seems to be a mu= ch simpler solution.=C2=A0

The client developers I have talked to really hate = per AS redirect URI as being too awkward for deployments. =C2=A0
=
The client would not need to re register to add a issuer URI= to its client_id record. =C2=A0 That is one of the ways to do it.
=C2= =A0
Also note that this is not a general framework for fi= nding out tainted communication, so it may have other holes.=C2=A0
=C2=A0
OAuth-meta<= u>
-------------------
OAuth= -meta is not designed as a specific fix to the problem. Rather, it was desi= gned as a general framework of providing the meta-data to the responses by = leveraging RFC5988 registry. It just happens to mitigate this particular ca= se.=C2=A0
=C2=A0=
Again, it is not a general framework for finding out tainted communica= tion, so it may have other holes.=C2=A0

Without sending the resource in the re= quest, the Authorization endpoint, and token endpoints are not necessarily = going to be able to return the correct next hop.

M= y biggest concern is that this potentially moves some of the client logic i= nto the AS. =C2=A0 I don=E2=80=99t know that that is a bad thing but it fee= ls to me like a real change to OAuth as it currently is. =C2=A0 I think we = need to really think about this change, and how it will impact OAuth overal= l. =C2=A0

I see this as potentially complimentary = OAuth mix up returning a logical name for the AS.

=C2=A0
Per AS Redirect URI
----------------= ----------------
This does not involve wire protoc= ol changes. It just adds requirements on the redirect uri. This by far is t= he simplest solution for [case2] (and [case1]), IMHO.=C2=A0=
=C2=A0
Again, it is not a g= eneral framework for finding out tainted communication, so it may have othe= r holes.

This is= probably the hardest for the client developer and for the deployer.=C2=A0 = Yes it is simplest from a spec point of view.=C2=A0
We need more = developer feedback on this.

=C2=A0
(Exte= nded) PKCE
---------------------------------
<= span lang=3D"EN-US" style=3D"font-size:10pt;font-family:Arial,sans-serif;co= lor:rgb(31,73,125)">To begin with, it works only with code flow. There has = to be something else to deal with implicit flow.=C2=A0<= u>
=C2=A0
PKCE binds the authorizat= ion request/response to the token request.=C2=A0=
If used with a confidential client, it seems to mitigate the vu= lnerability.=C2=A0
John points out th= at it is not the case. I must be missing something here=E2=80=A6 but my log= ic goes like:=C2=A0
=C2=A0<= /u>
=C2=A0
1.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0The good cl= ient creates code_challenge-v and code_verifier-v=3DS256(code_challenge-v) = and sends the client_id-v + code_challenge-v + state to the BadAS Authz EP.= =C2=A0
2.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0BadAS as a = client prepares a code_verifier-b and code_challenge-b=3DS256(code_verifer-= b).=C2=A0
3.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0BadAS re= directs to GoodAS with the client_id-v + code_challenge-b + state-v.=C2=A0<= span>=C2=A0
4.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0GoodAS stores = the code_challenge-b.=C2=A0
5.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0GoodAS returns code-v + state-v to the client=E2=80=99s redirect= uri.=C2=A0
6.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0The c= lient finds the AS from the state and sends code-v + code_verifier-v + secr= et-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished= .=C2=A0
=C2=A0
Now the attacker tries to use the code-v and code_verifier-v.=C2= =A0
=C2=A0
### C= ase A:
7.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0The BadAS as a client sends client_id-v + =E2=80=A6 but he does not hav= e client secret for the good client, so it fails.=C2=A0=
=C2=A0
### Case B:=C2=A0<= /span>
8.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The BadAS as a client send= s client_id-b + code-v + code_verifier-b + secret-b etc. to GoodAS.= =C2=A0
9.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0GoodAS verifies the= code_verifier-b is associated with code-v, but that code-v is not associat= ed with client_id-b, so the token request fails.=C2=A0<= u>
=C2=A0
### Case C: cut-n-paste
10.=C2=A0=C2=A0The attacker launches cut-n-paste attack by replaci= ng the code-b with code-v.=C2=A0
11.=C2=A0=C2=A0The = verifiers does not match, so fails.=C2=A0=
=C2=A0
Please let me know what I am missing.<= span>=C2=A0

In a step 0 the attacker has the good client create another request in t= he attackers user agent to get state-0 and code_challange-0

<= /div>
Step 2 is not required.
Step 3 Bad AS redirects to good= AS with client_id_v + state-v + code_challenge-0
Step 4 GoodAS s= tores code_challenge-0
Step 5 GoodAS returns code-v + state-v to = the clients redirect_uri
Step 6=C2=A0The client finds the A= S from the state and sends code-v + code_verifier-v + secret-b to the BadAS= token endpoint. Now, code-v and code_verifer-v is phished.=C2= =A0

Case C1 : =C2=A0cut = and paste
10.=C2=A0=C2=A0The attacker launches cut-n-paste attac= k by inserting code-v into a response using state-0
11. T= he client sends code-v and based on state-0 it sends code_verifyer-0 to the= good AS token endpoint.
12. The GoodAS verifies that code-= verifyer-0 is correct for code_challange-0 that it bound to code in step 4<= /span>
13. The GoodAS receives RT + AT.
14. The at= tacker has now used the client to bind the users resource to it=E2=80=99s a= ccount and is transferring money or looking at your data.
<= br>
<= span lang=3D"EN-US" style=3D"font-size:10pt;font-family:Arial,sans-serif;co= lor:rgb(31,73,125)">This could be 3rd party financial app like Mint as an e= xample or photos or any other PII that could then be used to escalate ident= ity theft.

This variation of the attac= k combining cut and paste with confused client was not mentioned in the res= earch papers.

I found it looking to se= e if PKCE could be used to mitigate the confused client attack.

As I mentioned in a response to William, while = the current PKCE Challenge methods only make the attack harder by forcing t= he attacker to get the=C2=A0client to make a step 0 request to get a code_c= hallenge to use in the request, =C2=A0we could define a new challenge metho= d that would be effective.

That would remo= ve the need to have a separate mechanism to prevent cut and paste.

The problem is that the PKCE challenge is independ= ent of state so becomes vulnerable to the confused client.
=
What we would need to do is include state in the challenge= so that if the AS receives mismatched state and code_challange in step 3 t= he=C2=A0verification of code verifier will fail. Effectively combining the = cut and paste mitigation with PKCE.

I have= n=E2=80=99t had time to write this up, but if the code_challenge =3D=3D SHA= 256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || c= lient_id || code-veriyer) , =C2=A0then the=C2=A0attacker could not change s= tate, client_id, or token_endpoint =C2=A0independently of code_challenge. = =C2=A0(note I am using a hash of state to make=C2=A0storage size determinis= tic for the AS on the grounds that the client already needs to be able to d= o the hash) (Some attacks =C2=A0change the=C2=A0client_id in the request so= I am including it in the hash)

This is sl= ightly more complicated than than S256, but not that much.=C2=A0 I wish I h= ad thought of this when we were doing PKCE. =C2=A0 Hit me with the=C2=A0stu= pid stick, my fault.

I don=E2=80=99t know = if it stops all the confused client attacks though.

If the client is confidential then it gives up it=E2=80=99s clien= t secret assuming compromised registration, so we can=E2=80=99t really coun= t on that for symmetric client=C2=A0authentication.

By including the token endpoint in the comparison if the client i= s sending the code to the attacker the client will use a different token en= dpoint_uri in=C2=A0to calculate the code_challenge than the GoodAS will use= to verify it. =C2=A0 =C2=A0This would stop both cut and paste as well as s= topping the attacker=C2=A0from using the code if they get it. =C2=A0 The at= tacker can=E2=80=99t get Secret for state-0, so it can=E2=80=99t create cod= e_challenge that would be valid.

This stop= s the registration attack where the client gets a bad AS discovery endpoint= that has all the Good AS info including dynamic registration=C2=A0endpoint= but the bad AS token endpoint. =C2=A0 The bad AS would get the token, clie= nt_secret and code_verier, but will fail pkce verification because=C2=A0the= token endpoint will be wrong.

The attack = where the client registers with the good AS but with bad token endpoint and= Authorization endpoint gives the attacker the ability to=C2=A0change the c= ode_challenge that the Good AS is going to see. =C2=A0 It would need to mak= e a new challenge using state and the GoodAS token=C2=A0endpoint and it=E2= =80=99s client_id. =C2=A0=C2=A0
To do that it needs = the code_verifier to use to calculate the hash to use as the code_challenge= value.=C2=A0 As long as the client is not tricked into accepting a replay = of the authentication response we should be safe.=C2=A0 The client would ne= ed to do replay protection on the code_verifier values before it makes a re= quest to the token endpoint. =C2=A0

The BadAS could however make up a new code_challenge and code_<= /span>verifier and use that in the request. For this one the AS would need = to do pull discovery on the client to get a key, or the AS needs to return = something in the response.=C2=A0 This attack can completely proxy all the e= ndpoints as far as the client is concerned and is taking advantage of the A= S saying you are granting permission to site X based on the redirect URI. = =C2=A0

I can=E2=80=99t see PKCE on it=E2=80=99s ow= n being able to stop a client from being used as a redirector back to the a= ttacker unless you also returned the code_challenge in the response from th= e authorization endpoint.

Hypothetically if we ret= urned code_challenge in the response from the authorization endpoint and ha= ve a new PKCE challenge method we might find it covers all of the attacks.<= /div>

We would need to put some serious analysis into th= is to see if it really covers all the attacks.=C2=A0

It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D response_= type or steeling the access token by impersonating the RS.=C2=A0
=
I think the correct way to stop the problem with access toke= ns is by audience restricting them. =C2=A0
To do that the client = needs to provide an audience in it=E2=80=99s request and the AS needs to in= clude that in the AT.

I included the Authorization= _endpoint URI in the hash to detect if the auth request may have been tampe= red with to change the audience for the AT.

For im= plicit we could have a version of PKCE where the AS returns a parameter wit= h S256( client_id || authorization_endpoint URI || resource endpoint URI) t= o verify the request was not tampered with, and that would allow the AT to = be properly audience restricted.=C2=A0


<= div>This would be a completely new approach not involving discovery, logica= l names for AS, or link relations.

Effectively=C2= =A0this code_challenge method becomes a signature over parts of the request= and the implicit=C2=A0audience of the token_endpoint URI. =C2=A0

People keep asking why PKCE doesn=E2=80=99t stop these atta= cks, and it won=E2=80=99t with the current PKCE methods, =C2=A0however a ne= w method along the lines I sketched out may let it work, or I could be comp= letely wrong.

Too bad I don=E2=80=99t think I will= make RSA to go over this in person.


John B.



=C2=A0
Nat
=C2=A0=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
--
PLEASE READ :This= e-mail is confidential and intended for the
named recipient only. If yo= u are not an intended recipient,
please notify the sender =C2=A0and dele= te this e-mail.
=C2=A0
From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org]=C2=A0On = Behalf Of=C2=A0John Bradley
Sent:=C2=A0Saturday, February 20, 2016 9:16 = PM
To:=C2=A0William Denniss
Cc:=C2=A0oauth@ietf.org
Subject:=C2=A0Re: [OAUTH-WG] Fixi= ng the Authorization Server Mix-Up: Call for Adoption
=C2=A0
Inline
On F= eb 20, 2016, at 9:49 AM, William Denniss <wdenniss@google.com> wrote:
=C2=A0
= Maybe it's because I wasn't at the Darmstadt meeting so I don't= have the full context, but I don't find=C2=A0draft A=C2=A0to be all th= at=C2=A0clear. Here's my review feedback:
=C2=A0
Regarding the te= xt "a client may be confused simply because it is receiving authorizat= ion responses from more than one=C2=A0authorization server at the same redi= rection endpoint". Even if the client re-uses the same redirection end= point, shouldn't=C2=A0state solve this? All incoming responses should h= ave an outgoing request with a matching state that would identify the=C2=A0= authorization request and therefore authorization server.
= =C2=A0
If only that were the case. =C2=A0 That is the nub of the problem= people think state works to do that, but it enables the attack not=C2=A0st= ops it.
=C2=A0
State contains where the client sends the request. =C2= =A0 The client assumes any response following that is from the AS it sent= =C2=A0the request to. =C2=A0
Most of the attacks documented take advanta= ge of this by misdirecting the request to a different AS than the one the c= lient=C2=A0=E2=80=9Cthinks=E2=80=9D it is making the request to. =C2=A0
= =C2=A0
This is done in two ways. One is by pointing at another AS=E2=80= =99s authorization endpoint as part of registration, and the other is=C2=A0= by redirecting and rewriting the authorization request.
=C2=A0
The cl= ient thinking it has a response from a AS based on state then uses the asso= ciated token and RS endpoints. =C2=A0 Those=C2=A0endpoints are wrong for th= e AS that really returned the response. =C2=A0 Thus the client becomes a pr= oxy for relaying responses=C2=A0from the target AS.
=C2=A0
Both mitig= ations attempt to mitigate this by having the AS return something that can = be compared with state to determine if=C2=A0the request has been misdirecte= d.
=C2=A0
In one case we return a logical identifier (Name) for the A= S that is compared to a name provided as part of client setup.=C2=A0 This= =C2=A0name can optionally be used as the input to discovery to verify other= meta-data about the AS.
=C2=A0
In the second mitigation the URI of t= he token endpoint or resource server is returned.
=C2=A0
They both pr= ovide a way for the client to determine if the stored state is invalid beca= use the response is coming from a=C2=A0different place than the request wen= t to.
=C2=A0
It was noted by the researchers that the OIDC flow =E2= =80=9Ccode id_token=E2=80=9D was not susceptible to this attack because the= client=C2=A0validates the issuer of the id_token and the client_id that th= e AS thinks it is responding to (some of the attacks rewrite the=C2=A0clien= t_id in the request).
=C2=A0
For reference=C2=A0http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation= =C2=A0points 2 & 3 of the OIDC=C2=A0validation.
=C2=A0
Knowin= g that works based on researcher feedback, the first option allows the two = id_token claims to be returned from the=C2=A0Authorization endpoint without= forcing OAuth clients to support signed JWT. =C2=A0 It also allows AS to p= rovide a issuer URI but=C2=A0allows clients to compare the strings without = forcing them to do discovery. =C2=A0 Clients that do discovery can use this= value to=C2=A0bootstrap/validate that. =C2=A0 This takes advantage of vali= dation that some clients already perform and applies it to the code=C2=A0re= sponse.
=C2=A0
The second option from Nat allows the client to compar= e the token_endpoint URI from configuration to the one in the=C2=A0response= .=C2=A0 A difference would indicate that the AS is different, in a similar = way to the other option. =C2=A0
=C2=A0
The difference is that the sec= ond option doesn=E2=80=99t include the client_id and while I don=E2=80=99t = have an attack against that off the=C2=A0top of my head, it was felt that i= t is a open attack surface and should be closed. =C2=A0
=C2=A0
The ot= her difference is I think more subtle and changes OAuth in the second optio= n (Nat probably argues that would be a=C2=A0good thing).
OAuth to this p= oint assumes that the client is in charge, that the developer configures th= e endpoints etc via service=C2=A0documentation.
In the authorization req= uest or the AT request the AS has no information about what RS is being use= d as part of the=C2=A0protocol.
=C2=A0
The second option changes that= by providing link relationships where each step provides meta data about w= here to use the=C2=A0result.
The Authorization endpoint points to the to= ken endpoint, the token endpoint points to the resource server and the reso= urce=C2=A0server points to the Authorization endpoint. =C2=A0 To get that t= o work for a number of uses cases you probably need to tell the=C2=A0author= ization endpoint and possibly the token endpoint what resource or resources= you want the scopes for. =C2=A0 =C2=A0A given AS=C2=A0might have more than= one token endpoint (not common but not precluded, =C2=A0but something that= might happen in multi tenant=C2=A0or other special cases), and if it is us= ing JWT access tokens it may not even know about the given RS.
=C2=A0So to be able to give the meta-data for the next hop the endpoint respondi= ng may need more information.
=C2=A0
The two mitigations are not inco= mpatible, we could do both.
=C2=A0
I do however think that the second= one may have architectural side effects that we need to more fully discuss= . =C2=A0
Adding link relation/follow your nose processing to OAuth may b= e a good thing, but may have impacts that we have not fully=C2=A0thought th= rough yet.
=C2=A0
=C2=A0
=C2=A0
For the issue of dynamic discovery an= d the potential to insert a malicious discovery document: can the recommend= ation be=C2=A0to use the hybrid flow of Connect if you do discovery (and va= lidate the issuer before exchanging the code)?=C2=A0 Do we need to=C2=A0inv= ent something new for this use-case?
=C2=A0
As above thi= s would work , but we don;t want to force all OAuth clients to have to deal= with JWT. =C2=A0 This would be a fix for=C2=A0Connect if we were only conc= erned about that.


=C2=A0
Regarding sections 5 & 6 ("Mitiga= tion Data Sent to the Token Endpoint"), this describes something that = seems similar to=C2=A0what is achieved by PKCE (RFC7636). Binding informati= on to the authorization code that must be presented to redeem the=C2=A0code= is precisely what PKCE does, and PKCE has additional security properties. = With the PKCE S256 challenge method, the=C2=A0authorization request and res= ponse can leak in their entirety, and yet still the attacker couldn't e= xchange the authorization=C2=A0code. Let's just recommend RFC7636 for t= his mitigation.
=C2=A0
Unfortunately PKCE makes the assu= mption that attacker cannot modify the request.=C2=A0 In this case the atta= cker can modify=C2=A0the request.=C2=A0
=C2=A0
PKCE provides protecti= on in cases where the attacker can=E2=80=99t modify the PKCE challenge in t= he request.=C2=A0
If the attacker can modify the request then they make = a new request in a second browser to get the PKCE challenge and=C2=A0replac= e the one in the request being modified by that one.
=C2=A0
I need to= think about it a bit more but there might be a way to do it by defining a = new PKCE method.=C2=A0
=C2=A0
If the code_challenge =C2=A0were a HASH= of state || code_verifyer, that would do both. =C2=A0=C2=A0
=C2=A0
T= he server would need to store state and code_challange.=C2=A0 The client wo= uld just calculate the hash over both, but still send=C2=A0the same code_ve= rifier.
( optimization would be for the code_challange =3D=3D S256 (S256= (state) || code_verifier) =C2=A0that way the AS only needs to store the=C2= =A0hash of state)
=C2=A0
The attacker can=E2=80=99t change the state = in the first request, or the client will reject the response, and because t= he code_verifyer=C2=A0will be different between the requests the AS would r= eject the second one because the code_challange will be wrong.
=C2=A0That is more complicated for the client, but would allow you to do it with= PKCE with no more crypto than PKCE S256 (the=C2=A0MTI) already requires.=C2=A0
For Asymmetric PKCE the code_challange would be a JWK of the pu= blic key and the code_verifier would be a JWS=C2=A0(S256(state) )
(You m= ight want to include code in the JWT but I need to think that through)
= =C2=A0
So yes unless someone finds a flaw in that logic we may be able t= o define some PKCE modes to mitigate against cut and=C2=A0paste.
I didn= =E2=80=99t think of defining a new PKCE mode at the time.=C2=A0 You should = have been at the meeting:)
=C2=A0


The security researcher documents= are only informative references, and yet the spec seems to rely on them no= rmatively.=C2=A0E.g.:
* =C2=A0"Mitigating the attacks also relies o= n the client sending additional data about the interaction to the token end= point" (how=C2=A0does this mitigate the attacks? and what attack exact= ly?).
* =C2=A0"a client may be confused simply because it is receiv= ing authorization responses from more than one authorization=C2=A0server&qu= ot; =C2=A0(why is the client confused?)
I would like to see the attacks = normatively described in the spec.
=C2=A0
For my own knowledge: what = are some of the use-cases that are subject to these attacks? I'm not co= nvinced every RP=C2=A0that talks to more than 1 AS is at risk today. What a= re some risky situations that exist which are mitigated by this draft?
<= /blockquote>=C2=A0
Any RP is at risk if one of the AS it talks to is com= promised, it can compromise all of the AS that the client talks to.=C2=A0 T= hat is=C2=A0just not a good design.
=C2=A0
Hans did a proof of concep= t that only required access to the logs of one AS to compromise all AS.
= =C2=A0
John B.
=C2=A0
=C2=A0
=C2=A0
On Fri, Feb 19, 2016 at 9:12 P= M, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zand= belt <hz= andbelt@pingidentity.com> wrote:
>
> Option A: I agree w= ith Mike that the complexity and implementation cost of Option B will make = adoption harder, which=C2=A0was also a concern with the first iteration of = Option A.
>
> To be honest, I'm not sure most people would = even understand why the complexity would be required and just forget=C2=A0a= bout it. At least with the simplicity of the most recent option A they don&= #39;t have to care, just add some simple=C2=A0parameters/checks.
>> And for the record: I've also implemented option A in the mod_aut= h_openidc [1] and lua-resty-openidc [2] clients for=C2=A0Apache and NGINX r= espectively.
>
> Hans.
>
> [1]=C2=A0https://git= hub.com/pingidentity/mod_auth_openidc
> [2]=C2=A0https://git= hub.com/pingidentity/lua-resty-openidc
>
>> On 2/19/16 9= :18 PM, Mike Jones wrote:
>> Option A.=C2=A0 I have higher confide= nce that this specification solves the
>> problems because it was = designed during a 4-day security meeting
>> dedicated to this task= by a group of over 20 OAuth security experts,
>> *including both = sets of researchers in Germany who originally identified
>> the pr= oblem*.=C2=A0 This solution has also been implemented and interop
>&g= t; tested by Roland Hedberg, Brian Campbell, and I believe others.=C2=A0 No= te
>> that the reason I am advocating this specification is **not*= * because
>> I'm an editor of it; my role was to record in spe= c language what the
>> OAuth security experts designed together ov= er the 4-day period in Darmstadt.
>>
>> I=E2=80=99ll also= note that even if Option B also solves the problem, it comes
>> a= t significant adoption costs and complexity not found in A.=C2=A0 In
>= ;> particular, it requires that developers understand support a new =E2= =80=9CLink
>> Relation=E2=80=9D syntax not used elsewhere in OAuth= .=C2=A0 As Nat writes about his
>> own draft in
>>=C2=A0<= a href=3D"http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html"= target=3D"_blank">http://www.ietf.org/mail-archive/web/oauth/current/msg15= 789.html=C2=A0- there
>> is not a standard JSON syntax for lin= k relations.=C2=A0 He writes =E2=80=9Cwe could
>> easily create a = parallel to it=E2=80=9D.=C2=A0 I=E2=80=99d rather we solve the problem usin= g
>> standard mechanisms already employed in OAuth, rather than ri= sk
>> bifurcating OAuth in the developer community by unnecessaril= y
>> inventing/creating new syntax that is unfamiliar to developer= s and that
>> many of them may reject using.
>>
>&g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>= >
>> P.S.=C2=A0 Information about the OAuth security meeting ca= n be found at
>>=C2=A0http= s://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4= /edit
>> and
>>=C2=A0https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSp= O5NtakVbA_sk/edit
>> .
>>
>> -----Original M= essage-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hanne= s Tschofenig
>> Sent: Friday, February 19, 2016 11:43 AM
>&g= t; To:=C2=A0oauth@ietf.= org
>> Subject: [OAUTH-WG] Fixing the Authorization Server Mix= -Up: Call for
>> Adoption
>>
>> Early February I= posted a mail to the list to make progress on the
>> solution to = the OAuth Authorization Server Mix-Up problem discovered
>> late l= ast year.
>>
>> Here is my mail about the Authorization S= erver Mix-Up:
>>
>>=C2=A0http://www.i= etf.org/mail-archive/web/oauth/current/msg15336.html
>>
>= ;> Here is my mail to the list that tries to summarize the discussion>> status and asked a few questions:
>>
>>=C2=A0http://www.ietf.org/mail-archive/web/oauth/current/msg156= 97.html
>>
>> Unfortunately, my mail didn't lead = to the intended success. While there
>> was some feedback I wasn&#= 39;t getting the desired response.
>>
>> In order to move= forward I believe we need a working group document that
>> serves= as a starting point for further work in the group*. We have two
>>= ; documents that provide similar functionality in an attempt to solve the>> Authorization Server Mix-Up problem.
>>
>> So,= here is the question for the group. Which document do you want as a
>= ;> starting point for work on this topic:
>>
>> -- Opt= ion A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley=
>>
>> Link:
>>
>>=C2=A0https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>>
>> -- Option B: 'OAuth Response Metadata' b= y Nat Sakimura, Nov Matake and
>> Sascha Preibisch
>>
= >> Link:
>>
>>=C2=A0https://tools.ietf.= org/html/draft-sakimura-oauth-meta-07
>>
>> Deadline = for feedback is March, 4th.
>>
>> Ciao
>>
>= ;> Hannes & Derek
>>
>> PS: (*) Regardless of the = selected solution we will provide proper
>> acknowledgement for th= ose who contributed to the work.
>>
>>
>>
>= ;> _______________________________________________
>> OAuth mai= ling list
>>=C2=A0OAuth@ietf.org
>>=C2=A0https://www.ietf.org/mailman/listinf= o/oauth
>
> --
> Hans Zandbelt =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| Sr. Technical Architect
>=C2=A0hzandbelt@pingiden= tity.com=C2=A0| Ping Identity
>
> _________________________= ______________________
> OAuth mailing list
>=C2=A0OAuth@ietf.org
>=C2=A0http= s://www.ietf.org/mailman/listinfo/oauth

________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman= /listinfo/oauth
=C2=A0
_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


--089e0158b2549c9d8d052c699cb8-- From nobody Tue Feb 23 00:06:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8861AD1FE for ; Tue, 23 Feb 2016 00:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CymV9vFHIWyc for ; Tue, 23 Feb 2016 00:06:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0669.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::669]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324F91A8797 for ; Tue, 23 Feb 2016 00:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LYQoPpjJKxgPv2ouVhk9zEE5K0DBGI1xqUVNkcXJot4=; b=KskArZHmofQAHQP9DP3cJ/eD81Aa8zyvDoMO689hdax/OsL+CkjBBUKEdhpsc6ZoL+BKZSlUXwRpTOD3F3gbsUHMNu6k0o8FBsxPAOi56Hmxj19nPRzLHLdlmCVpu7QhJS7XOI3PY26iqTDoFoit8oRNpHP0uFUnoZqWIAygtjg= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (10.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 08:05:51 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 08:05:51 +0000 From: Antonio Sanso To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRa02t2hTWxoFIyUukaZslLnZFiJ85S10A Date: Tue, 23 Feb 2016 08:05:50 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> In-Reply-To: <56C7702B.2000401@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.147.117.11] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1029; 5:vyILNAcZ7mQUecRJhUDJUhlN8wPztPj0dGgolDTx2/BdEBzWT3SfgcFlCLhw5pjea/Gbbk526UzvgK2YPCw/xgAIPM1r4U8s0zXloMh/VZKHsCUnmy7BN5g5Xdobrz+j49y/IXS9JKZGfX/0LkCa7g==; 24:cU5I8fRyWhDjqXMd4nDx5lPayqcnfcjPWDWbvluFZSN+aYQ1DzEnrmUfN0Rv2oG4VqGFvDemnL8GlWm5KlzcsDOGyG1ZB62B7bTphwdhtfo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029; x-ms-office365-filtering-correlation-id: 9a97ab27-26df-4b13-52f2-08d33c282540 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(87936001)(102836003)(50986999)(3846002)(76176999)(54356999)(189998001)(11100500001)(110136002)(5001960100002)(106116001)(36756003)(83716003)(5004730100002)(1220700001)(5008740100001)(5002640100001)(4326007)(1096002)(586003)(2906002)(66066001)(15975445007)(3660700001)(6116002)(99286002)(3280700002)(82746002)(92566002)(33656002)(86362001)(2900100001)(2950100001)(10400500002)(40100003)(122556002)(10090500001)(19580405001)(77096005)(19580395003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <6153B3386C4A1E4F8ACB7FD21A50DA25@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 08:05:50.7734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 08:06:08 -0000 hi, FWIW I also find Option A easier to understand/implement. regards antonio On Feb 19, 2016, at 8:42 PM, Hannes Tschofenig = wrote: > Early February I posted a mail to the list to make progress on the > solution to the OAuth Authorization Server Mix-Up problem discovered > late last year. >=20 > Here is my mail about the Authorization Server Mix-Up: > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >=20 > Here is my mail to the list that tries to summarize the discussion > status and asked a few questions: > http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >=20 > Unfortunately, my mail didn't lead to the intended success. While there > was some feedback I wasn't getting the desired response. >=20 > In order to move forward I believe we need a working group document that > serves as a starting point for further work in the group*. We have two > documents that provide similar functionality in an attempt to solve the > Authorization Server Mix-Up problem. >=20 > So, here is the question for the group. Which document do you want as a > starting point for work on this topic: >=20 > -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley >=20 > Link: > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >=20 > -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and > Sascha Preibisch >=20 > Link: > https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >=20 > Deadline for feedback is March, 4th. >=20 > Ciao > Hannes & Derek >=20 > PS: (*) Regardless of the selected solution we will provide proper > acknowledgement for those who contributed to the work. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Feb 23 01:09:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC0E1B3F5E for ; Tue, 23 Feb 2016 01:09:35 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_HB_qk6lP9G for ; Tue, 23 Feb 2016 01:09:33 -0800 (PST) Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8041B3F74 for ; Tue, 23 Feb 2016 01:09:33 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa07-03.prod.phx3.secureserver.net with id Ml9X1s00415ZTut01l9Yvb; Tue, 23 Feb 2016 02:09:33 -0700 To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <56C8360C.8010203@gmx.net> <56C83EEA.8000306@gmx.net> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56CC21CB.7070404@connect2id.com> Date: Tue, 23 Feb 2016 11:09:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050905080603080308050608" Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 09:09:35 -0000 This is a cryptographically signed message in MIME format. --------------ms050905080603080308050608 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, You mention that you spent considerable time in research. I wonder if there is existing theory, in communications or information theory, that can be used to formally establish and prove (or disprove) the security of the proposed OAuth measures? Perhaps some work that is totally unrelated to identity and the web protocols, but could well apply here? My reasoning is that we have a closed system that is fairly simple, so formal analysis must be entirely possible. 1. We have 5 parties (client, AS, RS, user, user agent). 2. The OAuth protocol follows a simple and well-defined pattern of messages between the parties. 3. The points and the number of ways by which an adversary may break into OAuth must therefore be finite. 4. The security requirement is essentially to guarantee the precedence and authenticity of the messages from discovery endpoint to RS, and the preferred way to do that is by establishing a binding between the messages, which can be forward or backward binding. Right now the WG concern is whether all possible attacks have been recognised, and then taken care of. If we can have a formal model that can reliably reveal and prove that, this will be a huge breakthrough. Cheers, Vladimir On 20/02/16 12:41, Mike Jones wrote: > Suggesting that they be read is of course, the right long-term approach= =2E But as someone who spent 20+ years as a researcher before switching = to digital identity, I was sensitive to not wanting to upstage their work= by copying too much of their material into our draft before their public= ations were widely known. I'll of course commit to working the researche= rs and the working group to create a self-contained concise description o= f the threats and mitigations in the working group document. > > Cheers, > -- Mike > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Saturday, February 20, 2016 2:25 AM > To: Mike Jones ; William Denniss ; Phil Hunt (IDM) > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call fo= r Adoption > > Hi Mike, > > On 02/20/2016 10:52 AM, Mike Jones wrote: >> Have you read both of their publications? If not, do yourself a favor= =20 >> and do. They're actually both very readable and quite informative. > I have read both documents. In context of this discussion the question = is whether we > > (a) require them to be read (in which case they should be a normative r= eference), or > (b) suggest them to be read (since they provide additional background i= nformation). In this case they are an informative reference. > > I believe believe we want (b) for the OAuth WG document. While I encour= age everyone to read the publications I also believe that there is lots o= f material in there that goes beyond the information our audience typical= ly reads (such as the text about the formal analysis). > > There is probably also a middle-ground where we either copy relevant te= xt from the papers into the draft or reference specific sections that are= "must-read". > > One other issue: I actually thought that the threat that is outlined in= the research paper is sufficiently well described but the second threat,= which is called 'cut-and-paste attack', requires more work. > I noted this in my summary mail to the list, see http://www.ietf.org/ma= il-archive/web/oauth/current/msg15697.html > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------ms050905080603080308050608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMwOTA5MzFaMC8GCSqGSIb3DQEJBDEiBCADaThAh8x4NiFm5ItLVkaCfkqmch78 fc6qrO+wLl1mEzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQA6mqsj495/ Wv9V5F6tGc01+6EPnbqicBTr9iGpUiHbq5MRnbsywgAPMCL9HlMznGznTvX7YDo+qEbGZlRL ZeUmnoelYNOrfKXTT2iydZ7u8GCN/4RKKKgNajmjOpykIwadHRAKVZK85Vlo8qHiro09CfKG j7L70ImqJ4DD5AGTujgoFkAZU17Asftb+eNiAPDnR3/SP/CNI4QhIlIsPm7vrGXeHGC45ElM Y0vkpFfAHuJM/uUbDe0aE1StCC0gNtsezoW+20NENd8QRiPheZ/LmqmxLP+IaSUcgQvq0Vmh rtN9IVawnVQcGO6UX0HWkOrLuRP4KxtNwG70xYPK+DRkAAAAAAAA --------------ms050905080603080308050608-- From nobody Tue Feb 23 02:28:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9DF1B416E for ; Tue, 23 Feb 2016 02:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQn93Wb5dLD1 for ; Tue, 23 Feb 2016 02:28:32 -0800 (PST) Received: from mx2.uni-trier.de (mx2.uni-trier.de [136.199.224.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EE51B416D for ; Tue, 23 Feb 2016 02:28:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,488,1449529200"; d="scan'208";a="18126674" Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx2i.uni-trier.de with ESMTP; 23 Feb 2016 11:28:07 +0100 Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id 78A2E459E5 for ; Tue, 23 Feb 2016 11:28:07 +0100 (CET) To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <56C8360C.8010203@gmx.net> <56C83EEA.8000306@gmx.net> <56CC21CB.7070404@connect2id.com> From: Daniel Fett Message-ID: <56CC3437.9020908@uni-trier.de> Date: Tue, 23 Feb 2016 11:28:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CC21CB.7070404@connect2id.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 10:28:34 -0000 Hi Valdimir, this is exactly what we did in our research paper. We also analyzed and established a proof of security for one of the proposed mitigations. Of course, any proof always depends on some assumptions (e.g., no untrusted third-party code on RP's web site) and aims at specific security properties. As you can see from the paper, due to the web itself being complex, the analysis is also rather lengthy. In the related work section we also refer to other approaches of formally analyzing web protocols. We do not think that approaches "unrelated to web protocols" can produce useful results, because the web brings many very specific features and constraints. Cheers, Daniel On 23.02.2016 10:09, Vladimir Dzhuvinov wrote: > Hi Mike, > > You mention that you spent considerable time in research. I wonder if > there is existing theory, in communications or information theory, that > can be used to formally establish and prove (or disprove) the security > of the proposed OAuth measures? Perhaps some work that is totally > unrelated to identity and the web protocols, but could well apply here? > > My reasoning is that we have a closed system that is fairly simple, so > formal analysis must be entirely possible. > > 1. We have 5 parties (client, AS, RS, user, user agent). > > 2. The OAuth protocol follows a simple and well-defined pattern of > messages between the parties. > > 3. The points and the number of ways by which an adversary may break > into OAuth must therefore be finite. > > 4. The security requirement is essentially to guarantee the precedence > and authenticity of the messages from discovery endpoint to RS, and the > preferred way to do that is by establishing a binding between the > messages, which can be forward or backward binding. > > > Right now the WG concern is whether all possible attacks have been > recognised, and then taken care of. If we can have a formal model that > can reliably reveal and prove that, this will be a huge breakthrough. > > Cheers, > > Vladimir > > -- Informationssicherheit und Kryptografie Universität Trier - Tel. 0651 201 2847 - H436 From nobody Tue Feb 23 04:35:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628481A889D for ; Tue, 23 Feb 2016 04:35:08 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP1-9NrRlA8p for ; Tue, 23 Feb 2016 04:35:06 -0800 (PST) Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D677D1A886B for ; Tue, 23 Feb 2016 04:35:06 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-07.prod.phx3.secureserver.net with id Mob41s00715ZTut01ob5XF; Tue, 23 Feb 2016 05:35:06 -0700 To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <56C8360C.8010203@gmx.net> <56C83EEA.8000306@gmx.net> <56CC21CB.7070404@connect2id.com> <56CC3437.9020908@uni-trier.de> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56CC51F8.5040707@connect2id.com> Date: Tue, 23 Feb 2016 14:35:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CC3437.9020908@uni-trier.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030600050304010603020209" Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 12:35:08 -0000 This is a cryptographically signed message in MIME format. --------------ms030600050304010603020209 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This sounds fantastic, Daniel. I was only aware of the work by the researchers from RUB.de about the CSRF attack on OIDC discovery. I'm reading the paper right now and want to take some time off to study it in more detail. Congratulations for doing this, Vladimir On 23/02/16 12:28, Daniel Fett wrote: > Hi Valdimir, > > this is exactly what we did in our research paper. We also analyzed and= > established a proof of security for one of the proposed mitigations. > > Of course, any proof always depends on some assumptions (e.g., no > untrusted third-party code on RP's web site) and aims at specific > security properties. > > As you can see from the paper, due to the web itself being complex, the= > analysis is also rather lengthy. > > In the related work section we also refer to other approaches of > formally analyzing web protocols. We do not think that approaches > "unrelated to web protocols" can produce useful results, because the we= b > brings many very specific features and constraints. > > Cheers, > Daniel > > On 23.02.2016 10:09, Vladimir Dzhuvinov wrote: >> Hi Mike, >> >> You mention that you spent considerable time in research. I wonder if >> there is existing theory, in communications or information theory, tha= t >> can be used to formally establish and prove (or disprove) the security= >> of the proposed OAuth measures? Perhaps some work that is totally >> unrelated to identity and the web protocols, but could well apply here= ? >> >> My reasoning is that we have a closed system that is fairly simple, so= >> formal analysis must be entirely possible. >> >> 1. We have 5 parties (client, AS, RS, user, user agent). >> >> 2. The OAuth protocol follows a simple and well-defined pattern of >> messages between the parties. >> >> 3. The points and the number of ways by which an adversary may break >> into OAuth must therefore be finite. >> >> 4. The security requirement is essentially to guarantee the precedence= >> and authenticity of the messages from discovery endpoint to RS, and th= e >> preferred way to do that is by establishing a binding between the >> messages, which can be forward or backward binding. >> >> >> Right now the WG concern is whether all possible attacks have been >> recognised, and then taken care of. If we can have a formal model that= >> can reliably reveal and prove that, this will be a huge breakthrough. >> >> Cheers, >> >> Vladimir >> >> --------------ms030600050304010603020209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxMjM1MDRaMC8GCSqGSIb3DQEJBDEiBCBYb2Uq9Kopio2qGuPfKhjufXIBMWzF X/EObPiZbv13+zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQAZfXyfHZWy Q4InSaVWAppf5ikf0+Mt2Y2V0YNbsUS325gWcVc847SAX8plrlcmeHrpnZZKuNtP4jTx1STz Qpv1T7YwZwQEHxpz7errqJuxct9Znmgsp9TxylZzxYtTZdnW4+RRxPHLLJyPYfgndt6FrxsE IYLzXY/HXDE9kH4bvqp0LMtpAroUu/aff3mmPaORETNy3WIJ4NoPTQdkTtIPquFLDT22QhY9 egid0ggOsEutjybj1EeaDe+YiRaaoils1H8Nm2NHyyfu0bvIKYdhPYXnvxbC8AA3cDtvmnki xLFOu3Xuozk74OrIu5eEr6YzCijk3vn+pxX35Yep5/kPAAAAAAAA --------------ms030600050304010603020209-- From nobody Tue Feb 23 07:00:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5A21B307C for ; Tue, 23 Feb 2016 07:00:20 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A96QbMPETWQM for ; Tue, 23 Feb 2016 07:00:19 -0800 (PST) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05401B3072 for ; Tue, 23 Feb 2016 07:00:18 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa09-01.prod.phx3.secureserver.net with id Mr0H1s00315ZTut01r0HDn; Tue, 23 Feb 2016 08:00:18 -0700 To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56CC7400.5050708@connect2id.com> Date: Tue, 23 Feb 2016 17:00:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040908090106080407010101" Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:00:20 -0000 This is a cryptographically signed message in MIME format. --------------ms040908090106080407010101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23/02/16 07:56, William Denniss wrote: > I also wonder if the spec could be re-titled and focus on use-case that= it > solves (supporting multiple ASes without using Connect), rather than th= e > attack it mitigates. I like that the metadata draft is targeted to solv= e a > particular use-case, while mitigating some attacks the process. I find this reframing an excellent idea. Today I shared the draft with a few client devs I know. Starting from the use case makes it easier to decide when you need to act (as opposed to figuring out what the attack is and then why you need to act). Does your client need to support more than one AS? Ok, then do this ... because -> see security considerations. Vladimir --------------ms040908090106080407010101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxNTAwMTZaMC8GCSqGSIb3DQEJBDEiBCBcrIMJ/SKzvF6BOv18Bn3HhI+yOTu2 A2rVYi9g+ApFJTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBBRWj9wWWe h2ulWJDf0GwOBFm44Px3K7xJRBppFTrJMg0q6wbnkjLp5xI1ojr+R4eta9gt4aAmIRmnxNzG k7zSAjdxQexamjvNsJIweagcATj+FrPXLSZo7o7MDNA9wDjUXtfMCPpNtehR7JyZJQy5gaqu h6J03Zip32jlWf6iX2zCLY848eb8jCJf8AGb8pzZggTbz4DGqfYAFTYGo5I3whmt3OVgA+1h Xs4jJeSTdC29cvpyV37JXj4fbUgO1qOiwSHvoIA2XS76f1icG3VM+LgOi1syH5K8VFwXVBK8 iyQ5L+GmrqeqvJAoYpEwe/iJuk3MUOCK3SSAc21CO9AiAAAAAAAA --------------ms040908090106080407010101-- From nobody Tue Feb 23 07:29:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08F1B3417 for ; Tue, 23 Feb 2016 07:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 8akinKfHhGYj for ; Tue, 23 Feb 2016 07:29:45 -0800 (PST) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35951B3415 for ; Tue, 23 Feb 2016 07:29:44 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa11-02.prod.phx3.secureserver.net with id MrVa1s00415ZTut01rVaXT; Tue, 23 Feb 2016 08:29:44 -0700 To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56CC7ADD.1080403@connect2id.com> Date: Tue, 23 Feb 2016 17:29:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070502050001040606060603" Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:29:53 -0000 This is a cryptographically signed message in MIME format. --------------ms070502050001040606060603 Content-Type: multipart/alternative; boundary="------------030009040505060002050202" This is a multi-part message in MIME format. --------------030009040505060002050202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comment starts at line 173 :) On 22/02/16 14:08, John Bradley wrote: > Inline > >> On Feb 22, 2016, at 9:22 AM, Nat Sakimura wrote= : >> >> [case1] Code phishing + cut-n-paste attack <> >> [case1a] through BadAS to GoodAS redirect >> [case1b] through tampering the unprotected client access response >> [case1c] through the server log >> [case2] Token phishing (in case of implicit flow).=20 >> [case3] Code and Client credential phishing >> =20 >> All of these seem to involve the tampering of the unprotected communic= ation.=20 >> If we can secure all the communication, the problem would be solved fo= r all the variants and for those that we still do not know. One way of do= ing it is to use OAuth JAR and authorization response that includes ID To= ken, but that=92s not possible in many cases as I understand.=20 >> We have to accommodate a measure that is proportionate to the risks.=20 >> =20 >> The risk impact of [case1] is that the code is stolen, and it is used = against the client to =93login=94 to the client. The attacker will not ha= ve an access to the access token. Is that right? If that is the case, is = this a case that we are really concerned of? Is it not out of scope for O= Auth? If so, we can punt this case to something like a login protocol suc= h as OpenID Connect. It also has the notion of =93issuer=94 baked in, so = there will be less conflict to use the mix-up draft.=20 > In this case with OAuth the information protected by the AT can still b= e stolen. While the attacker doesn=92t get the AT directly it gets contr= ol of a client that has the AT. If I link my Flikr account to your priv= ate Flikr feed, you as the Resource owner is still compromised. Arguing= that OAuth didn=92t leak the token is not a good argument. OAuth needs= to protect against this. > >> =20 >> The risk impact of [case2] is more OAuth specific. The token is stolen= as the token is going to be sent to a rogue resource, and the resource c= an use that to obtain the resource that was supposed to be only available= to the proper client.=20 >> =20 >> The risk impact of [case3] is the most grave among these three. Now th= e attacker can create his own client that impersonates the compromised cl= ient.=20 >> =20 >> OAuth-mix-up >> --------------------------- >> OAuth-mix-up draft gives one way of addressing [case2] by introducing = a new concept of =93issuer=94 and =93discovery=94 to RFC6749. It also ret= urns client_id and verifies it in 4.2, but if the BadAS has assigned a sa= me client_id to the client, it does not help.=20 > Client_id are not guaranteed to be unique. They need to be name spaced= by the AS. In OAuth currently we have no name for the AS this makes th= at difficult, the client can use the authorization endpoint URI, but that= logic may well break in multi tenant situations. Having a clear issuer= string makes it easier for the client. =20 >> =20 >> By comparing the issuer stored in the session (the draft should be exp= licit about it) with the issuer in the response, the client can find out = that the party he is getting the response from is not the one he sent a r= equest to, that communication was compromised/tampered with, provided tha= t the response is not tampered by the attacker in-browser.=20 > Yes >> =20 >> Note that the response may still be tampered (e.g., by MITB) so that t= he issuer can be re-written, in which case the mitigation does not work, = but IMHO, we do not have to worry about it here, as with MITB, you can do= worse things easier.=20 > Yes >> =20 >> One of the issue with this approach is that the central notion of =93i= ssuer=94 is new to the existing servers and clients. The verification rul= e in 4.1 states =93Compare the issuer URL for the authorization server th= at the client received when it registered at the authorization server=94,= but in most existing pure OAuth cases, there is no such thing, so you ca= nnot compare. This means that you would have to re-register, and if you a= re doing that, the per-AS redirect_uri seems to be a much simpler solutio= n.=20 > The client developers I have talked to really hate per AS redirect URI = as being too awkward for deployments. =20 > > The client would not need to re register to add a issuer URI to its cli= ent_id record. That is one of the ways to do it. >> =20 >> Also note that this is not a general framework for finding out tainted= communication, so it may have other holes.=20 >> =20 >> OAuth-meta >> ------------------- >> OAuth-meta is not designed as a specific fix to the problem. Rather, i= t was designed as a general framework of providing the meta-data to the r= esponses by leveraging RFC5988 registry. It just happens to mitigate this= particular case.=20 >> =20 >> Again, it is not a general framework for finding out tainted communica= tion, so it may have other holes.=20 > Without sending the resource in the request, the Authorization endpoint= , and token endpoints are not necessarily going to be able to return the = correct next hop. > > My biggest concern is that this potentially moves some of the client lo= gic into the AS. I don=92t know that that is a bad thing but it feels t= o me like a real change to OAuth as it currently is. I think we need to= really think about this change, and how it will impact OAuth overall. =20 > > I see this as potentially complimentary OAuth mix up returning a logica= l name for the AS. > >> =20 >> Per AS Redirect URI >> -------------------------------- >> This does not involve wire protocol changes. It just adds requirements= on the redirect uri. This by far is the simplest solution for [case2] (a= nd [case1]), IMHO.=20 >> =20 >> Again, it is not a general framework for finding out tainted communica= tion, so it may have other holes. > This is probably the hardest for the client developer and for the deplo= yer. Yes it is simplest from a spec point of view.=20 > We need more developer feedback on this. > >> =20 >> (Extended) PKCE >> --------------------------------- >> To begin with, it works only with code flow. There has to be something= else to deal with implicit flow.=20 >> =20 >> PKCE binds the authorization request/response to the token request.=20 >> If used with a confidential client, it seems to mitigate the vulnerabi= lity.=20 >> John points out that it is not the case. I must be missing something h= ere=85 but my logic goes like:=20 >> =20 >> =20 >> 1. The good client creates code_challenge-v and code_verifier-v=3D= S256(code_challenge-v) and sends the client_id-v + code_challenge-v + sta= te to the BadAS Authz EP.=20 >> 2. BadAS as a client prepares a code_verifier-b and code_challenge= -b=3DS256(code_verifer-b).=20 >> 3. BadAS redirects to GoodAS with the client_id-v + code_challenge= -b + state-v. =20 >> 4. GoodAS stores the code_challenge-b.=20 >> 5. GoodAS returns code-v + state-v to the client=92s redirect uri.= =20 >> 6. The client finds the AS from the state and sends code-v + code_= verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_v= erifer-v is phished.=20 >> =20 >> Now the attacker tries to use the code-v and code_verifier-v.=20 >> =20 >> ### Case A: >> 7. The BadAS as a client sends client_id-v + =85 but he does not h= ave client secret for the good client, so it fails.=20 >> =20 >> ### Case B:=20 >> 8. The BadAS as a client sends client_id-b + code-v + code_verifie= r-b + secret-b etc. to GoodAS.=20 >> 9. GoodAS verifies the code_verifier-b is associated with code-v, = but that code-v is not associated with client_id-b, so the token request = fails.=20 >> =20 >> ### Case C: cut-n-paste >> 10. The attacker launches cut-n-paste attack by replacing the code-b = with code-v.=20 >> 11. The verifiers does not match, so fails.=20 >> =20 >> Please let me know what I am missing.=20 > In a step 0 the attacker has the good client create another request in = the attackers user agent to get state-0 and code_challange-0 > > Step 2 is not required. > Step 3 Bad AS redirects to good AS with client_id_v + state-v + code_ch= allenge-0 > Step 4 GoodAS stores code_challenge-0 > Step 5 GoodAS returns code-v + state-v to the clients redirect_uri > Step 6 The client finds the AS from the state and sends code-v + code_v= erifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_ve= rifer-v is phished.=20 > > Case C1 : cut and paste > 10. The attacker launches cut-n-paste attack by inserting code-v into = a response using state-0 > 11. The client sends code-v and based on state-0 it sends code_verifyer= -0 to the good AS token endpoint. > 12. The GoodAS verifies that code-verifyer-0 is correct for code_challa= nge-0 that it bound to code in step 4 > 13. The GoodAS receives RT + AT. > 14. The attacker has now used the client to bind the users resource to = it=92s account and is transferring money or looking at your data. > > This could be 3rd party financial app like Mint as an example or photos= or any other PII that could then be used to escalate identity theft. > > This variation of the attack combining cut and paste with confused clie= nt was not mentioned in the research papers. > > I found it looking to see if PKCE could be used to mitigate the confuse= d client attack. > > As I mentioned in a response to William, while the current PKCE Challen= ge methods only make the attack harder by forcing the attacker to get the= client to make a step 0 request to get a code_challenge to use in the re= quest, we could define a new challenge method that would be effective. > > That would remove the need to have a separate mechanism to prevent cut = and paste. > > The problem is that the PKCE challenge is independent of state so becom= es vulnerable to the confused client. > > What we would need to do is include state in the challenge so that if t= he AS receives mismatched state and code_challange in step 3 the verifica= tion of code verifier will fail. Effectively combining the cut and paste = mitigation with PKCE. > > I haven=92t had time to write this up, but if the code_challenge =3D=3D= SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint UR= I || client_id || code-veriyer) , then the attacker could not change sta= te, client_id, or token_endpoint independently of code_challenge. (note= I am using a hash of state to make storage size deterministic for the AS= on the grounds that the client already needs to be able to do the hash) = (Some attacks change the client_id in the request so I am including it i= n the hash) > > This is slightly more complicated than than S256, but not that much. I= wish I had thought of this when we were doing PKCE. Hit me with the st= upid stick, my fault. > > I don=92t know if it stops all the confused client attacks though. > > If the client is confidential then it gives up it=92s client secret ass= uming compromised registration, so we can=92t really count on that for sy= mmetric client authentication. > > By including the token endpoint in the comparison if the client is send= ing the code to the attacker the client will use a different token endpoi= nt_uri in to calculate the code_challenge than the GoodAS will use to ver= ify it. This would stop both cut and paste as well as stopping the att= acker from using the code if they get it. The attacker can=92t get Secr= et for state-0, so it can=92t create code_challenge that would be valid. > > This stops the registration attack where the client gets a bad AS disco= very endpoint that has all the Good AS info including dynamic registratio= n endpoint but the bad AS token endpoint. The bad AS would get the toke= n, client_secret and code_verier, but will fail pkce verification because= the token endpoint will be wrong. > > The attack where the client registers with the good AS but with bad tok= en endpoint and Authorization endpoint gives the attacker the ability to = change the code_challenge that the Good AS is going to see. It would ne= ed to make a new challenge using state and the GoodAS token endpoint and = it=92s client_id. =20 > To do that it needs the code_verifier to use to calculate the hash to u= se as the code_challenge value. As long as the client is not tricked int= o accepting a replay of the authentication response we should be safe. T= he client would need to do replay protection on the code_verifier values = before it makes a request to the token endpoint. =20 > > The BadAS could however make up a new code_challenge and code_verifier = and use that in the request. For this one the AS would need to do pull di= scovery on the client to get a key, or the AS needs to return something i= n the response. This attack can completely proxy all the endpoints as fa= r as the client is concerned and is taking advantage of the AS saying you= are granting permission to site X based on the redirect URI. =20 > > I can=92t see PKCE on it=92s own being able to stop a client from being= used as a redirector back to the attacker unless you also returned the c= ode_challenge in the response from the authorization endpoint. > > Hypothetically if we returned code_challenge in the response from the a= uthorization endpoint and have a new PKCE challenge method we might find = it covers all of the attacks. > > We would need to put some serious analysis into this to see if it reall= y covers all the attacks.=20 > > It however doesn=92t address the =93token=94 response_type or steeling = the access token by impersonating the RS.=20 > > I think the correct way to stop the problem with access tokens is by au= dience restricting them. =20 > To do that the client needs to provide an audience in it=92s request an= d the AS needs to include that in the AT. > > I included the Authorization_endpoint URI in the hash to detect if the = auth request may have been tampered with to change the audience for the A= T. > > For implicit we could have a version of PKCE where the AS returns a par= ameter with S256( client_id || authorization_endpoint URI || resource end= point URI) to verify the request was not tampered with, and that would al= low the AT to be properly audience restricted.=20 > > > This would be a completely new approach not involving discovery, logica= l names for AS, or link relations. > > Effectively this code_challenge method becomes a signature over parts o= f the request and the implicit audience of the token_endpoint URI. =20 > > People keep asking why PKCE doesn=92t stop these attacks, and it won=92= t with the current PKCE methods, however a new method along the lines I = sketched out may let it work, or I could be completely wrong. > > Too bad I don=92t think I will make RSA to go over this in person. > If PKCE with a new mode manages to fix everything, that would be great! I'm just reframing the essence of the proposed solution, as I roughly understood it: 1. The mix-up attack causes the client to be set up with compromised endpoints. There are 3 ways to prevent that: a) by letting the client submit a signature of the setup endpoints to the AS, via new PKCE mode, or version of PKCE for implicit. b) by letting each AS response hint the URL for the next hop c) by a combination of a & b =3D> a) is best because it's just one extra param, the hash is of fixed size and relatively short 2. The confusion attack is made possible when using more than one AS. There are 3 ways to prevent that: a) by requiring separate redirect_uri for each AS b) by returning the client_id in the AS response b) is best because it can be combined with the mix-up attack prevention via new PKCE mode. If multiple resource URIs are to be included in the hash, how do we make the order predictable? Vladimir > John B. > > > >> =20 >> Nat >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> -- >> PLEASE READ :This e-mail is confidential and intended for the >> named recipient only. If you are not an intended recipient, >> please notify the sender and delete this e-mail. >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> Sent: Saturday, February 20, 2016 9:16 PM >> To: William Denniss >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call f= or Adoption >> =20 >> Inline >>> On Feb 20, 2016, at 9:49 AM, William Denniss wr= ote: >>> =20 >>> Maybe it's because I wasn't at the Darmstadt meeting so I don't have = the full context, but I don't find draft A to be all that clear. Here's m= y review feedback: >>> =20 >>> Regarding the text "a client may be confused simply because it is rec= eiving authorization responses from more than one authorization server at= the same redirection endpoint". Even if the client re-uses the same redi= rection endpoint, shouldn't state solve this? All incoming responses shou= ld have an outgoing request with a matching state that would identify the= authorization request and therefore authorization server. >> =20 >> If only that were the case. That is the nub of the problem people th= ink state works to do that, but it enables the attack not stops it. >> =20 >> State contains where the client sends the request. The client assume= s any response following that is from the AS it sent the request to. =20 >> Most of the attacks documented take advantage of this by misdirecting = the request to a different AS than the one the client =93thinks=94 it is = making the request to. =20 >> =20 >> This is done in two ways. One is by pointing at another AS=92s authori= zation endpoint as part of registration, and the other is by redirecting = and rewriting the authorization request. >> =20 >> The client thinking it has a response from a AS based on state then us= es the associated token and RS endpoints. Those endpoints are wrong for= the AS that really returned the response. Thus the client becomes a pr= oxy for relaying responses from the target AS. >> =20 >> Both mitigations attempt to mitigate this by having the AS return some= thing that can be compared with state to determine if the request has bee= n misdirected. >> =20 >> In one case we return a logical identifier (Name) for the AS that is c= ompared to a name provided as part of client setup. This name can option= ally be used as the input to discovery to verify other meta-data about th= e AS. >> =20 >> In the second mitigation the URI of the token endpoint or resource ser= ver is returned. >> =20 >> They both provide a way for the client to determine if the stored stat= e is invalid because the response is coming from a different place than t= he request went to. >> =20 >> It was noted by the researchers that the OIDC flow =93code id_token=94= was not susceptible to this attack because the client validates the issu= er of the id_token and the client_id that the AS thinks it is responding = to (some of the attacks rewrite the client_id in the request). >> =20 >> For reference http://openid.net/specs/openid-connect-core-1_0.html#IDT= okenValidation points 2 & 3 of the OIDC validation. >> =20 >> Knowing that works based on researcher feedback, the first option allo= ws the two id_token claims to be returned from the Authorization endpoint= without forcing OAuth clients to support signed JWT. It also allows AS= to provide a issuer URI but allows clients to compare the strings withou= t forcing them to do discovery. Clients that do discovery can use this = value to bootstrap/validate that. This takes advantage of validation th= at some clients already perform and applies it to the code response. >> =20 >> The second option from Nat allows the client to compare the token_endp= oint URI from configuration to the one in the response. A difference wou= ld indicate that the AS is different, in a similar way to the other optio= n. =20 >> =20 >> The difference is that the second option doesn=92t include the client_= id and while I don=92t have an attack against that off the top of my head= , it was felt that it is a open attack surface and should be closed. =20 >> =20 >> The other difference is I think more subtle and changes OAuth in the s= econd option (Nat probably argues that would be a good thing). >> OAuth to this point assumes that the client is in charge, that the dev= eloper configures the endpoints etc via service documentation. >> In the authorization request or the AT request the AS has no informati= on about what RS is being used as part of the protocol. >> =20 >> The second option changes that by providing link relationships where e= ach step provides meta data about where to use the result. >> The Authorization endpoint points to the token endpoint, the token end= point points to the resource server and the resource server points to the= Authorization endpoint. To get that to work for a number of uses cases= you probably need to tell the authorization endpoint and possibly the to= ken endpoint what resource or resources you want the scopes for. A giv= en AS might have more than one token endpoint (not common but not preclud= ed, but something that might happen in multi tenant or other special cas= es), and if it is using JWT access tokens it may not even know about the = given RS. >> =20 >> So to be able to give the meta-data for the next hop the endpoint resp= onding may need more information. >> =20 >> The two mitigations are not incompatible, we could do both. >> =20 >> I do however think that the second one may have architectural side eff= ects that we need to more fully discuss. =20 >> Adding link relation/follow your nose processing to OAuth may be a goo= d thing, but may have impacts that we have not fully thought through yet.= >> =20 >>> =20 >>> =20 >>> For the issue of dynamic discovery and the potential to insert a mali= cious discovery document: can the recommendation be to use the hybrid flo= w of Connect if you do discovery (and validate the issuer before exchangi= ng the code)? Do we need to invent something new for this use-case? >> =20 >> As above this would work , but we don;t want to force all OAuth client= s to have to deal with JWT. This would be a fix for Connect if we were = only concerned about that. >> >> >>> =20 >>> Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint= "), this describes something that seems similar to what is achieved by PK= CE (RFC7636). Binding information to the authorization code that must be = presented to redeem the code is precisely what PKCE does, and PKCE has ad= ditional security properties. With the PKCE S256 challenge method, the au= thorization request and response can leak in their entirety, and yet stil= l the attacker couldn't exchange the authorization code. Let's just recom= mend RFC7636 for this mitigation. >>> =20 >> Unfortunately PKCE makes the assumption that attacker cannot modify th= e request. In this case the attacker can modify the request.=20 >> =20 >> PKCE provides protection in cases where the attacker can=92t modify th= e PKCE challenge in the request.=20 >> If the attacker can modify the request then they make a new request in= a second browser to get the PKCE challenge and replace the one in the re= quest being modified by that one. >> =20 >> I need to think about it a bit more but there might be a way to do it = by defining a new PKCE method.=20 >> =20 >> If the code_challenge were a HASH of state || code_verifyer, that wou= ld do both. =20 >> =20 >> The server would need to store state and code_challange. The client w= ould just calculate the hash over both, but still send the same code_veri= fier. >> ( optimization would be for the code_challange =3D=3D S256 (S256(state= ) || code_verifier) that way the AS only needs to store the hash of stat= e) >> =20 >> The attacker can=92t change the state in the first request, or the cli= ent will reject the response, and because the code_verifyer will be diffe= rent between the requests the AS would reject the second one because the = code_challange will be wrong. >> =20 >> That is more complicated for the client, but would allow you to do it = with PKCE with no more crypto than PKCE S256 (the MTI) already requires. >> =20 >> For Asymmetric PKCE the code_challange would be a JWK of the public ke= y and the code_verifier would be a JWS (S256(state) ) >> (You might want to include code in the JWT but I need to think that th= rough) >> =20 >> So yes unless someone finds a flaw in that logic we may be able to def= ine some PKCE modes to mitigate against cut and paste. >> I didn=92t think of defining a new PKCE mode at the time. You should = have been at the meeting:) >> =20 >> >> >>> The security researcher documents are only informative references, an= d yet the spec seems to rely on them normatively. E.g.: >>> * "Mitigating the attacks also relies on the client sending addition= al data about the interaction to the token endpoint" (how does this mitig= ate the attacks? and what attack exactly?). >>> * "a client may be confused simply because it is receiving authoriza= tion responses from more than one authorization server" (why is the clie= nt confused?) >>> I would like to see the attacks normatively described in the spec. >>> =20 >>> For my own knowledge: what are some of the use-cases that are subject= to these attacks? I'm not convinced every RP that talks to more than 1 A= S is at risk today. What are some risky situations that exist which are m= itigated by this draft? >> =20 >> Any RP is at risk if one of the AS it talks to is compromised, it can = compromise all of the AS that the client talks to. That is just not a go= od design. >> =20 >> Hans did a proof of concept that only required access to the logs of o= ne AS to compromise all AS. >> =20 >> John B. >>> =20 >>> =20 >>> =20 >>> On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) wrote: >>>> Option A >>>> >>>> Phil >>>> >>>>> On Feb 19, 2016, at 13:39, Hans Zandbelt wrote: >>>>> >>>>> Option A: I agree with Mike that the complexity and implementation = cost of Option B will make adoption harder, which was also a concern with= the first iteration of Option A. >>>>> >>>>> To be honest, I'm not sure most people would even understand why th= e complexity would be required and just forget about it. At least with th= e simplicity of the most recent option A they don't have to care, just ad= d some simple parameters/checks. >>>>> >>>>> And for the record: I've also implemented option A in the mod_auth_= openidc [1] and lua-resty-openidc [2] clients for Apache and NGINX respec= tively. >>>>> >>>>> Hans. >>>>> >>>>> [1] https://github.com/pingidentity/mod_auth_openidc >>>>> [2] https://github.com/pingidentity/lua-resty-openidc >>>>> >>>>>> On 2/19/16 9:18 PM, Mike Jones wrote: >>>>>> Option A. I have higher confidence that this specification solves= the >>>>>> problems because it was designed during a 4-day security meeting >>>>>> dedicated to this task by a group of over 20 OAuth security expert= s, >>>>>> *including both sets of researchers in Germany who originally iden= tified >>>>>> the problem*. This solution has also been implemented and interop= >>>>>> tested by Roland Hedberg, Brian Campbell, and I believe others. N= ote >>>>>> that the reason I am advocating this specification is **not** beca= use >>>>>> I'm an editor of it; my role was to record in spec language what t= he >>>>>> OAuth security experts designed together over the 4-day period in = Darmstadt. >>>>>> >>>>>> I=92ll also note that even if Option B also solves the problem, it= comes >>>>>> at significant adoption costs and complexity not found in A. In >>>>>> particular, it requires that developers understand support a new =93= Link >>>>>> Relation=94 syntax not used elsewhere in OAuth. As Nat writes abo= ut his >>>>>> own draft in >>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html -= there >>>>>> is not a standard JSON syntax for link relations. He writes =93we= could >>>>>> easily create a parallel to it=94. I=92d rather we solve the prob= lem using >>>>>> standard mechanisms already employed in OAuth, rather than risk >>>>>> bifurcating OAuth in the developer community by unnecessarily >>>>>> inventing/creating new syntax that is unfamiliar to developers and= that >>>>>> many of them may reject using. >>>>>> >>>>>> -- Mike >>>>>> >>>>>> P.S. Information about the OAuth security meeting can be found at= >>>>>> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6= kM5OyeXzGptU4/edit >>>>>> and >>>>>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoS= pO5NtakVbA_sk/edit >>>>>> . >>>>>> >>>>>> -----Original Message----- >>>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Ts= chofenig >>>>>> Sent: Friday, February 19, 2016 11:43 AM >>>>>> To: oauth@ietf.org >>>>>> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call f= or >>>>>> Adoption >>>>>> >>>>>> Early February I posted a mail to the list to make progress on the= >>>>>> solution to the OAuth Authorization Server Mix-Up problem discover= ed >>>>>> late last year. >>>>>> >>>>>> Here is my mail about the Authorization Server Mix-Up: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >>>>>> >>>>>> Here is my mail to the list that tries to summarize the discussion= >>>>>> status and asked a few questions: >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >>>>>> >>>>>> Unfortunately, my mail didn't lead to the intended success. While = there >>>>>> was some feedback I wasn't getting the desired response. >>>>>> >>>>>> In order to move forward I believe we need a working group documen= t that >>>>>> serves as a starting point for further work in the group*. We have= two >>>>>> documents that provide similar functionality in an attempt to solv= e the >>>>>> Authorization Server Mix-Up problem. >>>>>> >>>>>> So, here is the question for the group. Which document do you want= as a >>>>>> starting point for work on this topic: >>>>>> >>>>>> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John = Bradley >>>>>> >>>>>> Link: >>>>>> >>>>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01= >>>>>> >>>>>> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake= and >>>>>> Sascha Preibisch >>>>>> >>>>>> Link: >>>>>> >>>>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >>>>>> >>>>>> Deadline for feedback is March, 4th. >>>>>> >>>>>> Ciao >>>>>> >>>>>> Hannes & Derek >>>>>> >>>>>> PS: (*) Regardless of the selected solution we will provide proper= >>>>>> acknowledgement for those who contributed to the work. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030009040505060002050202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comment starts at line 173 :)

On 22/02/16 14:08, John Bradley wrote:= 
Inline


On Feb 22, 2016, at 9:22 AM, Nat Sakimura <n-sak=
imura@nri.co.jp> wrote:

[case1] Code phishing + cut-n-paste attack=A0 <>
  [case1a] through BadAS to GoodAS redirect
  [case1b] through tampering the unprotected client access response
  [case1c] through the server log
[case2] Token phishing (in case of implicit flow).=20
[case3] Code and Client credential phishing
=20
All of these seem to involve the tampering of the unprotected communicati=
on.=20
If we can secure all the communication, the problem would be solved for a=
ll the variants and for those that we still do not know. One way of doing=
 it is to use OAuth JAR and authorization response that includes ID Token=
, but that=92s not possible in many cases as I understand.=20
We have to accommodate a measure that is proportionate to the risks.=20
=20
The risk impact of [case1] is that the code is stolen, and it is used aga=
inst the client to =93login=94 to the client. The attacker will not have =
an access to the access token. Is that right? If that is the case, is thi=
s a case that we are really concerned of? Is it not out of scope for OAut=
h? If so, we can punt this case to something like a login protocol such a=
s OpenID Connect. It also has the notion of =93issuer=94 baked in, so the=
re will be less conflict to use the mix-up draft.=20

In this case with OAuth the information protected by the AT can still be =
stolen.  While the attacker doesn=92t get the AT directly it gets control=
 of a client that has the AT.   If I link my Flikr account to your privat=
e Flikr feed, you as the Resource owner is still compromised.   Arguing t=
hat OAuth didn=92t leak the token is not a good argument.   OAuth needs t=
o protect against this.


=20
The risk impact of [case2] is more OAuth specific. The token is stolen as=
 the token is going to be sent to a rogue resource, and the resource can =
use that to obtain the resource that was supposed to be only available to=
 the proper client.=20
=20
The risk impact of [case3] is the most grave among these three. Now the a=
ttacker can create his own client that impersonates the compromised clien=
t.=20
=20
OAuth-mix-up
---------------------------
OAuth-mix-up draft gives one way of addressing [case2] by introducing a n=
ew concept of =93issuer=94 and =93discovery=94 to RFC6749. It also return=
s client_id and verifies it in 4.2, but if the BadAS has assigned a same =
client_id to the client, it does not help.=20

Client_id are not guaranteed to be unique.  They need to be name spaced b=
y the AS.   In OAuth currently we have no name for the AS this makes that=
 difficult, the client can use the authorization endpoint URI, but that l=
ogic may well break in multi tenant situations.   Having a clear issuer s=
tring makes it easier for the client. =20

=20
By comparing the issuer stored in the session (the draft should be explic=
it about it) with the issuer in the response, the client can find out tha=
t the party he is getting the response from is not the one he sent a requ=
est to, that communication was compromised/tampered with, provided that t=
he response is not tampered by the attacker in-browser.=20

Yes

=20
Note that the response may still be tampered (e.g., by MITB) so that the =
issuer can be re-written, in which case the mitigation does not work, but=
 IMHO, we do not have to worry about it here, as with MITB, you can do wo=
rse things easier.=20

Yes

=20
One of the issue with this approach is that the central notion of =93issu=
er=94 is new to the existing servers and clients. The verification rule i=
n 4.1 states =93Compare the issuer URL for the authorization server that =
the client received when it registered at the authorization server=94, bu=
t in most existing pure OAuth cases, there is no such thing, so you canno=
t compare. This means that you would have to re-register, and if you are =
doing that, the per-AS redirect_uri seems to be a much simpler solution. =


The client developers I have talked to really hate per AS redirect URI as=
 being too awkward for deployments. =20

The client would not need to re register to add a issuer URI to its clien=
t_id record.   That is one of the ways to do it.

=20
Also note that this is not a general framework for finding out tainted co=
mmunication, so it may have other holes.=20
=20
OAuth-meta
-------------------
OAuth-meta is not designed as a specific fix to the problem. Rather, it w=
as designed as a general framework of providing the meta-data to the resp=
onses by leveraging RFC5988 registry. It just happens to mitigate this pa=
rticular case.=20
=20
Again, it is not a general framework for finding out tainted communicatio=
n, so it may have other holes.=20

Without sending the resource in the request, the Authorization endpoint, =
and token endpoints are not necessarily going to be able to return the co=
rrect next hop.

My biggest concern is that this potentially moves some of the client logi=
c into the AS.   I don=92t know that that is a bad thing but it feels to =
me like a real change to OAuth as it currently is.   I think we need to r=
eally think about this change, and how it will impact OAuth overall. =20

I see this as potentially complimentary OAuth mix up returning a logical =
name for the AS.


=20
Per AS Redirect URI
--------------------------------
This does not involve wire protocol changes. It just adds requirements on=
 the redirect uri. This by far is the simplest solution for [case2] (and =
[case1]), IMHO.=20
=20
Again, it is not a general framework for finding out tainted communicatio=
n, so it may have other holes.

This is probably the hardest for the client developer and for the deploye=
r.  Yes it is simplest from a spec point of view.=20
We need more developer feedback on this.


=20
(Extended) PKCE
---------------------------------
To begin with, it works only with code flow. There has to be something el=
se to deal with implicit flow.=20
=20
PKCE binds the authorization request/response to the token request.=20
If used with a confidential client, it seems to mitigate the vulnerabilit=
y.=20
John points out that it is not the case. I must be missing something here=
=85 but my logic goes like:=20
=20
=20
1.     The good client creates code_challenge-v and code_verifier-v=3DS25=
6(code_challenge-v) and sends the client_id-v + code_challenge-v + state =
to the BadAS Authz EP.=20
2.     BadAS as a client prepares a code_verifier-b and code_challenge-b=3D=
S256(code_verifer-b).=20
3.     BadAS redirects to GoodAS with the client_id-v + code_challenge-b =
+ state-v. =20
4.     GoodAS stores the code_challenge-b.=20
5.     GoodAS returns code-v + state-v to the client=92s redirect uri.=20
6.     The client finds the AS from the state and sends code-v + code_ver=
ifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_veri=
fer-v is phished.=20
=20
Now the attacker tries to use the code-v and code_verifier-v.=20
=20
### Case A:
7.     The BadAS as a client sends client_id-v + =85 but he does not have=
 client secret for the good client, so it fails.=20
=20
### Case B:=20
8.     The BadAS as a client sends client_id-b + code-v + code_verifier-b=
 + secret-b etc. to GoodAS.=20
9.     GoodAS verifies the code_verifier-b is associated with code-v, but=
 that code-v is not associated with client_id-b, so the token request fai=
ls.=20
=20
### Case C: cut-n-paste
10.  The attacker launches cut-n-paste attack by replacing the code-b wit=
h code-v.=20
11.  The verifiers does not match, so fails.=20
=20
Please let me know what I am missing.=20

In a step 0 the attacker has the good client create another request in th=
e attackers user agent to get state-0 and code_challange-0

Step 2 is not required.
Step 3 Bad AS redirects to good AS with client_id_v + state-v + code_chal=
lenge-0
Step 4 GoodAS stores code_challenge-0
Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
Step 6 The client finds the AS from the state and sends code-v + code_ver=
ifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_veri=
fer-v is phished.=20

Case C1 :  cut and paste
10.  The attacker launches cut-n-paste attack by inserting code-v into a =
response using state-0
11. The client sends code-v and based on state-0 it sends code_verifyer-0=
 to the good AS token endpoint.
12. The GoodAS verifies that code-verifyer-0 is correct for code_challang=
e-0 that it bound to code in step 4
13. The GoodAS receives RT + AT.
14. The attacker has now used the client to bind the users resource to it=
=92s account and is transferring money or looking at your data.

This could be 3rd party financial app like Mint as an example or photos o=
r any other PII that could then be used to escalate identity theft.

This variation of the attack combining cut and paste with confused client=
 was not mentioned in the research papers.

I found it looking to see if PKCE could be used to mitigate the confused =
client attack.

As I mentioned in a response to William, while the current PKCE Challenge=
 methods only make the attack harder by forcing the attacker to get the c=
lient to make a step 0 request to get a code_challenge to use in the requ=
est,  we could define a new challenge method that would be effective.

That would remove the need to have a separate mechanism to prevent cut an=
d paste.

The problem is that the PKCE challenge is independent of state so becomes=
 vulnerable to the confused client.

What we would need to do is include state in the challenge so that if the=
 AS receives mismatched state and code_challange in step 3 the verificati=
on of code verifier will fail. Effectively combining the cut and paste mi=
tigation with PKCE.

I haven=92t had time to write this up, but if the code_challenge =3D=3D S=
HA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI =
|| client_id || code-veriyer) ,  then the attacker could not change state=
, client_id, or token_endpoint  independently of code_challenge.  (note I=
 am using a hash of state to make storage size deterministic for the AS o=
n the grounds that the client already needs to be able to do the hash) (S=
ome attacks  change the client_id in the request so I am including it in =
the hash)

This is slightly more complicated than than S256, but not that much.  I w=
ish I had thought of this when we were doing PKCE.   Hit me with the stup=
id stick, my fault.

I don=92t know if it stops all the confused client attacks though.

If the client is confidential then it gives up it=92s client secret assum=
ing compromised registration, so we can=92t really count on that for symm=
etric client authentication.

By including the token endpoint in the comparison if the client is sendin=
g the code to the attacker the client will use a different token endpoint=
_uri in to calculate the code_challenge than the GoodAS will use to verif=
y it.    This would stop both cut and paste as well as stopping the attac=
ker from using the code if they get it.   The attacker can=92t get Secret=
 for state-0, so it can=92t create code_challenge that would be valid.

This stops the registration attack where the client gets a bad AS discove=
ry endpoint that has all the Good AS info including dynamic registration =
endpoint but the bad AS token endpoint.   The bad AS would get the token,=
 client_secret and code_verier, but will fail pkce verification because t=
he token endpoint will be wrong.

The attack where the client registers with the good AS but with bad token=
 endpoint and Authorization endpoint gives the attacker the ability to ch=
ange the code_challenge that the Good AS is going to see.   It would need=
 to make a new challenge using state and the GoodAS token endpoint and it=
=92s client_id.  =20
To do that it needs the code_verifier to use to calculate the hash to use=
 as the code_challenge value.  As long as the client is not tricked into =
accepting a replay of the authentication response we should be safe.  The=
 client would need to do replay protection on the code_verifier values be=
fore it makes a request to the token endpoint. =20

The BadAS could however make up a new code_challenge and code_verifier an=
d use that in the request. For this one the AS would need to do pull disc=
overy on the client to get a key, or the AS needs to return something in =
the response.  This attack can completely proxy all the endpoints as far =
as the client is concerned and is taking advantage of the AS saying you a=
re granting permission to site X based on the redirect URI. =20

I can=92t see PKCE on it=92s own being able to stop a client from being u=
sed as a redirector back to the attacker unless you also returned the cod=
e_challenge in the response from the authorization endpoint.

Hypothetically if we returned code_challenge in the response from the aut=
horization endpoint and have a new PKCE challenge method we might find it=
 covers all of the attacks.

We would need to put some serious analysis into this to see if it really =
covers all the attacks.=20

It however doesn=92t address the =93token=94 response_type or steeling th=
e access token by impersonating the RS.=20

I think the correct way to stop the problem with access tokens is by audi=
ence restricting them. =20
To do that the client needs to provide an audience in it=92s request and =
the AS needs to include that in the AT.

I included the Authorization_endpoint URI in the hash to detect if the au=
th request may have been tampered with to change the audience for the AT.=


For implicit we could have a version of PKCE where the AS returns a param=
eter with S256( client_id || authorization_endpoint URI || resource endpo=
int URI) to verify the request was not tampered with, and that would allo=
w the AT to be properly audience restricted.=20


This would be a completely new approach not involving discovery, logical =
names for AS, or link relations.

Effectively this code_challenge method becomes a signature over parts of =
the request and the implicit audience of the token_endpoint URI. =20

People keep asking why PKCE doesn=92t stop these attacks, and it won=92t =
with the current PKCE methods,  however a new method along the lines I sk=
etched out may let it work, or I could be completely wrong.

Too bad I don=92t think I will make RSA to go over this in person.

If PKCE with a new mode manages to fix everything, that would be great!

I'm just reframing the essence of the proposed solution, as I roughly understood it:

1. The mix-up attack causes the client to be set up with compromised endpoints. There are 3 ways to prevent that:

a) by letting the client submit a signature of the setup endpoints to the AS, via new PKCE mode, or version of PKCE for implicit.
b) by letting each AS response hint the URL for the next hop
c) by a combination of a & b

=3D> a) is best because it's just one extra param, the hash is of fixed size and relatively short



2. The confusion attack is made possible when using more than one AS. There are 3 ways to prevent that:

a) by requiring separate redirect_uri for each AS
b) by returning the client_id in the AS response


b) is best because it can be combined with the mix-up attack prevention via new PKCE mode.



If multiple resource URIs are to be included in the hash, how do we make the order predictable?


Vladimir


John B.




=20
Nat
=20
=20
=20
=20
=20
=20
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradle=
y
Sent: Saturday, February 20, 2016 9:16 PM
To: William Denniss
Cc: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for =
Adoption
=20
Inline

On Feb 20, 2016, at 9:49 AM, William Denniss <w=
denniss@google.com> wrote:
=20
Maybe it's because I wasn't at the Darmstadt meeting so I don't have the =
full context, but I don't find draft A to be all that clear. Here's my re=
view feedback:
=20
Regarding the text "a client may be confused simply because it is receivi=
ng authorization responses from more than one authorization server at the=
 same redirection endpoint". Even if the client re-uses the same redirect=
ion endpoint, shouldn't state solve this? All incoming responses should h=
ave an outgoing request with a matching state that would identify the aut=
horization request and therefore authorization server.

=20
If only that were the case.   That is the nub of the problem people think=
 state works to do that, but it enables the attack not stops it.
=20
State contains where the client sends the request.   The client assumes a=
ny response following that is from the AS it sent the request to. =20
Most of the attacks documented take advantage of this by misdirecting the=
 request to a different AS than the one the client =93thinks=94 it is mak=
ing the request to. =20
=20
This is done in two ways. One is by pointing at another AS=92s authorizat=
ion endpoint as part of registration, and the other is by redirecting and=
 rewriting the authorization request.
=20
The client thinking it has a response from a AS based on state then uses =
the associated token and RS endpoints.   Those endpoints are wrong for th=
e AS that really returned the response.   Thus the client becomes a proxy=
 for relaying responses from the target AS.
=20
Both mitigations attempt to mitigate this by having the AS return somethi=
ng that can be compared with state to determine if the request has been m=
isdirected.
=20
In one case we return a logical identifier (Name) for the AS that is comp=
ared to a name provided as part of client setup.  This name can optionall=
y be used as the input to discovery to verify other meta-data about the A=
S.
=20
In the second mitigation the URI of the token endpoint or resource server=
 is returned.
=20
They both provide a way for the client to determine if the stored state i=
s invalid because the response is coming from a different place than the =
request went to.
=20
It was noted by the researchers that the OIDC flow =93code id_token=94 wa=
s not susceptible to this attack because the client validates the issuer =
of the id_token and the client_id that the AS thinks it is responding to =
(some of the attacks rewrite the client_id in the request).
=20
For reference http://openid.net=
/specs/openid-connect-core-1_0.html#IDTokenValidation points 2 & =
3 of the OIDC validation.
=20
Knowing that works based on researcher feedback, the first option allows =
the two id_token claims to be returned from the Authorization endpoint wi=
thout forcing OAuth clients to support signed JWT.   It also allows AS to=
 provide a issuer URI but allows clients to compare the strings without f=
orcing them to do discovery.   Clients that do discovery can use this val=
ue to bootstrap/validate that.   This takes advantage of validation that =
some clients already perform and applies it to the code response.
=20
The second option from Nat allows the client to compare the token_endpoin=
t URI from configuration to the one in the response.  A difference would =
indicate that the AS is different, in a similar way to the other option. =
=20
=20
The difference is that the second option doesn=92t include the client_id =
and while I don=92t have an attack against that off the top of my head, i=
t was felt that it is a open attack surface and should be closed. =20
=20
The other difference is I think more subtle and changes OAuth in the seco=
nd option (Nat probably argues that would be a good thing).
OAuth to this point assumes that the client is in charge, that the develo=
per configures the endpoints etc via service documentation.
In the authorization request or the AT request the AS has no information =
about what RS is being used as part of the protocol.
=20
The second option changes that by providing link relationships where each=
 step provides meta data about where to use the result.
The Authorization endpoint points to the token endpoint, the token endpoi=
nt points to the resource server and the resource server points to the Au=
thorization endpoint.   To get that to work for a number of uses cases yo=
u probably need to tell the authorization endpoint and possibly the token=
 endpoint what resource or resources you want the scopes for.    A given =
AS might have more than one token endpoint (not common but not precluded,=
  but something that might happen in multi tenant or other special cases)=
, and if it is using JWT access tokens it may not even know about the giv=
en RS.
=20
So to be able to give the meta-data for the next hop the endpoint respond=
ing may need more information.
=20
The two mitigations are not incompatible, we could do both.
=20
I do however think that the second one may have architectural side effect=
s that we need to more fully discuss. =20
Adding link relation/follow your nose processing to OAuth may be a good t=
hing, but may have impacts that we have not fully thought through yet.
=20

=20
=20
For the issue of dynamic discovery and the potential to insert a maliciou=
s discovery document: can the recommendation be to use the hybrid flow of=
 Connect if you do discovery (and validate the issuer before exchanging t=
he code)?  Do we need to invent something new for this use-case?

=20
As above this would work , but we don;t want to force all OAuth clients t=
o have to deal with JWT.   This would be a fix for Connect if we were onl=
y concerned about that.



=20
Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint=
"), this describes something that seems similar to what is achieved by PK=
CE (RFC7636). Binding information to the authorization code that must be =
presented to redeem the code is precisely what PKCE does, and PKCE has ad=
ditional security properties. With the PKCE S256 challenge method, the au=
thorization request and response can leak in their entirety, and yet stil=
l the attacker couldn't exchange the authorization code. Let's just recom=
mend RFC7636 for this mitigation.
=20

Unfortunately PKCE makes the assumption that attac=
ker cannot modify the request.  In this case the attacker can modify the =
request.=20
=20
PKCE provides protection in cases where the attacker can=92t modify the P=
KCE challenge in the request.=20
If the attacker can modify the request then they make a new request in a =
second browser to get the PKCE challenge and replace the one in the reque=
st being modified by that one.
=20
I need to think about it a bit more but there might be a way to do it by =
defining a new PKCE method.=20
=20
If the code_challenge  were a HASH of state || code_verifyer, that would =
do both.  =20
=20
The server would need to store state and code_challange.  The client woul=
d just calculate the hash over both, but still send the same code_verifie=
r.
( optimization would be for the code_challange =3D=3D S256 (S256(state) |=
| code_verifier)  that way the AS only needs to store the hash of state)
=20
The attacker can=92t change the state in the first request, or the client=
 will reject the response, and because the code_verifyer will be differen=
t between the requests the AS would reject the second one because the cod=
e_challange will be wrong.
=20
That is more complicated for the client, but would allow you to do it wit=
h PKCE with no more crypto than PKCE S256 (the MTI) already requires.
=20
For Asymmetric PKCE the code_challange would be a JWK of the public key a=
nd the code_verifier would be a JWS (S256(state) )
(You might want to include code in the JWT but I need to think that throu=
gh)
=20
So yes unless someone finds a flaw in that logic we may be able to define=
 some PKCE modes to mitigate against cut and paste.
I didn=92t think of defining a new PKCE mode at the time.  You should hav=
e been at the meeting:)
=20



The security researcher documents are only infor=
mative references, and yet the spec seems to rely on them normatively. E.=
g.:
*  "Mitigating the attacks also relies on the client sending additional d=
ata about the interaction to the token endpoint" (how does this mitigate =
the attacks? and what attack exactly?).
*  "a client may be confused simply because it is receiving authorization=
 responses from more than one authorization server"  (why is the client c=
onfused?)
I would like to see the attacks normatively described in the spec.
=20
For my own knowledge: what are some of the use-cases that are subject to =
these attacks? I'm not convinced every RP that talks to more than 1 AS is=
 at risk today. What are some risky situations that exist which are mitig=
ated by this draft?

=20
Any RP is at risk if one of the AS it talks to is compromised, it can com=
promise all of the AS that the client talks to.  That is just not a good =
design.
=20
Hans did a proof of concept that only required access to the logs of one =
AS to compromise all AS.
=20
John B.

=20
=20
=20
On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <phil.hunt@oracle.com&=
gt; wrote:

Option A

Phil


On Feb 19, 2016, at 13:39, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Option A: I agree with Mike that the complexity and implementation cost o=
f Option B will make adoption harder, which was also a concern with the f=
irst iteration of Option A.

To be honest, I'm not sure most people would even understand why the comp=
lexity would be required and just forget about it. At least with the simp=
licity of the most recent option A they don't have to care, just add some=
 simple parameters/checks.

And for the record: I've also implemented option A in the mod_auth_openid=
c [1] and lua-resty-openidc [2] clients for Apache and NGINX respectively=
=2E

Hans.

[1] https://github.com/pingidentity/mod_auth_openidc<=
/a>
[2] https://github.com/pingidentity/lua-resty-openid=
c


On 2/19/16 9:18 PM, Mike Jones wrote:
Option A.  I have higher confidence that this specification solves the
problems because it was designed during a 4-day security meeting
dedicated to this task by a group of over 20 OAuth security experts,
*including both sets of researchers in Germany who originally identified
the problem*.  This solution has also been implemented and interop
tested by Roland Hedberg, Brian Campbell, and I believe others.  Note
that the reason I am advocating this specification is **not** because
I'm an editor of it; my role was to record in spec language what the
OAuth security experts designed together over the 4-day period in Darmsta=
dt.

I=92ll also note that even if Option B also solves the problem, it comes
at significant adoption costs and complexity not found in A.  In
particular, it requires that developers understand support a new =93Link
Relation=94 syntax not used elsewhere in OAuth.  As Nat writes about his
own draft in
http://www.ietf.org/mail-archive/web/=
oauth/current/msg15789.html - there
is not a standard JSON syntax for link relations.  He writes =93we could
easily create a parallel to it=94.  I=92d rather we solve the problem usi=
ng
standard mechanisms already employed in OAuth, rather than risk
bifurcating OAuth in the developer community by unnecessarily
inventing/creating new syntax that is unfamiliar to developers and that
many of them may reject using.

                                                          -- Mike

P.S.  Information about the OAuth security meeting can be found at
https://docs.goog=
le.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
and
https://docs.goog=
le.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
=2E

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tsch=
ofenig
Sent: Friday, February 19, 2016 11:43 AM
To: =
oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption

Early February I posted a mail to the list to make progress on the
solution to the OAuth Authorization Server Mix-Up problem discovered
late last year.

Here is my mail about the Authorization Server Mix-Up:

http://www.ietf.org/mail-archive/web/=
oauth/current/msg15336.html

Here is my mail to the list that tries to summarize the discussion
status and asked a few questions:

http://www.ietf.org/mail-archive/web/=
oauth/current/msg15697.html

Unfortunately, my mail didn't lead to the intended success. While there
was some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that
serves as a starting point for further work in the group*. We have two
documents that provide similar functionality in an attempt to solve the
Authorization Server Mix-Up problem.

So, here is the question for the group. Which document do you want as a
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley=


Link:

https://tools.ietf.org/html/draft-j=
ones-oauth-mix-up-mitigation-01

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
Sascha Preibisch

Link:

https://tools.ietf.org/html/draft-sakimura-oa=
uth-meta-07

Deadline for feedback is March, 4th.

Ciao

Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper
acknowledgement for those who contributed to the work.



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

--
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

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

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

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





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


--------------030009040505060002050202-- --------------ms070502050001040606060603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxNTI5MzNaMC8GCSqGSIb3DQEJBDEiBCDSTFkdOfZFn5LKPI53Wg76ViWQxRO3 KqV23fmDaZi2xzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCEXM1PRjKU mwzb3E3GbAIltG0QD4c4copTgrw389qZoZ09Wu01fybZrdgtEBOZkx2OuHwI6qlRsZPfs7FN y94b+TmJSHbXrKlVP7xeJQVFbFL0MKWk1ZuJg2IdibXF835QEjwg3AgmRl1W9H/4C6J1bwv+ 8LmUR77DQDjLDZDe8sQAmxwjqvOCurSRWK8JlVD9nzZUnFFr9WKPwSOWJUywMk84sbLhNqkB UCM/5wM3NlnXIcPmgIehPcU8SfKJKIdOHOOAnzHuYdsnru8kQcuXWebldv0dlXLKjAnCSOYX ZpnmfL3AyTcPO6M/48VhTO2k4LnGOaZXlxhS8yO7iKzqAAAAAAAA --------------ms070502050001040606060603-- From nobody Tue Feb 23 09:15:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B451B371E for ; Tue, 23 Feb 2016 09:15:32 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQqcc9vhpqru for ; Tue, 23 Feb 2016 09:15:31 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27CC1B371C for ; Tue, 23 Feb 2016 09:15:30 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g62so210529310wme.0 for ; Tue, 23 Feb 2016 09:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=JgBX89sc0qIHTcm1aoe4v3mfV1D9ET+CxhGWq4KwYsc=; b=xLRle2D0d8ejbHeAeqXVVfCIPcSSXTQxCZN/2DnauJWb9D/C3dHknF1/MNZ+B9oqn8 sLC/IjJ+Uc6XQTlcTlc96sGtlTjW/qbbvuycEBvxfmykV4zTinJefJlOBOmYRf0fI+Qg 8A1iQpBA5r+ln+VDhPfwLLO0RinGr4ueLM/J2QYcYdI2ZSc7UhPE5NxRx+ponyTS8EO5 D099LUCuGGBYZR9Rz1MvwHL8kBdWsHr3eHt47iO0Qo6yag5QtbP7Jf2sKrmhkSq0Nh6M Yc5a74eRukv1LLMBsefkBLThupJrcb+p67GKYt58kWScGIM2Ji0RzGBlJQhNLjZvxE7A HOBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=JgBX89sc0qIHTcm1aoe4v3mfV1D9ET+CxhGWq4KwYsc=; b=bauiXTaoAngu5mOKsHq3Dtqzh44mxHR4ez4Cdu8U1VWvwVntSKs0XkIRXB5+syPeJm piVDzbLn2ndubNWiO9+5W0PRmrCjbyPtIb24yflzxfg5uI0HmUWO+0c6UONUDF7uephi yJE71mhwKKnJxnYSfCalaDYJ1biEvo5fJpWzw1hwFHGHaxAAUp8B1IwJQwN+U4/uSlee LANUxbPdyh7zysi2SqDQzKBA8JW6ir5cBixAnSSeeNhXU2Ur0avrx3awX2dwd77vhWau PFrXhD3SkZjooHMsUcJDS1xMfP7uoWO4xNw8Vaav4k30KCaPUUnhizNSr7cEZ37W2DMX qrsw== X-Gm-Message-State: AG10YOTA84LSLM0ImZkrbF5575O7/OoWKctBeGzFkCyzZqcS6UD+C+9siTSqRxw+DNlfhw== X-Received: by 10.28.1.196 with SMTP id 187mr19211001wmb.68.1456247729523; Tue, 23 Feb 2016 09:15:29 -0800 (PST) Received: from [192.168.2.7] (31-187-45-195.dynamic.upc.ie. [31.187.45.195]) by smtp.googlemail.com with ESMTPSA id i12sm27103950wmf.10.2016.02.23.09.15.27 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 09:15:28 -0800 (PST) To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> From: Sergey Beryozkin Message-ID: <56CC93AF.1060105@gmail.com> Date: Tue, 23 Feb 2016 17:15:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] JWS Access Token concerns X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:15:32 -0000 Hi Some OAuth2 providers may return self-contained access tokens which are JWS Compact-encoded. I wonder is it really a good idea and would it not be better to only JWE-encrypt the tokens. I'm not sure JWS signing the claims is necessarily faster then only encrypting the claims, assuming the symmetric algorithms are used in both cases. For example, my colleague and myself, while dealing with the issue related to parsing an access token response from a 3rd party provider were able to easily check the content of the JWS-signed access_token by simply submitting an easily recognized JWS Compact-formatted value (3 dots) into our JWS reader - we did not have to worry about decrypting it neither the fact we did not validate the signature mattered. But access tokens are opaque values as far as the clients are concerned and if the introspection is needed then the introspection endpoint does exist for that purpose... Thanks, Sergey From nobody Tue Feb 23 11:32:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708571AC44E for ; Tue, 23 Feb 2016 11:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60xOc9ceYQFo for ; Tue, 23 Feb 2016 11:32:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0642.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2896E1A89B5 for ; Tue, 23 Feb 2016 11:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gZChGTrQQ5Rx3xY5NtulXWyUSXuSLofStOqUCi3jSK0=; b=wYBs/M1xVV5hGag+IaO+b3LejRMopnhGiOWegIRude2UA0UC2PQv+BietFgbIpo5/z/58ONwAWl0IERX5uR0pXH5jrJYUNmcqlUQxeT5sNIkcQbttJjqNPCLk89FRKqpoCgmRCAQug4BxNIvoyeuTlSsdCGmqpBwTuwJlIzWQ6A= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 19:31:41 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 19:31:41 +0000 From: Antonio Sanso To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] JWS Access Token concerns Thread-Index: AQHRbl3Qw2FgwdW1BkqnxfuXZFeE6586BNyA Date: Tue, 23 Feb 2016 19:31:41 +0000 Message-ID: <767F14EC-812F-4ACB-95AB-A70651FF0FB3@adobe.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <56CC93AF.1060105@gmail.com> In-Reply-To: <56CC93AF.1060105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [188.61.97.101] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:ztyjev8ebRtYZWKkjHd0inIJdX+VtXCuekAUVoCEYLA0XDTx7CNgwyl+ar/S1OK0hQA+W0CRIcrqZ7wv7yE6PbV14LP/4SZnom/aKPZ3ZDhDamIapQpzKjMUIFL6ue4EWyut7Y25zU1yERnzruXVNg==; 24:1ldYDP1j24LOdP9QiSwoPEHzAGRpHv/D7uCKgf9oiTTVnXRU665tOo005P4dKggjaKgpbe0rYXTiy0FY6RRuyDin2VZseYZb0FvfUYNL78c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; x-ms-office365-filtering-correlation-id: 14dc91ac-4c3e-435c-a3e6-08d33c87f4cd x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(164054003)(377454003)(40100003)(87936001)(36756003)(83716003)(10090500001)(122556002)(93886004)(86362001)(76176999)(50986999)(54356999)(189998001)(3280700002)(82746002)(11100500001)(106116001)(99286002)(10400500002)(1220700001)(1411001)(5004730100002)(1096002)(33656002)(5008740100001)(6116002)(3846002)(102836003)(586003)(66066001)(4326007)(3660700001)(15975445007)(19580405001)(5001960100002)(19580395003)(77096005)(2950100001)(2906002)(5002640100001)(2900100001)(92566002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <6E0436845079214E84E98EB34CF56116@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 19:31:41.2084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWS Access Token concerns X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:32:08 -0000 hi Sergey, just my 2 cents let=92s start from a simple fact that encryption is not authentication. :) Now, if the claim sets of a JWS contains only not confidential information = JWS is enough. See also inline On Feb 23, 2016, at 6:15 PM, Sergey Beryozkin wrote: > Hi >=20 > Some OAuth2 providers may return self-contained access tokens which are J= WS Compact-encoded. > I wonder is it really a good idea and would it not be better to only JWE-= encrypt the tokens. I'm not sure JWS signing the claims is necessarily fast= er then only encrypting the claims, assuming the symmetric algorithms are u= sed in both cases. JWE algorithms are all AEAD AFAIK so is not only symmetric encryption plus = there is the content key "wrap algorithm=94. regards antonio >=20 > For example, my colleague and myself, while dealing with the issue relate= d to parsing an access token response from a 3rd party provider were able t= o easily check the content of the JWS-signed access_token by simply submitt= ing an easily recognized JWS Compact-formatted value (3 dots) into our JWS = reader - we did not have to worry about decrypting it neither the fact we d= id not validate the signature mattered. >=20 > But access tokens are opaque values as far as the clients are concerned a= nd if the introspection is needed then the introspection endpoint does exis= t for that purpose... >=20 > Thanks, Sergey >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Feb 23 11:41:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FC21A6FC0 for ; Tue, 23 Feb 2016 11:41:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiOn6vo6U8Fq for ; Tue, 23 Feb 2016 11:41:43 -0800 (PST) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179B01A1A27 for ; Tue, 23 Feb 2016 11:41:43 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-01.prod.phx3.secureserver.net with id Mvhh1s00715ZTut01vhiAh; Tue, 23 Feb 2016 12:41:42 -0700 To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <56CC93AF.1060105@gmail.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56CCB5F4.2060105@connect2id.com> Date: Tue, 23 Feb 2016 21:41:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CC93AF.1060105@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080506020408040901020903" Archived-At: Subject: Re: [OAUTH-WG] JWS Access Token concerns X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:41:44 -0000 This is a cryptographically signed message in MIME format. --------------ms080506020408040901020903 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sergey, JWE will indeed make the token content confidential to clients. However, without a proper signature (RSA or EC, HMAC in JWS doesn't qualify), the RS cannot establish the origin of the token. With symmetric crypto (e.g. JWE alg=3Ddir) anyone who has the shared key will be able to create a token (e.g. other RS in the domain that rely on the AS). With asymmetric crypto, anyone with access to the public key of the RS will be able to encrypt for the recipient. Hope this helps, On 23/02/16 19:15, Sergey Beryozkin wrote: > Hi > > Some OAuth2 providers may return self-contained access tokens which > are JWS Compact-encoded. > I wonder is it really a good idea and would it not be better to only > JWE-encrypt the tokens. I'm not sure JWS signing the claims is > necessarily faster then only encrypting the claims, assuming the > symmetric algorithms are used in both cases. > > For example, my colleague and myself, while dealing with the issue > related to parsing an access token response from a 3rd party provider > were able to easily check the content of the JWS-signed access_token > by simply submitting an easily recognized JWS Compact-formatted value > (3 dots) into our JWS reader - we did not have to worry about > decrypting it neither the fact we did not validate the signature > mattered. > > But access tokens are opaque values as far as the clients are > concerned and if the introspection is needed then the introspection > endpoint does exist for that purpose... > > Thanks, Sergey > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------ms080506020408040901020903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxOTQxNDBaMC8GCSqGSIb3DQEJBDEiBCDgi7hV52MlKDamAWJoF4CPaekl7aDD 8S1czNhEZ/3UQjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCH4fiyKkAa +szhPyoIDG3036qnFy6e3sphBBIELWnz6SzvMNM9AId50qIMvImxn7jY+w3u/abz8qz5DXI0 r8nJJiI+yCJh3brd8dKoiNOKwzqrc8eVhWET3DkdUu3XuQ5yQx/RuTZQrNHhjg+s5RQlyiFG bhsHFpNJW8neyA8BJS7ZB/d/33adp1heEqyjPok+3zumIG6hjwQJ/VKH9aH6JCTuXE29+V/W 3QfsRj3y9n626IbsAnrN+gnoTX4cqFtUzDemWtiu9ws+Y5LCzvra3CEz4N0B9JlicmUKLEpw QdvxvEUfaHW3Tv4ghFmjBe2ZdAXmsCd+ikoWKH/5O/6GAAAAAAAA --------------ms080506020408040901020903-- From nobody Tue Feb 23 12:59:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8F1B2C65 for ; Tue, 23 Feb 2016 12:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pti7ajOsRWxF for ; Tue, 23 Feb 2016 12:59:48 -0800 (PST) Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDE21B2BCF for ; Tue, 23 Feb 2016 12:59:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,491,1449529200"; d="asc'?scan'208";a="87834477" X-IPAS-Result: A2CjBADzx8xW/8sN74JVCRkBAQEBDwEBAQGCX4FqBrhThAeGDQKCGQEBAQEBAWUnhEEBAQEBAgEdBk8HBQsCAQgOChUVAgIyJQIECgQFDg0Eh3cIAa5FjmoBAQEBBgEBAQEBAQERCIYSgWwIgkaEDBECVYJBK4EPBYdWAoVShUmEFIFBgUeBZIpOhEOIUo5JYoICARmBSGqGfDwBfAEBAQ Received: from umu-ex03.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.203]) by smtp5.umu.se with ESMTP; 23 Feb 2016 21:59:25 +0100 Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 23 Feb 2016 21:59:19 +0100 Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Tue, 23 Feb 2016 21:59:19 +0100 From: Roland Hedberg To: John Bradley Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRbn0QrfQBk4eaeU+bly+14EltRw== Date: Tue, 23 Feb 2016 20:59:19 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> In-Reply-To: <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.239.144.158] Content-Type: multipart/signed; boundary="Apple-Mail=_829389C4-7F6A-41B1-83E9-87BC200101BD"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:59:53 -0000 --Apple-Mail=_829389C4-7F6A-41B1-83E9-87BC200101BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In line ! > 22 feb 2016 kl. 05:08 skrev John Bradley : >=20 >> On Feb 22, 2016, at 9:22 AM, Nat Sakimura = wrote: >>=20 >> The risk impact of [case2] is more OAuth specific. The token is = stolen as the token is going to be sent to a rogue resource, and the = resource can use that to obtain the resource that was supposed to be = only available to the proper client. >>=20 >> The risk impact of [case3] is the most grave among these three. Now = the attacker can create his own client that impersonates the compromised = client. >>=20 >> OAuth-mix-up >> --------------------------- >> OAuth-mix-up draft gives one way of addressing [case2] by introducing = a new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D = to RFC6749. It also returns client_id and verifies it in 4.2, but if the = BadAS has assigned a same client_id to the client, it does not help. >=20 > Client_id are not guaranteed to be unique. They need to be name = spaced by the AS. In OAuth currently we have no name for the AS this = makes that difficult, the client can use the authorization endpoint URI, = but that logic may well break in multi tenant situations. Having a = clear issuer string makes it easier for the client. I stumbled over exactly this point when I made my implementation follow = the Mix-Up draft. If not discovery is involved I think an AS has to have a name which is = different from the endpoint URIs. >> One of the issue with this approach is that the central notion of = =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the = authorization server that the client received when it registered at the = authorization server=E2=80=9D, but in most existing pure OAuth cases, = there is no such thing, so you cannot compare. This means that you would = have to re-register, and if you are doing that, the per-AS redirect_uri = seems to be a much simpler solution. >=20 > The client developers I have talked to really hate per AS redirect URI = as being too awkward for deployments. I on the other hand found it quite easy to do per AS redirect URIs, so = it might well be implementation dependent rather then contextual. >>=20 >> Per AS Redirect URI >> -------------------------------- >> This does not involve wire protocol changes. It just adds = requirements on the redirect uri. This by far is the simplest solution = for [case2] (and [case1]), IMHO. >>=20 >> Again, it is not a general framework for finding out tainted = communication, so it may have other holes. >=20 > This is probably the hardest for the client developer and for the = deployer. Yes it is simplest from a spec point of view. > We need more developer feedback on this. As I said above I found this quite simple to implement. >> (Extended) PKCE >> --------------------------------- >> To begin with, it works only with code flow. There has to be = something else to deal with implicit flow. >>=20 >> PKCE binds the authorization request/response to the token request. >> If used with a confidential client, it seems to mitigate the = vulnerability. >> John points out that it is not the case. I must be missing something = here=E2=80=A6 but my logic goes like: >>=20 >>=20 >> 1. The good client creates code_challenge-v and = code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + = code_challenge-v + state to the BadAS Authz EP. >> 2. BadAS as a client prepares a code_verifier-b and = code_challenge-b=3DS256(code_verifer-b). >> 3. BadAS redirects to GoodAS with the client_id-v + = code_challenge-b + state-v. >> 4. GoodAS stores the code_challenge-b. >> 5. GoodAS returns code-v + state-v to the client=E2=80=99s = redirect uri. >> 6. The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished. >>=20 >> Now the attacker tries to use the code-v and code_verifier-v. >>=20 >> ### Case A: >> 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he = does not have client secret for the good client, so it fails. >>=20 >> ### Case B: >> 8. The BadAS as a client sends client_id-b + code-v + = code_verifier-b + secret-b etc. to GoodAS. >> 9. GoodAS verifies the code_verifier-b is associated with code-v, = but that code-v is not associated with client_id-b, so the token request = fails. >>=20 >> ### Case C: cut-n-paste >> 10. The attacker launches cut-n-paste attack by replacing the code-b = with code-v. >> 11. The verifiers does not match, so fails. >>=20 >> Please let me know what I am missing. >=20 > In a step 0 the attacker has the good client create another request in = the attackers user agent to get state-0 and code_challange-0 >=20 > Step 2 is not required. > Step 3 Bad AS redirects to good AS with client_id_v + state-v + = code_challenge-0 > Step 4 GoodAS stores code_challenge-0 > Step 5 GoodAS returns code-v + state-v to the clients redirect_uri > Step 6 The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished. >=20 > Case C1 : cut and paste > 10. The attacker launches cut-n-paste attack by inserting code-v into = a response using state-0 > 11. The client sends code-v and based on state-0 it sends = code_verifyer-0 to the good AS token endpoint. > 12. The GoodAS verifies that code-verifyer-0 is correct for = code_challange-0 that it bound to code in step 4 > 13. The GoodAS receives RT + AT. > 14. The attacker has now used the client to bind the users resource to = it=E2=80=99s account and is transferring money or looking at your data. >=20 > This could be 3rd party financial app like Mint as an example or = photos or any other PII that could then be used to escalate identity = theft. >=20 > This variation of the attack combining cut and paste with confused = client was not mentioned in the research papers. >=20 > I found it looking to see if PKCE could be used to mitigate the = confused client attack. >=20 > As I mentioned in a response to William, while the current PKCE = Challenge methods only make the attack harder by forcing the attacker to = get the client to make a step 0 request to get a code_challenge to use = in the request, we could define a new challenge method that would be = effective. >=20 > That would remove the need to have a separate mechanism to prevent cut = and paste. >=20 > The problem is that the PKCE challenge is independent of state so = becomes vulnerable to the confused client. >=20 > What we would need to do is include state in the challenge so that if = the AS receives mismatched state and code_challange in step 3 the = verification of code verifier will fail. Effectively combining the cut = and paste mitigation with PKCE. >=20 > I haven=E2=80=99t had time to write this up, but if the code_challenge = =3D=3D SHA256 (SHA256(state) || token_endpoint URI || = Authorization_endpoint URI || client_id || code-veriyer) , then the = attacker could not change state, client_id, or token_endpoint = independently of code_challenge. (note I am using a hash of state to = make storage size deterministic for the AS on the grounds that the = client already needs to be able to do the hash) (Some attacks change = the client_id in the request so I am including it in the hash) >=20 > This is slightly more complicated than than S256, but not that much. = I wish I had thought of this when we were doing PKCE. Hit me with the = stupid stick, my fault. >=20 > I don=E2=80=99t know if it stops all the confused client attacks = though. >=20 > If the client is confidential then it gives up it=E2=80=99s client = secret assuming compromised registration, so we can=E2=80=99t really = count on that for symmetric client authentication. >=20 > By including the token endpoint in the comparison if the client is = sending the code to the attacker the client will use a different token = endpoint_uri in to calculate the code_challenge than the GoodAS will use = to verify it. This would stop both cut and paste as well as stopping = the attacker from using the code if they get it. The attacker can=E2=80=99= t get Secret for state-0, so it can=E2=80=99t create code_challenge that = would be valid. >=20 > This stops the registration attack where the client gets a bad AS = discovery endpoint that has all the Good AS info including dynamic = registration endpoint but the bad AS token endpoint. The bad AS would = get the token, client_secret and code_verier, but will fail pkce = verification because the token endpoint will be wrong. >=20 > The attack where the client registers with the good AS but with bad = token endpoint and Authorization endpoint gives the attacker the ability = to change the code_challenge that the Good AS is going to see. It = would need to make a new challenge using state and the GoodAS token = endpoint and it=E2=80=99s client_id. > To do that it needs the code_verifier to use to calculate the hash to = use as the code_challenge value. As long as the client is not tricked = into accepting a replay of the authentication response we should be = safe. The client would need to do replay protection on the = code_verifier values before it makes a request to the token endpoint. >=20 > The BadAS could however make up a new code_challenge and code_verifier = and use that in the request. For this one the AS would need to do pull = discovery on the client to get a key, or the AS needs to return = something in the response. This attack can completely proxy all the = endpoints as far as the client is concerned and is taking advantage of = the AS saying you are granting permission to site X based on the = redirect URI. >=20 > I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a = client from being used as a redirector back to the attacker unless you = also returned the code_challenge in the response from the authorization = endpoint. >=20 > Hypothetically if we returned code_challenge in the response from the = authorization endpoint and have a new PKCE challenge method we might = find it covers all of the attacks. >=20 > We would need to put some serious analysis into this to see if it = really covers all the attacks. >=20 > It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D = response_type or steeling the access token by impersonating the RS. >=20 > I think the correct way to stop the problem with access tokens is by = audience restricting them. > To do that the client needs to provide an audience in it=E2=80=99s = request and the AS needs to include that in the AT. >=20 > I included the Authorization_endpoint URI in the hash to detect if the = auth request may have been tampered with to change the audience for the = AT. >=20 > For implicit we could have a version of PKCE where the AS returns a = parameter with S256( client_id || authorization_endpoint URI || resource = endpoint URI) to verify the request was not tampered with, and that = would allow the AT to be properly audience restricted. >=20 >=20 > This would be a completely new approach not involving discovery, = logical names for AS, or link relations. >=20 > Effectively this code_challenge method becomes a signature over parts = of the request and the implicit audience of the token_endpoint URI. >=20 > People keep asking why PKCE doesn=E2=80=99t stop these attacks, and it = won=E2=80=99t with the current PKCE methods, however a new method along = the lines I sketched out may let it work, or I could be completely = wrong. Once you have written down something more definite I promise to = implement it promptly such that we can do interop testing early in the process. Before John brought up this new PKCE mode I was on the Option A side of = the fence now I=E2=80=99d like to see more of this PKCE idea before committing to one or the other. =E2=80=94 Roland =E2=80=9DEverybody should be quiet near a little stream and listen." =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss --Apple-Mail=_829389C4-7F6A-41B1-83E9-87BC200101BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWzMglAAoJEMHjX+0KUIOomtAP/iWYiklNKNjRVjxhaL7sZckC qQnUjv6ujEgzDJr5k5zKH0m9omLLvTGzBxW5jcaoGSAuBi0k/85bFDjXZPj/tAgs LmXSa23bC4mX10QZ5wVrnZCy2fxtz9O8EJ5IzprHA+mWEoDUz3PMWwrhjuZ8GJbV PI3sGcQf47N1Z2Aev3mg09a8fqK1EdgPriIhsv1ukcF14X7tEhPHqhzTJ7jZ6eh3 c2ZfKuc4QXKIh8c9Y2NeCwRZzJh5pN+q7istK733IeuWPF7M1lw2T+fFAfanceFi P9kq7DbhRGl5UM19ft+V3HK1Lw5/QVKNASjUZsN3b/9P6NuXJGYlWO5hEcMiPMCq 0bNeG+gLD8edQLdRwDoLTumbqpkISNRcwPTXyf79sVJiQzSVR6Zc4FIDfpXjD0UJ GxOyhtnR6m07a9t7HUo2E5+VlGiQZ3MwCP+hPF9qv7qnGKVC58udoMh3g5XgEUfl 54eDb9JzLk9e3oFtJOzKZZl5tx7jnTeNXLaICdsc+94807fIt9u/C9qs9TJZ7/pj ROQ30ggJhejHTmj2LmGJewF1syFoV5fCeC7XLAWTkW3L82u7T1IqX6f0zTx2mPtA vrwjvlmG4XRUd452Si8W7n2qR8K3XmCsABKLfy++rSLbnh0Aj66XmMqZt4tUfaLQ 4zV7syS2UWuiLEiA5Ifm =Mwzk -----END PGP SIGNATURE----- --Apple-Mail=_829389C4-7F6A-41B1-83E9-87BC200101BD-- From nobody Tue Feb 23 13:54:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9371ACCF6 for ; Tue, 23 Feb 2016 13:54:38 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Au1e7Namij for ; Tue, 23 Feb 2016 13:54:36 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774E71A8AB3 for ; Tue, 23 Feb 2016 13:54:36 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id g62so244073081wme.1 for ; Tue, 23 Feb 2016 13:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Kr0akONdsVF9yrjHko2WWWvYI8jgMSYB4wzj2JBHPM0=; b=LxvrpdqcRY1BFdrP+ccASz2cnd65sWWnS8cAB71SEY1Sjq36RINk9JJtyf5iwcZi8a EycBJzoi/w6tUCTT1hYd34/Isrcg5ICo91aUw2ZkAob3Tugfau42njhkzjgjW8H5hELO dxL3mVRyYVEBkjPWckmygDqFoUBHRC99c0UQkE+GYAhNK4j0t30B9ZsYnLb9tjs+hTvv zH1BW3MqHmp6TsDxHXVqqFPm8NEwwTxhQKXm4Nhz65InQlnQxbxmWaLw99gIYqCwnH7P BuIAg7kqLtKNJDAkaHQ77zvqDvltRQfkNy5z3UlDgKI+oKhLYOQRHSYg7qVwHowwRO+7 iYOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Kr0akONdsVF9yrjHko2WWWvYI8jgMSYB4wzj2JBHPM0=; b=hooGbLYhCEj4YiQ9WlvCK7R9emwNyvVKZKm49qVlpnbF2YTUgZDkoLT5A6IIcg6F5k iHWkSfqhbeEy4DrNzap7+R+qDJSjb1SZQ6nyDiE5AJvbGbKvn+9u76+mxIHzZcLLixRa NR6Q8Y7JO2fQ0jLnTg5iB6MdlQ7PaLdhxogOysj7t55TU/dlU1A/4VKZ66qak8sdYqAt fzFvZx9st92YQv6pxuaA4wjoTebxpg7T2GnzT48AyOZtE3jhUvk1Axbwl6EjXWO5DUOD r8ZGrUwMD39kS7lSrNNramSqJJcTRjegdnUC66UabNgFqgMore2g0uyzqHK9m+pSvKgI gI4Q== X-Gm-Message-State: AG10YOTUNbrvCt9SdeGrs3SSWvwfzi9Lgt+Z+fRM1aGPuv5cN14Nx5/5sTMnD0X9BG9UoA== X-Received: by 10.194.86.130 with SMTP id p2mr668285wjz.93.1456264474902; Tue, 23 Feb 2016 13:54:34 -0800 (PST) Received: from [192.168.2.7] (31-187-45-195.dynamic.upc.ie. [31.187.45.195]) by smtp.googlemail.com with ESMTPSA id x65sm335173wmg.4.2016.02.23.13.54.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 13:54:34 -0800 (PST) To: Antonio Sanso References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <56CC93AF.1060105@gmail.com> <767F14EC-812F-4ACB-95AB-A70651FF0FB3@adobe.com> From: Sergey Beryozkin Message-ID: <56CCD50C.9000803@gmail.com> Date: Tue, 23 Feb 2016 21:54:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <767F14EC-812F-4ACB-95AB-A70651FF0FB3@adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWS Access Token concerns X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 21:54:38 -0000 Hi On 23/02/16 19:31, Antonio Sanso wrote: > hi Sergey, > just my 2 cents > let’s start from a simple fact that encryption is not authentication. :) > And since then the access tokens are supposed to provide the source guarantee to the client ? Can you point to any text somewhere suggesting the clients must expect the access tokens be a set of JWT JWS signed claims ? (lets put the whole PoP aside for now...) > Now, if the claim sets of a JWS contains only not confidential information JWS is enough. > You are right - this is close to what I was asking about. My point is that given that a JWS-signed JWT content can be processed as easily as Base64 encoded data, the problems will start happening if a given OAuth2 server inadvertently puts more into this JWT container than it should... Thanks Sergey > See also inline > > > On Feb 23, 2016, at 6:15 PM, Sergey Beryozkin wrote: > >> Hi >> >> Some OAuth2 providers may return self-contained access tokens which are JWS Compact-encoded. >> I wonder is it really a good idea and would it not be better to only JWE-encrypt the tokens. I'm not sure JWS signing the claims is necessarily faster then only encrypting the claims, assuming the symmetric algorithms are used in both cases. > > JWE algorithms are all AEAD AFAIK so is not only symmetric encryption plus there is the content key "wrap algorithm”. > > regards > > antonio > >> >> For example, my colleague and myself, while dealing with the issue related to parsing an access token response from a 3rd party provider were able to easily check the content of the JWS-signed access_token by simply submitting an easily recognized JWS Compact-formatted value (3 dots) into our JWS reader - we did not have to worry about decrypting it neither the fact we did not validate the signature mattered. >> >> But access tokens are opaque values as far as the clients are concerned and if the introspection is needed then the introspection endpoint does exist for that purpose... >> >> Thanks, Sergey >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Tue Feb 23 15:09:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD861B370A for ; Tue, 23 Feb 2016 15:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utp_dh2qhJTi for ; Tue, 23 Feb 2016 15:09:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234DA1B3708 for ; Tue, 23 Feb 2016 15:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AzmCeQwLJY37zQonsIgc9Jp+q8y/euTftQXG8gFYg3c=; b=IOZIRmeZ5QuqUSkyqAFxbVtU713wKjUaXww/61NidZDihSFRF8ZWNa2bnF2eGR5NXlKwYKJHzpOcJplctDJ/YwzNJyaLmxTTMEmxT/MiojNhzpE0NfVD/U7KIN3gLVKI14ZGALtlafwnwxPhm93gHW1abVzeogq7N46YoTAiZ2s= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 23:08:47 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 23:08:47 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRa02wxzvG7zjtnEKFSlVIxrNR2p86RJxw Date: Tue, 23 Feb 2016 23:08:47 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> In-Reply-To: <56C7702B.2000401@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [131.107.159.103] x-ms-office365-filtering-correlation-id: 0680781d-f9a7-428c-8808-08d33ca648e2 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:/c/PTEJGivfj42HjwvH8NKX13AjNjqbmA/uVMf88b5FYxzNFNeH7aD0UO4ZIIYc7+WRy4xccJvJjXRoC3ak8Jm/LtanjGGjh4+a+e3iwc+gT6IFCymfTV5YiJC82CA5dB5y6PVhRBybjExH7XAHdlQ==; 24:BW8xZh4erX9whgocjx0KnM0DiVsxxurYKDBmXv+pYdAmLeCvA1ZOPYgDXS6SAaxi1+tMJv702Yh6JukQ0kK78pHPVqfVOPbpD+iq5xYLk8E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(72854002)(377454003)(87936001)(102836003)(3846002)(107886002)(11100500001)(76176999)(54356999)(189998001)(106116001)(5001960100002)(50986999)(76576001)(5004730100002)(66066001)(40100003)(5003600100002)(5008740100001)(586003)(1220700001)(5002640100001)(1096002)(2906002)(6116002)(3660700001)(74316001)(15975445007)(99286002)(3280700002)(92566002)(2900100001)(10400500002)(2950100001)(5005710100001)(2501003)(5001770100001)(8990500004)(33656002)(122556002)(10290500002)(86362001)(77096005)(10090500001)(19580405001)(19580395003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 23:08:47.2227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 23:09:12 -0000 SSB3b3VsZCBnbyB3aXRoIG9wdGlvbiBBLCBvcHRpb24gQiBpbnRyb2R1Y2VzIGNvbmNlcHRzL3N5 bnRheCB0aGF0IGNvbXBsaWNhdGVzIHRoZSBjdXJyZW50IE9hdXRoIG1vZGVsDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSAxOSwgMjAxNiAxMTo0MyBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbT0FV VEgtV0ddIEZpeGluZyB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWl4LVVwOiBDYWxsIGZvciBB ZG9wdGlvbg0KDQpFYXJseSBGZWJydWFyeSBJIHBvc3RlZCBhIG1haWwgdG8gdGhlIGxpc3QgdG8g bWFrZSBwcm9ncmVzcyBvbiB0aGUgc29sdXRpb24gdG8gdGhlIE9BdXRoIEF1dGhvcml6YXRpb24g U2VydmVyIE1peC1VcCBwcm9ibGVtIGRpc2NvdmVyZWQgbGF0ZSBsYXN0IHllYXIuDQoNCkhlcmUg aXMgbXkgbWFpbCBhYm91dCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWl4LVVwOg0KaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy Znd3dy5pZXRmLm9yZyUyZm1haWwtYXJjaGl2ZSUyZndlYiUyZm9hdXRoJTJmY3VycmVudCUyZm1z ZzE1MzM2Lmh0bWwmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M5YTVl ZGVhOWJjNzA0MjM5MDU5NTA4ZDMzOTY0ZDA3YyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSZzZGF0YT1EZ0lIdmFndzZZamFJRkRGbHhwNCUyYmhnUTdpdm1WJTJmMkZ1dXVp RHdWUVJ2OCUzZA0KDQpIZXJlIGlzIG15IG1haWwgdG8gdGhlIGxpc3QgdGhhdCB0cmllcyB0byBz dW1tYXJpemUgdGhlIGRpc2N1c3Npb24gc3RhdHVzIGFuZCBhc2tlZCBhIGZldyBxdWVzdGlvbnM6 DQpodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbC1hcmNoaXZlJTJmd2ViJTJmb2F1dGglMmZjdXJy ZW50JTJmbXNnMTU2OTcuaHRtbCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3YzlhNWVkZWE5YmM3MDQyMzkwNTk1MDhkMzM5NjRkMDdjJTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTFFdm9XbSUyYjdLMkJTZHZUR0NEeG16QmttZVNvM1dt MUdXYW1ndEc2ZmNOayUzZA0KDQpVbmZvcnR1bmF0ZWx5LCBteSBtYWlsIGRpZG4ndCBsZWFkIHRv IHRoZSBpbnRlbmRlZCBzdWNjZXNzLiBXaGlsZSB0aGVyZSB3YXMgc29tZSBmZWVkYmFjayBJIHdh c24ndCBnZXR0aW5nIHRoZSBkZXNpcmVkIHJlc3BvbnNlLg0KDQpJbiBvcmRlciB0byBtb3ZlIGZv cndhcmQgSSBiZWxpZXZlIHdlIG5lZWQgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IHRoYXQgc2Vy dmVzIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGZ1cnRoZXIgd29yayBpbiB0aGUgZ3JvdXAqLiBX ZSBoYXZlIHR3byBkb2N1bWVudHMgdGhhdCBwcm92aWRlIHNpbWlsYXIgZnVuY3Rpb25hbGl0eSBp biBhbiBhdHRlbXB0IHRvIHNvbHZlIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBNaXgtVXAgcHJv YmxlbS4NCg0KU28sIGhlcmUgaXMgdGhlIHF1ZXN0aW9uIGZvciB0aGUgZ3JvdXAuIFdoaWNoIGRv Y3VtZW50IGRvIHlvdSB3YW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgb24gdGhpcyB0 b3BpYzoNCg0KLS0gT3B0aW9uIEE6ICdPQXV0aCAyLjAgTWl4LVVwIE1pdGlnYXRpb24nIGJ5IE1p a2UgSm9uZXMgYW5kIEpvaG4gQnJhZGxleQ0KDQpMaW5rOg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9y ZyUyZmh0bWwlMmZkcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMSZkYXRhPTAx JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzlhNWVkZWE5YmM3MDQyMzkwNTk1MDhk MzM5NjRkMDdjJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWwy N0daUDklMmJTNUJndmxYeFNzZ0oyY1p2NjZtRmJScGRrUkVPNUwlMmJjanNRJTNkDQoNCi0tIE9w dGlvbiBCOiAnT0F1dGggUmVzcG9uc2UgTWV0YWRhdGEnIGJ5IE5hdCBTYWtpbXVyYSwgTm92IE1h dGFrZSBhbmQgU2FzY2hhIFByZWliaXNjaA0KDQpMaW5rOg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9y ZyUyZmh0bWwlMmZkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3JmRhdGE9MDElN2MwMSU3Y3Rv bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjOWE1ZWRlYTliYzcwNDIzOTA1OTUwOGQzMzk2NGQwN2Ml N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Qm82cUolMmI3SmNB cWZSQ3pBZkQ0RDRvRENPRiUyYmUyOVJGUkxleVd0SlA5bGclM2QNCg0KRGVhZGxpbmUgZm9yIGZl ZWRiYWNrIGlzIE1hcmNoLCA0dGguDQoNCkNpYW8NCkhhbm5lcyAmIERlcmVrDQoNClBTOiAoKikg UmVnYXJkbGVzcyBvZiB0aGUgc2VsZWN0ZWQgc29sdXRpb24gd2Ugd2lsbCBwcm92aWRlIHByb3Bl ciBhY2tub3dsZWRnZW1lbnQgZm9yIHRob3NlIHdobyBjb250cmlidXRlZCB0byB0aGUgd29yay4N Cg0K From nobody Tue Feb 23 15:17:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191201B3763 for ; Tue, 23 Feb 2016 15:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm-WmNncDK_s for ; Tue, 23 Feb 2016 15:17:19 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02261B3759 for ; Tue, 23 Feb 2016 15:17:18 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id c200so244564803wme.0 for ; Tue, 23 Feb 2016 15:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BY/vosOYFD3DwKjvq9RoyNSdyN+fSJTpg0R/RRnAI/U=; b=IUkVnUiIqQJjrju5hQGf2cirhGxw2jQyg3vdp3C0GrmKuhnjbb98+gijhYKn/+D9p8 5BZbjMezA5XDx8x/3c840CMS+7BtfP0xqowInCkKKIxfu2VYYGnuh9L/Pd91Jfxf5guv Yzcqg3bLrnHKcTTz5XPTu4uHwOeyiib+NNBUXX1tC/n8MSR22fCYixtEE84UgPFnbjQn bGi1xVas/Mu/1Qo04BYmx5fKx42qk7TmQ22pgDiRfiIz1zy4sqygK1v+ZJf7bUPxz1FN lKjvhZyEj5J3WhNFKrMaoV9xGl8W3GqmTI+RtJOZQek5HdQ+NKRqGHJrlPvipevwKZ13 +6Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BY/vosOYFD3DwKjvq9RoyNSdyN+fSJTpg0R/RRnAI/U=; b=aCm8as4iM8kbJTyDY1I4NqbhgkQsqHkLBMN9aMbjKxt6qh4QRdnMi6grq99X/jd3JH qVeSQrSqy5X16WmooR11AHIrny5WiHRqTcJ0A4D0mipNTBeS5TfSVDcZmD9VyYbyKg18 5L/WX+qW0a9VytRou6DvoHvTXiAbCkBS00WgMWon7/t+is+CFdI3FVSeYcWDcG1way+k 8ImgKz+f8OoyOf4dPBgZZCvvvKttd7Apsk1cYjqgZxDAKMzbyD0J2zUjfvF7GA70mkgD M/davYw/1uGsQiTyFCJe62pIV+5Is6kwx/s9a2veb1suYXj0h7kCKG8RjgvWoLBvJXFq ajwA== X-Gm-Message-State: AG10YORTBoavB2OrQI2RH5wgH/F/mOUcscPE/r0E3QEn5Dt/X37xLTBTnbFNBf0XURiOwg== X-Received: by 10.28.127.5 with SMTP id a5mr21984685wmd.32.1456269437063; Tue, 23 Feb 2016 15:17:17 -0800 (PST) Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id cb2sm117845wjc.16.2016.02.23.15.17.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Feb 2016 15:17:15 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_A86BEBCF-DB8F-4962-AB37-96C4E2AF87DA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 24 Feb 2016 00:17:12 +0100 Message-Id: <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> To: Roland Hedberg X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 23:17:23 -0000 --Apple-Mail=_A86BEBCF-DB8F-4962-AB37-96C4E2AF87DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The idea of including the state in the PKCE calculation was one I think = Hans brought up at the meeting in Darmstadt. I think we discounted it as not solving the problem because the attacker = could manipulate the code_challenge. As and example the attacker receives the request and changes the = code_challenge to one it makes up based on the state from a second = request made to the client in it=E2=80=99s browser.=20 The attacker can replay the token to the client with the state that will = validate the code_callenge or use the token directly at the token = endpoint to get a access token as it would know both the client secret = and code verifier. We moved on to look at another way to validate state by passing it to = the token endpoint for validation to stop the cut and paste attack. In thinking again about William and Nat=E2=80=99s question about why not = PKCE, I looked at the idea of using PKCE again. The problem with using PKCE as it is now is that we made the assumption = that the attacker could not modify the request. That got me trying to think of a way to: a) stop the attacker from modifying the request (signed request, = probably too complicated to be generally deployed) b) allow the client to detect if code_challenge has been modified and = abort of the request was compromise. I realized that you could simply echo back the code_challenge from the = authorization endpoint and that would allow the client to know if = code_challenge had been altered in the request, assuming the attacker = can=E2=80=99t modify the response from the legitimate AS. So if we add that step we now have a client where code_challenge can=E2=80= =99t be altered. =20 That in it selfs stops the cut and pate attack. It however still allows = an attacker to use the code it receives along with the the code_verifier = and client secret to get a AT and RT from the legitimate token endpoint. So that is not enough Including state in the hash calculation helps = against the cut and paste attack but we fixed that by returning = code_challenge. That leaves the other things we were talking about returning from the = authorization endpoint. If we include token_endpoint URI in the hash then any token the client = requests thinking it is for the attackers token endpoint won=E2=80=99t = generate the same code_challenge as the AS would based on it=E2=80=99s = token endpoint. The attacker would know the code_challenge and the = real token endpoint URI but would have to generate a collision in the = lifetime of code to use the code. This would not be possible based on = the PKCE analysis. Returning the code_challenge and including the token_endpoint URI in the = hash is the minimum needed for the code flow to stop both cut and paste = as well as protect the code from being used if stolen via a confused = client attack. It doesn=E2=80=99t stop the theft just the use of the = token. So it is mitigating the issue a different way from A and B that = are trying to stop the attacker from getting the code. Given the technique I realized it would be simple enough to also include = some other paramaters in the hash 1) The authorization endpoint in the hash causing it not to validate if = the client has been given a bad authorization endpoint so the client can = modify the request. =20 2) The client_id so that it cannot be tampered with in the request. 3) The state This is tied to the browser instance for XSRF protection. = Including this means it cannot be changed and is another protection = against cut and paste. Including all 4 in the hash may be overkill as they overlap in = protection. I however think that not integrity protecting one of the = values might bite us in the future. We could go farther and include scopes or the whole request but that = gets more complicated than it is worth. We do have a option for request = signing already. So we almost had this at the Darmstadt meeting but it slipped away. This is not stoping the attack it is protecting code. =20 I should point out that some of the attacks like man in the middling = registration can still compromise the client secret, making it possible = for an attacker to impersonate a client. Nat=E2=80=99s option B doesn=E2=80=99t have a solution to that ether as = far as I can tell. I think the only option for that is to have a logical identifier for the = AS and some sort of discovery check at registration to be certain that = you are using the correct registration location. Option A plus discovery works for that and mitigates confused client but = not cut and paste. We still have a problem with AT leaking. I think that needs to be = dealt with separately.=20 Access tokens should have a audience (by value or by introspection) the = client needs to tell the AS what resource it want s to use the token at = and have that included as the audience or the request rejected because = it is an invalid audience. That should happen at the token endpoint for code. For implicit it would need to be at the authoriation endpoint and the = audience would need to be echoed back to prevent tampering. The AT can also be protected by POP so I think that code and AT should = be kept separate issues. John B. > On Feb 23, 2016, at 9:59 PM, Roland Hedberg = wrote: >=20 > In line ! >=20 >> 22 feb 2016 kl. 05:08 skrev John Bradley : >>=20 >>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura = wrote: >>>=20 >>> The risk impact of [case2] is more OAuth specific. The token is = stolen as the token is going to be sent to a rogue resource, and the = resource can use that to obtain the resource that was supposed to be = only available to the proper client. >>>=20 >>> The risk impact of [case3] is the most grave among these three. Now = the attacker can create his own client that impersonates the compromised = client. >>>=20 >>> OAuth-mix-up >>> --------------------------- >>> OAuth-mix-up draft gives one way of addressing [case2] by = introducing a new concept of =E2=80=9Cissuer=E2=80=9D and = =E2=80=9Cdiscovery=E2=80=9D to RFC6749. It also returns client_id and = verifies it in 4.2, but if the BadAS has assigned a same client_id to = the client, it does not help. >>=20 >> Client_id are not guaranteed to be unique. They need to be name = spaced by the AS. In OAuth currently we have no name for the AS this = makes that difficult, the client can use the authorization endpoint URI, = but that logic may well break in multi tenant situations. Having a = clear issuer string makes it easier for the client. >=20 > I stumbled over exactly this point when I made my implementation = follow the Mix-Up draft. > If not discovery is involved I think an AS has to have a name which is = different from the endpoint URIs. >=20 >>> One of the issue with this approach is that the central notion of = =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the = authorization server that the client received when it registered at the = authorization server=E2=80=9D, but in most existing pure OAuth cases, = there is no such thing, so you cannot compare. This means that you would = have to re-register, and if you are doing that, the per-AS redirect_uri = seems to be a much simpler solution. >>=20 >> The client developers I have talked to really hate per AS redirect = URI as being too awkward for deployments. >=20 > I on the other hand found it quite easy to do per AS redirect URIs, so = it might well be implementation > dependent rather then contextual. >=20 >>>=20 >>> Per AS Redirect URI >>> -------------------------------- >>> This does not involve wire protocol changes. It just adds = requirements on the redirect uri. This by far is the simplest solution = for [case2] (and [case1]), IMHO. >>>=20 >>> Again, it is not a general framework for finding out tainted = communication, so it may have other holes. >>=20 >> This is probably the hardest for the client developer and for the = deployer. Yes it is simplest from a spec point of view. >> We need more developer feedback on this. >=20 > As I said above I found this quite simple to implement. >=20 >>> (Extended) PKCE >>> --------------------------------- >>> To begin with, it works only with code flow. There has to be = something else to deal with implicit flow. >>>=20 >>> PKCE binds the authorization request/response to the token request. >>> If used with a confidential client, it seems to mitigate the = vulnerability. >>> John points out that it is not the case. I must be missing something = here=E2=80=A6 but my logic goes like: >>>=20 >>>=20 >>> 1. The good client creates code_challenge-v and = code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + = code_challenge-v + state to the BadAS Authz EP. >>> 2. BadAS as a client prepares a code_verifier-b and = code_challenge-b=3DS256(code_verifer-b). >>> 3. BadAS redirects to GoodAS with the client_id-v + = code_challenge-b + state-v. >>> 4. GoodAS stores the code_challenge-b. >>> 5. GoodAS returns code-v + state-v to the client=E2=80=99s = redirect uri. >>> 6. The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished. >>>=20 >>> Now the attacker tries to use the code-v and code_verifier-v. >>>=20 >>> ### Case A: >>> 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he = does not have client secret for the good client, so it fails. >>>=20 >>> ### Case B: >>> 8. The BadAS as a client sends client_id-b + code-v + = code_verifier-b + secret-b etc. to GoodAS. >>> 9. GoodAS verifies the code_verifier-b is associated with = code-v, but that code-v is not associated with client_id-b, so the token = request fails. >>>=20 >>> ### Case C: cut-n-paste >>> 10. The attacker launches cut-n-paste attack by replacing the = code-b with code-v. >>> 11. The verifiers does not match, so fails. >>>=20 >>> Please let me know what I am missing. >>=20 >> In a step 0 the attacker has the good client create another request = in the attackers user agent to get state-0 and code_challange-0 >>=20 >> Step 2 is not required. >> Step 3 Bad AS redirects to good AS with client_id_v + state-v + = code_challenge-0 >> Step 4 GoodAS stores code_challenge-0 >> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri >> Step 6 The client finds the AS from the state and sends code-v + = code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and = code_verifer-v is phished. >>=20 >> Case C1 : cut and paste >> 10. The attacker launches cut-n-paste attack by inserting code-v = into a response using state-0 >> 11. The client sends code-v and based on state-0 it sends = code_verifyer-0 to the good AS token endpoint. >> 12. The GoodAS verifies that code-verifyer-0 is correct for = code_challange-0 that it bound to code in step 4 >> 13. The GoodAS receives RT + AT. >> 14. The attacker has now used the client to bind the users resource = to it=E2=80=99s account and is transferring money or looking at your = data. >>=20 >> This could be 3rd party financial app like Mint as an example or = photos or any other PII that could then be used to escalate identity = theft. >>=20 >> This variation of the attack combining cut and paste with confused = client was not mentioned in the research papers. >>=20 >> I found it looking to see if PKCE could be used to mitigate the = confused client attack. >>=20 >> As I mentioned in a response to William, while the current PKCE = Challenge methods only make the attack harder by forcing the attacker to = get the client to make a step 0 request to get a code_challenge to use = in the request, we could define a new challenge method that would be = effective. >>=20 >> That would remove the need to have a separate mechanism to prevent = cut and paste. >>=20 >> The problem is that the PKCE challenge is independent of state so = becomes vulnerable to the confused client. >>=20 >> What we would need to do is include state in the challenge so that if = the AS receives mismatched state and code_challange in step 3 the = verification of code verifier will fail. Effectively combining the cut = and paste mitigation with PKCE. >>=20 >> I haven=E2=80=99t had time to write this up, but if the = code_challenge =3D=3D SHA256 (SHA256(state) || token_endpoint URI || = Authorization_endpoint URI || client_id || code-veriyer) , then the = attacker could not change state, client_id, or token_endpoint = independently of code_challenge. (note I am using a hash of state to = make storage size deterministic for the AS on the grounds that the = client already needs to be able to do the hash) (Some attacks change = the client_id in the request so I am including it in the hash) >>=20 >> This is slightly more complicated than than S256, but not that much. = I wish I had thought of this when we were doing PKCE. Hit me with the = stupid stick, my fault. >>=20 >> I don=E2=80=99t know if it stops all the confused client attacks = though. >>=20 >> If the client is confidential then it gives up it=E2=80=99s client = secret assuming compromised registration, so we can=E2=80=99t really = count on that for symmetric client authentication. >>=20 >> By including the token endpoint in the comparison if the client is = sending the code to the attacker the client will use a different token = endpoint_uri in to calculate the code_challenge than the GoodAS will use = to verify it. This would stop both cut and paste as well as stopping = the attacker from using the code if they get it. The attacker can=E2=80=99= t get Secret for state-0, so it can=E2=80=99t create code_challenge that = would be valid. >>=20 >> This stops the registration attack where the client gets a bad AS = discovery endpoint that has all the Good AS info including dynamic = registration endpoint but the bad AS token endpoint. The bad AS would = get the token, client_secret and code_verier, but will fail pkce = verification because the token endpoint will be wrong. >>=20 >> The attack where the client registers with the good AS but with bad = token endpoint and Authorization endpoint gives the attacker the ability = to change the code_challenge that the Good AS is going to see. It = would need to make a new challenge using state and the GoodAS token = endpoint and it=E2=80=99s client_id. >> To do that it needs the code_verifier to use to calculate the hash to = use as the code_challenge value. As long as the client is not tricked = into accepting a replay of the authentication response we should be = safe. The client would need to do replay protection on the = code_verifier values before it makes a request to the token endpoint. >>=20 >> The BadAS could however make up a new code_challenge and = code_verifier and use that in the request. For this one the AS would = need to do pull discovery on the client to get a key, or the AS needs to = return something in the response. This attack can completely proxy all = the endpoints as far as the client is concerned and is taking advantage = of the AS saying you are granting permission to site X based on the = redirect URI. >>=20 >> I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a = client from being used as a redirector back to the attacker unless you = also returned the code_challenge in the response from the authorization = endpoint. >>=20 >> Hypothetically if we returned code_challenge in the response from the = authorization endpoint and have a new PKCE challenge method we might = find it covers all of the attacks. >>=20 >> We would need to put some serious analysis into this to see if it = really covers all the attacks. >>=20 >> It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D = response_type or steeling the access token by impersonating the RS. >>=20 >> I think the correct way to stop the problem with access tokens is by = audience restricting them. >> To do that the client needs to provide an audience in it=E2=80=99s = request and the AS needs to include that in the AT. >>=20 >> I included the Authorization_endpoint URI in the hash to detect if = the auth request may have been tampered with to change the audience for = the AT. >>=20 >> For implicit we could have a version of PKCE where the AS returns a = parameter with S256( client_id || authorization_endpoint URI || resource = endpoint URI) to verify the request was not tampered with, and that = would allow the AT to be properly audience restricted. >>=20 >>=20 >> This would be a completely new approach not involving discovery, = logical names for AS, or link relations. >>=20 >> Effectively this code_challenge method becomes a signature over parts = of the request and the implicit audience of the token_endpoint URI. >>=20 >> People keep asking why PKCE doesn=E2=80=99t stop these attacks, and = it won=E2=80=99t with the current PKCE methods, however a new method = along the lines I sketched out may let it work, or I could be completely = wrong. >=20 > Once you have written down something more definite I promise to = implement it promptly such that we can do interop > testing early in the process. >=20 > Before John brought up this new PKCE mode I was on the Option A side = of the fence now I=E2=80=99d like to see more > of this PKCE idea before committing to one or the other. >=20 > =E2=80=94 Roland >=20 > =E2=80=9DEverybody should be quiet near a little stream and listen." > =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >=20 --Apple-Mail=_A86BEBCF-DB8F-4962-AB37-96C4E2AF87DA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMjMyMzE3MTNaMCMGCSqGSIb3DQEJBDEWBBQU+XZFwioGGNOveHbcgiSm 3N8i+zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAspJDNZ8ww5EsnmhCHFkKJm61vyWxWbckR4W8JOys/GDXy634OlvSJ +ZZ3EJq6TmtMAext79Aw+aUghFe7tZ3OIBYrmkzk4jDBtmqIHvOSBf6+GWjCJsv7p9b+VYhX4dcO iGWmE9KtOc+uFGf4VWqAlmdMYYNXSOBhSj1JoE40B0l7E3Ez0mTGCbYOc8bUlXZX7x+xe0lYJ74P yDkspL4xVcMwxvnKs30wlT29JPq3050gfBvrOak+hcoz6kYezrbbiRLK3mnC2Zns0DkuYsw0phL+ 0aD1ESOla/LUPl69ELWzBE0K+yuYEO/gd8sKBxhO7RlR3ISja4YhRtzoMSc9AAAAAAAA --Apple-Mail=_A86BEBCF-DB8F-4962-AB37-96C4E2AF87DA-- From nobody Tue Feb 23 15:23:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D51B379D for ; Tue, 23 Feb 2016 15:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G3_1DIF646h for ; Tue, 23 Feb 2016 15:23:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A881B379C for ; Tue, 23 Feb 2016 15:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DTuhoTrV+d9+9SE+ZmwjSRcOfJbGdqyQKt8D42/W3Dc=; b=Gc0pQq3j3oNbCCPujoWMRr6E0sKbIolUQgxpgx4kwgNkLTPq5tP4IGe6G20EKY9HOhPra7vbHzc7flrK6lO09SURAsa0tkEiUVA5YlK93fFV5AcOp9D1ucz/7jvvtQGC51ciuMUqBnNqlFPZE4TRw/cmL1E00HR43ezDLUdPw5E= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 23:23:42 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 23:23:42 +0000 From: Anthony Nadalin To: John Bradley , Roland Hedberg Thread-Topic: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption Thread-Index: AQHRa02wxzvG7zjtnEKFSlVIxrNR2p8zzueAgAAF1ACAAI80gIAAPJQAgAA52wCAAuNGAIAAP0KAgAImnoCAACaGAIAAATbg Date: Tue, 23 Feb 2016 23:23:42 +0000 Message-ID: References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> In-Reply-To: <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [131.107.159.103] x-ms-office365-filtering-correlation-id: e15169a6-5ce1-470d-18c3-08d33ca85ea5 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:UvlGrfzx25PYUM5SPXPpN116frhfyQmYdzdH5gQUCb5/sPWr2yHvQ5td+GrmvgjCS0QpK8BjOgb3haurARaJPNokiH2vvRomFe61JIC33vN5hx7IFzTBPTZzZh2WCDb+sy6UReEPiVEvbPj7RGABvw==; 24:9u7b8oDyP8L1FzOdf70YlHraN0skeHGVqkxHpG0rQlkz0EkL2vvDhhiwxk5YWbF589v/PAlxi4PpmG4iunqJLfre9slNZVITbGcZBQoX8Qk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51444003)(13464003)(377454003)(3846002)(87936001)(102836003)(50986999)(189998001)(54356999)(11100500001)(76176999)(5001960100002)(106116001)(93886004)(66066001)(76576001)(5008740100001)(5002640100001)(5003600100002)(1096002)(2906002)(1220700001)(4326007)(586003)(5004730100002)(74316001)(3660700001)(3280700002)(99286002)(6116002)(92566002)(86362001)(122556002)(2900100001)(2950100001)(10400500002)(5005710100001)(33656002)(1600100001)(8990500004)(77096005)(10090500001)(19580395003)(19580405001)(5001770100001)(40100003)(10290500002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 23:23:42.5515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 23:23:50 -0000 SSBoZWFyIHRoYXQgbWFueSBmb2xrcyBkb24ndCB3YW50IHRvIGFkZCBhIG1hbmRhdG9yeSBjcnlw dG8gb3BlcmF0aW9uIG9uIHRoZSBjbGllbnQgc2lkZSA6LSgNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjMsIDIwMTYg MzoxNyBQTQ0KVG86IFJvbGFuZCBIZWRiZXJnIDxyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+DQpDYzog PG9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBGaXhpbmcgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIE1peC1VcDogQ2FsbCBmb3IgQWRvcHRp b24NCg0KVGhlIGlkZWEgb2YgaW5jbHVkaW5nIHRoZSBzdGF0ZSBpbiB0aGUgUEtDRSBjYWxjdWxh dGlvbiB3YXMgb25lIEkgdGhpbmsgSGFucyBicm91Z2h0IHVwIGF0IHRoZSBtZWV0aW5nIGluIERh cm1zdGFkdC4NCg0KSSB0aGluayB3ZSBkaXNjb3VudGVkIGl0IGFzIG5vdCBzb2x2aW5nIHRoZSBw cm9ibGVtIGJlY2F1c2UgdGhlIGF0dGFja2VyIGNvdWxkIG1hbmlwdWxhdGUgdGhlIGNvZGVfY2hh bGxlbmdlLg0KDQpBcyBhbmQgZXhhbXBsZSB0aGUgYXR0YWNrZXIgcmVjZWl2ZXMgdGhlIHJlcXVl c3QgYW5kIGNoYW5nZXMgdGhlIGNvZGVfY2hhbGxlbmdlIHRvIG9uZSBpdCBtYWtlcyB1cCBiYXNl ZCBvbiB0aGUgc3RhdGUgZnJvbSBhIHNlY29uZCByZXF1ZXN0IG1hZGUgdG8gdGhlIGNsaWVudCBp biBpdOKAmXMgYnJvd3Nlci4gDQoNClRoZSBhdHRhY2tlciBjYW4gcmVwbGF5IHRoZSB0b2tlbiB0 byB0aGUgY2xpZW50IHdpdGggdGhlIHN0YXRlIHRoYXQgd2lsbCB2YWxpZGF0ZSB0aGUgY29kZV9j YWxsZW5nZSBvciB1c2UgdGhlIHRva2VuIGRpcmVjdGx5IGF0IHRoZSB0b2tlbiBlbmRwb2ludCB0 byBnZXQgYSBhY2Nlc3MgdG9rZW4gYXMgaXQgd291bGQga25vdyBib3RoIHRoZSBjbGllbnQgc2Vj cmV0IGFuZCBjb2RlIHZlcmlmaWVyLg0KDQpXZSBtb3ZlZCBvbiB0byBsb29rIGF0IGFub3RoZXIg d2F5IHRvIHZhbGlkYXRlIHN0YXRlIGJ5IHBhc3NpbmcgaXQgdG8gdGhlIHRva2VuIGVuZHBvaW50 IGZvciB2YWxpZGF0aW9uIHRvIHN0b3AgdGhlIGN1dCBhbmQgcGFzdGUgYXR0YWNrLg0KDQpJbiB0 aGlua2luZyBhZ2FpbiBhYm91dCBXaWxsaWFtIGFuZCBOYXTigJlzIHF1ZXN0aW9uIGFib3V0IHdo eSBub3QgUEtDRSwgSSBsb29rZWQgYXQgdGhlIGlkZWEgb2YgdXNpbmcgUEtDRSBhZ2Fpbi4NCg0K VGhlIHByb2JsZW0gd2l0aCB1c2luZyBQS0NFIGFzIGl0IGlzIG5vdyBpcyB0aGF0IHdlIG1hZGUg dGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgYXR0YWNrZXIgY291bGQgbm90IG1vZGlmeSB0aGUgcmVx dWVzdC4NCg0KVGhhdCBnb3QgbWUgdHJ5aW5nIHRvIHRoaW5rIG9mIGEgd2F5IHRvOg0KIGEpIHN0 b3AgdGhlIGF0dGFja2VyIGZyb20gbW9kaWZ5aW5nIHRoZSByZXF1ZXN0IChzaWduZWQgcmVxdWVz dCwgcHJvYmFibHkgdG9vIGNvbXBsaWNhdGVkIHRvIGJlIGdlbmVyYWxseSBkZXBsb3llZCkNCiBi KSBhbGxvdyB0aGUgY2xpZW50IHRvIGRldGVjdCBpZiBjb2RlX2NoYWxsZW5nZSBoYXMgYmVlbiBt b2RpZmllZCBhbmQgYWJvcnQgb2YgdGhlIHJlcXVlc3Qgd2FzIGNvbXByb21pc2UuDQoNCkkgcmVh bGl6ZWQgdGhhdCB5b3UgY291bGQgc2ltcGx5IGVjaG8gYmFjayB0aGUgY29kZV9jaGFsbGVuZ2Ug ZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhbmQgdGhhdCB3b3VsZCBhbGxvdyB0aGUg Y2xpZW50IHRvIGtub3cgaWYgY29kZV9jaGFsbGVuZ2UgaGFkIGJlZW4gYWx0ZXJlZCBpbiB0aGUg cmVxdWVzdCwgYXNzdW1pbmcgdGhlIGF0dGFja2VyIGNhbuKAmXQgbW9kaWZ5IHRoZSByZXNwb25z ZSBmcm9tIHRoZSBsZWdpdGltYXRlIEFTLg0KDQpTbyBpZiB3ZSBhZGQgdGhhdCBzdGVwIHdlIG5v dyBoYXZlIGEgY2xpZW50IHdoZXJlIGNvZGVfY2hhbGxlbmdlIGNhbuKAmXQgYmUgYWx0ZXJlZC4g IA0KDQpUaGF0IGluIGl0IHNlbGZzIHN0b3BzIHRoZSBjdXQgYW5kIHBhdGUgYXR0YWNrLiAgSXQg aG93ZXZlciBzdGlsbCBhbGxvd3MgYW4gYXR0YWNrZXIgdG8gdXNlIHRoZSBjb2RlIGl0IHJlY2Vp dmVzIGFsb25nIHdpdGggdGhlIHRoZSBjb2RlX3ZlcmlmaWVyIGFuZCBjbGllbnQgc2VjcmV0IHRv IGdldCBhIEFUIGFuZCBSVCBmcm9tIHRoZSBsZWdpdGltYXRlIHRva2VuIGVuZHBvaW50Lg0KDQpT byB0aGF0IGlzIG5vdCBlbm91Z2ggSW5jbHVkaW5nIHN0YXRlIGluIHRoZSBoYXNoIGNhbGN1bGF0 aW9uIGhlbHBzIGFnYWluc3QgdGhlIGN1dCBhbmQgcGFzdGUgYXR0YWNrIGJ1dCB3ZSBmaXhlZCB0 aGF0IGJ5IHJldHVybmluZyBjb2RlX2NoYWxsZW5nZS4NCg0KVGhhdCBsZWF2ZXMgdGhlIG90aGVy IHRoaW5ncyB3ZSB3ZXJlIHRhbGtpbmcgYWJvdXQgcmV0dXJuaW5nIGZyb20gdGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQuDQoNCklmIHdlIGluY2x1ZGUgdG9rZW5fZW5kcG9pbnQgVVJJIGluIHRo ZSBoYXNoIHRoZW4gYW55IHRva2VuIHRoZSBjbGllbnQgcmVxdWVzdHMgdGhpbmtpbmcgaXQgaXMg Zm9yIHRoZSBhdHRhY2tlcnMgdG9rZW4gZW5kcG9pbnQgd29u4oCZdCBnZW5lcmF0ZSB0aGUgc2Ft ZSBjb2RlX2NoYWxsZW5nZSBhcyB0aGUgQVMgd291bGQgYmFzZWQgb24gaXTigJlzIHRva2VuIGVu ZHBvaW50LiAgIFRoZSBhdHRhY2tlciB3b3VsZCBrbm93IHRoZSBjb2RlX2NoYWxsZW5nZSBhbmQg dGhlIHJlYWwgdG9rZW4gZW5kcG9pbnQgVVJJIGJ1dCB3b3VsZCBoYXZlIHRvIGdlbmVyYXRlIGEg Y29sbGlzaW9uIGluIHRoZSBsaWZldGltZSBvZiBjb2RlIHRvIHVzZSB0aGUgY29kZS4gICBUaGlz IHdvdWxkIG5vdCBiZSBwb3NzaWJsZSBiYXNlZCBvbiB0aGUgUEtDRSBhbmFseXNpcy4NCg0KUmV0 dXJuaW5nIHRoZSBjb2RlX2NoYWxsZW5nZSBhbmQgaW5jbHVkaW5nIHRoZSB0b2tlbl9lbmRwb2lu dCBVUkkgaW4gdGhlIGhhc2ggaXMgdGhlIG1pbmltdW0gbmVlZGVkIGZvciB0aGUgY29kZSBmbG93 IHRvIHN0b3AgYm90aCBjdXQgYW5kIHBhc3RlIGFzIHdlbGwgIGFzIHByb3RlY3QgdGhlIGNvZGUg ZnJvbSBiZWluZyB1c2VkIGlmIHN0b2xlbiB2aWEgYSBjb25mdXNlZCBjbGllbnQgYXR0YWNrLiAg IEl0IGRvZXNu4oCZdCBzdG9wIHRoZSB0aGVmdCBqdXN0IHRoZSB1c2Ugb2YgdGhlIHRva2VuLiAg U28gaXQgaXMgbWl0aWdhdGluZyB0aGUgaXNzdWUgYSBkaWZmZXJlbnQgd2F5IGZyb20gQSBhbmQg QiB0aGF0IGFyZSB0cnlpbmcgdG8gc3RvcCB0aGUgYXR0YWNrZXIgZnJvbSBnZXR0aW5nIHRoZSBj b2RlLg0KDQpHaXZlbiB0aGUgdGVjaG5pcXVlIEkgcmVhbGl6ZWQgaXQgd291bGQgYmUgc2ltcGxl IGVub3VnaCB0byBhbHNvIGluY2x1ZGUgc29tZSBvdGhlciBwYXJhbWF0ZXJzIGluIHRoZSBoYXNo DQoxKSBUaGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBpbiB0aGUgaGFzaCBjYXVzaW5nIGl0IG5v dCB0byB2YWxpZGF0ZSBpZiB0aGUgY2xpZW50IGhhcyBiZWVuIGdpdmVuIGEgYmFkIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgc28gdGhlIGNsaWVudCBjYW4gbW9kaWZ5IHRoZSByZXF1ZXN0LiAgDQoy KSBUaGUgY2xpZW50X2lkIHNvIHRoYXQgaXQgY2Fubm90IGJlIHRhbXBlcmVkIHdpdGggaW4gdGhl IHJlcXVlc3QuDQozKSBUaGUgc3RhdGUgIFRoaXMgaXMgdGllZCB0byB0aGUgYnJvd3NlciBpbnN0 YW5jZSBmb3IgWFNSRiBwcm90ZWN0aW9uLiAgSW5jbHVkaW5nIHRoaXMgbWVhbnMgaXQgY2Fubm90 IGJlIGNoYW5nZWQgYW5kIGlzIGFub3RoZXIgcHJvdGVjdGlvbiBhZ2FpbnN0IGN1dCBhbmQgcGFz dGUuDQoNCkluY2x1ZGluZyBhbGwgNCBpbiB0aGUgaGFzaCBtYXkgYmUgb3ZlcmtpbGwgYXMgdGhl eSBvdmVybGFwIGluIHByb3RlY3Rpb24uICBJIGhvd2V2ZXIgdGhpbmsgdGhhdCBub3QgaW50ZWdy aXR5IHByb3RlY3Rpbmcgb25lIG9mIHRoZSB2YWx1ZXMgbWlnaHQgYml0ZSB1cyBpbiB0aGUgZnV0 dXJlLg0KDQpXZSBjb3VsZCBnbyBmYXJ0aGVyIGFuZCBpbmNsdWRlIHNjb3BlcyBvciB0aGUgd2hv bGUgcmVxdWVzdCBidXQgdGhhdCBnZXRzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBpdCBpcyB3b3J0 aC4gIFdlIGRvIGhhdmUgYSBvcHRpb24gZm9yIHJlcXVlc3Qgc2lnbmluZyBhbHJlYWR5Lg0KDQpT byB3ZSBhbG1vc3QgaGFkIHRoaXMgYXQgdGhlIERhcm1zdGFkdCBtZWV0aW5nIGJ1dCBpdCBzbGlw cGVkIGF3YXkuDQoNClRoaXMgaXMgbm90IHN0b3BpbmcgdGhlIGF0dGFjayBpdCBpcyBwcm90ZWN0 aW5nIGNvZGUuICAgDQoNCkkgc2hvdWxkIHBvaW50IG91dCB0aGF0IHNvbWUgb2YgdGhlIGF0dGFj a3MgbGlrZSBtYW4gaW4gdGhlIG1pZGRsaW5nIHJlZ2lzdHJhdGlvbiBjYW4gc3RpbGwgY29tcHJv bWlzZSB0aGUgY2xpZW50IHNlY3JldCwgbWFraW5nIGl0IHBvc3NpYmxlIGZvciBhbiBhdHRhY2tl ciB0byBpbXBlcnNvbmF0ZSBhIGNsaWVudC4NCg0KTmF04oCZcyBvcHRpb24gQiBkb2VzbuKAmXQg aGF2ZSBhIHNvbHV0aW9uIHRvIHRoYXQgZXRoZXIgYXMgZmFyIGFzIEkgY2FuIHRlbGwuDQoNCkkg dGhpbmsgdGhlIG9ubHkgb3B0aW9uIGZvciB0aGF0IGlzIHRvIGhhdmUgYSBsb2dpY2FsIGlkZW50 aWZpZXIgZm9yIHRoZSBBUyBhbmQgc29tZSBzb3J0IG9mIGRpc2NvdmVyeSBjaGVjayBhdCByZWdp c3RyYXRpb24gdG8gYmUgY2VydGFpbiB0aGF0IHlvdSBhcmUgdXNpbmcgdGhlIGNvcnJlY3QgcmVn aXN0cmF0aW9uIGxvY2F0aW9uLg0KDQpPcHRpb24gQSBwbHVzIGRpc2NvdmVyeSB3b3JrcyBmb3Ig dGhhdCBhbmQgbWl0aWdhdGVzIGNvbmZ1c2VkIGNsaWVudCBidXQgbm90IGN1dCBhbmQgcGFzdGUu DQoNCldlIHN0aWxsIGhhdmUgYSBwcm9ibGVtIHdpdGggQVQgbGVha2luZy4gICBJIHRoaW5rIHRo YXQgbmVlZHMgdG8gYmUgZGVhbHQgd2l0aCBzZXBhcmF0ZWx5LiANCkFjY2VzcyB0b2tlbnMgc2hv dWxkIGhhdmUgYSBhdWRpZW5jZSAoYnkgdmFsdWUgb3IgYnkgaW50cm9zcGVjdGlvbikgdGhlIGNs aWVudCBuZWVkcyB0byB0ZWxsIHRoZSBBUyB3aGF0IHJlc291cmNlIGl0IHdhbnQgcyB0byB1c2Ug dGhlIHRva2VuIGF0IGFuZCBoYXZlIHRoYXQgaW5jbHVkZWQgYXMgdGhlIGF1ZGllbmNlIG9yIHRo ZSByZXF1ZXN0IHJlamVjdGVkIGJlY2F1c2UgaXQgaXMgYW4gaW52YWxpZCBhdWRpZW5jZS4NCg0K VGhhdCBzaG91bGQgaGFwcGVuIGF0IHRoZSB0b2tlbiBlbmRwb2ludCBmb3IgY29kZS4NCkZvciBp bXBsaWNpdCBpdCB3b3VsZCBuZWVkIHRvIGJlIGF0IHRoZSBhdXRob3JpYXRpb24gZW5kcG9pbnQg YW5kIHRoZSBhdWRpZW5jZSB3b3VsZCBuZWVkIHRvIGJlIGVjaG9lZCBiYWNrIHRvIHByZXZlbnQg dGFtcGVyaW5nLg0KDQpUaGUgQVQgY2FuIGFsc28gYmUgcHJvdGVjdGVkIGJ5IFBPUCBzbyBJIHRo aW5rIHRoYXQgY29kZSBhbmQgQVQgc2hvdWxkIGJlIGtlcHQgc2VwYXJhdGUgaXNzdWVzLg0KDQpK b2huIEIuDQoNCg0KPiBPbiBGZWIgMjMsIDIwMTYsIGF0IDk6NTkgUE0sIFJvbGFuZCBIZWRiZXJn IDxyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+IHdyb3RlOg0KPiANCj4gSW4gbGluZSAhDQo+IA0KPj4g MjIgZmViIDIwMTYga2wuIDA1OjA4IHNrcmV2IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5j b20+Og0KPj4gDQo+Pj4gT24gRmViIDIyLCAyMDE2LCBhdCA5OjIyIEFNLCBOYXQgU2FraW11cmEg PG4tc2FraW11cmFAbnJpLmNvLmpwPiB3cm90ZToNCj4+PiANCj4+PiBUaGUgcmlzayBpbXBhY3Qg b2YgW2Nhc2UyXSBpcyBtb3JlIE9BdXRoIHNwZWNpZmljLiBUaGUgdG9rZW4gaXMgc3RvbGVuIGFz IHRoZSB0b2tlbiBpcyBnb2luZyB0byBiZSBzZW50IHRvIGEgcm9ndWUgcmVzb3VyY2UsIGFuZCB0 aGUgcmVzb3VyY2UgY2FuIHVzZSB0aGF0IHRvIG9idGFpbiB0aGUgcmVzb3VyY2UgdGhhdCB3YXMg c3VwcG9zZWQgdG8gYmUgb25seSBhdmFpbGFibGUgdG8gdGhlIHByb3BlciBjbGllbnQuDQo+Pj4g DQo+Pj4gVGhlIHJpc2sgaW1wYWN0IG9mIFtjYXNlM10gaXMgdGhlIG1vc3QgZ3JhdmUgYW1vbmcg dGhlc2UgdGhyZWUuIE5vdyB0aGUgYXR0YWNrZXIgY2FuIGNyZWF0ZSBoaXMgb3duIGNsaWVudCB0 aGF0IGltcGVyc29uYXRlcyB0aGUgY29tcHJvbWlzZWQgY2xpZW50Lg0KPj4+IA0KPj4+IE9BdXRo LW1peC11cA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IE9BdXRoLW1peC11 cCBkcmFmdCBnaXZlcyBvbmUgd2F5IG9mIGFkZHJlc3NpbmcgW2Nhc2UyXSBieSBpbnRyb2R1Y2lu ZyBhIG5ldyBjb25jZXB0IG9mIOKAnGlzc3VlcuKAnSBhbmQg4oCcZGlzY292ZXJ54oCdIHRvIFJG QzY3NDkuIEl0IGFsc28gcmV0dXJucyBjbGllbnRfaWQgYW5kIHZlcmlmaWVzIGl0IGluIDQuMiwg YnV0IGlmIHRoZSBCYWRBUyBoYXMgYXNzaWduZWQgYSBzYW1lIGNsaWVudF9pZCB0byB0aGUgY2xp ZW50LCBpdCBkb2VzIG5vdCBoZWxwLg0KPj4gDQo+PiBDbGllbnRfaWQgYXJlIG5vdCBndWFyYW50 ZWVkIHRvIGJlIHVuaXF1ZS4gIFRoZXkgbmVlZCB0byBiZSBuYW1lIHNwYWNlZCBieSB0aGUgQVMu ICAgSW4gT0F1dGggY3VycmVudGx5IHdlIGhhdmUgbm8gbmFtZSBmb3IgdGhlIEFTIHRoaXMgbWFr ZXMgdGhhdCBkaWZmaWN1bHQsIHRoZSBjbGllbnQgY2FuIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBl bmRwb2ludCBVUkksIGJ1dCB0aGF0IGxvZ2ljIG1heSB3ZWxsIGJyZWFrIGluIG11bHRpIHRlbmFu dCBzaXR1YXRpb25zLiAgIEhhdmluZyBhIGNsZWFyIGlzc3VlciBzdHJpbmcgbWFrZXMgaXQgZWFz aWVyIGZvciB0aGUgY2xpZW50Lg0KPiANCj4gSSBzdHVtYmxlZCBvdmVyIGV4YWN0bHkgdGhpcyBw b2ludCB3aGVuIEkgbWFkZSBteSBpbXBsZW1lbnRhdGlvbiBmb2xsb3cgdGhlIE1peC1VcCBkcmFm dC4NCj4gSWYgbm90IGRpc2NvdmVyeSBpcyBpbnZvbHZlZCBJIHRoaW5rIGFuIEFTIGhhcyB0byBo YXZlIGEgbmFtZSB3aGljaCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZW5kcG9pbnQgVVJJcy4NCj4g DQo+Pj4gT25lIG9mIHRoZSBpc3N1ZSB3aXRoIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCB0aGUgY2Vu dHJhbCBub3Rpb24gb2Yg4oCcaXNzdWVy4oCdIGlzIG5ldyB0byB0aGUgZXhpc3Rpbmcgc2VydmVy cyBhbmQgY2xpZW50cy4gVGhlIHZlcmlmaWNhdGlvbiBydWxlIGluIDQuMSBzdGF0ZXMg4oCcQ29t cGFyZSB0aGUgaXNzdWVyIFVSTCBmb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRoYXQgdGhl IGNsaWVudCByZWNlaXZlZCB3aGVuIGl0IHJlZ2lzdGVyZWQgYXQgdGhlIGF1dGhvcml6YXRpb24g c2VydmVy4oCdLCBidXQgaW4gbW9zdCBleGlzdGluZyBwdXJlIE9BdXRoIGNhc2VzLCB0aGVyZSBp cyBubyBzdWNoIHRoaW5nLCBzbyB5b3UgY2Fubm90IGNvbXBhcmUuIFRoaXMgbWVhbnMgdGhhdCB5 b3Ugd291bGQgaGF2ZSB0byByZS1yZWdpc3RlciwgYW5kIGlmIHlvdSBhcmUgZG9pbmcgdGhhdCwg dGhlIHBlci1BUyByZWRpcmVjdF91cmkgc2VlbXMgdG8gYmUgYSBtdWNoIHNpbXBsZXIgc29sdXRp b24uDQo+PiANCj4+IFRoZSBjbGllbnQgZGV2ZWxvcGVycyBJIGhhdmUgdGFsa2VkIHRvIHJlYWxs eSBoYXRlIHBlciBBUyByZWRpcmVjdCBVUkkgYXMgYmVpbmcgdG9vIGF3a3dhcmQgZm9yIGRlcGxv eW1lbnRzLg0KPiANCj4gSSBvbiB0aGUgb3RoZXIgaGFuZCBmb3VuZCBpdCBxdWl0ZSBlYXN5IHRv IGRvIHBlciBBUyByZWRpcmVjdCBVUklzLCBzbyANCj4gaXQgbWlnaHQgd2VsbCBiZSBpbXBsZW1l bnRhdGlvbiBkZXBlbmRlbnQgcmF0aGVyIHRoZW4gY29udGV4dHVhbC4NCj4gDQo+Pj4gDQo+Pj4g UGVyIEFTIFJlZGlyZWN0IFVSSQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4gVGhpcyBkb2VzIG5vdCBpbnZvbHZlIHdpcmUgcHJvdG9jb2wgY2hhbmdlcy4gSXQganVz dCBhZGRzIHJlcXVpcmVtZW50cyBvbiB0aGUgcmVkaXJlY3QgdXJpLiBUaGlzIGJ5IGZhciBpcyB0 aGUgc2ltcGxlc3Qgc29sdXRpb24gZm9yIFtjYXNlMl0gKGFuZCBbY2FzZTFdKSwgSU1ITy4NCj4+ PiANCj4+PiBBZ2FpbiwgaXQgaXMgbm90IGEgZ2VuZXJhbCBmcmFtZXdvcmsgZm9yIGZpbmRpbmcg b3V0IHRhaW50ZWQgY29tbXVuaWNhdGlvbiwgc28gaXQgbWF5IGhhdmUgb3RoZXIgaG9sZXMuDQo+ PiANCj4+IFRoaXMgaXMgcHJvYmFibHkgdGhlIGhhcmRlc3QgZm9yIHRoZSBjbGllbnQgZGV2ZWxv cGVyIGFuZCBmb3IgdGhlIGRlcGxveWVyLiAgWWVzIGl0IGlzIHNpbXBsZXN0IGZyb20gYSBzcGVj IHBvaW50IG9mIHZpZXcuDQo+PiBXZSBuZWVkIG1vcmUgZGV2ZWxvcGVyIGZlZWRiYWNrIG9uIHRo aXMuDQo+IA0KPiBBcyBJIHNhaWQgYWJvdmUgSSBmb3VuZCB0aGlzIHF1aXRlIHNpbXBsZSB0byBp bXBsZW1lbnQuDQo+IA0KPj4+IChFeHRlbmRlZCkgUEtDRQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+IFRvIGJlZ2luIHdpdGgsIGl0IHdvcmtzIG9ubHkgd2l0aCBj b2RlIGZsb3cuIFRoZXJlIGhhcyB0byBiZSBzb21ldGhpbmcgZWxzZSB0byBkZWFsIHdpdGggaW1w bGljaXQgZmxvdy4NCj4+PiANCj4+PiBQS0NFIGJpbmRzIHRoZSBhdXRob3JpemF0aW9uIHJlcXVl c3QvcmVzcG9uc2UgdG8gdGhlIHRva2VuIHJlcXVlc3QuDQo+Pj4gSWYgdXNlZCB3aXRoIGEgY29u ZmlkZW50aWFsIGNsaWVudCwgaXQgc2VlbXMgdG8gbWl0aWdhdGUgdGhlIHZ1bG5lcmFiaWxpdHku DQo+Pj4gSm9obiBwb2ludHMgb3V0IHRoYXQgaXQgaXMgbm90IHRoZSBjYXNlLiBJIG11c3QgYmUg bWlzc2luZyBzb21ldGhpbmcgaGVyZeKApiBidXQgbXkgbG9naWMgZ29lcyBsaWtlOg0KPj4+IA0K Pj4+IA0KPj4+IDEuICAgICBUaGUgZ29vZCBjbGllbnQgY3JlYXRlcyBjb2RlX2NoYWxsZW5nZS12 IGFuZCBjb2RlX3ZlcmlmaWVyLXY9UzI1Nihjb2RlX2NoYWxsZW5nZS12KSBhbmQgc2VuZHMgdGhl IGNsaWVudF9pZC12ICsgY29kZV9jaGFsbGVuZ2UtdiArIHN0YXRlIHRvIHRoZSBCYWRBUyBBdXRo eiBFUC4NCj4+PiAyLiAgICAgQmFkQVMgYXMgYSBjbGllbnQgcHJlcGFyZXMgYSBjb2RlX3Zlcmlm aWVyLWIgYW5kIGNvZGVfY2hhbGxlbmdlLWI9UzI1Nihjb2RlX3ZlcmlmZXItYikuDQo+Pj4gMy4g ICAgIEJhZEFTIHJlZGlyZWN0cyB0byBHb29kQVMgd2l0aCB0aGUgY2xpZW50X2lkLXYgKyBjb2Rl X2NoYWxsZW5nZS1iICsgc3RhdGUtdi4NCj4+PiA0LiAgICAgR29vZEFTIHN0b3JlcyB0aGUgY29k ZV9jaGFsbGVuZ2UtYi4NCj4+PiA1LiAgICAgR29vZEFTIHJldHVybnMgY29kZS12ICsgc3RhdGUt diB0byB0aGUgY2xpZW504oCZcyByZWRpcmVjdCB1cmkuDQo+Pj4gNi4gICAgIFRoZSBjbGllbnQg ZmluZHMgdGhlIEFTIGZyb20gdGhlIHN0YXRlIGFuZCBzZW5kcyBjb2RlLXYgKyBjb2RlX3Zlcmlm aWVyLXYgKyBzZWNyZXQtYiB0byB0aGUgQmFkQVMgdG9rZW4gZW5kcG9pbnQuIE5vdywgY29kZS12 IGFuZCBjb2RlX3ZlcmlmZXItdiBpcyBwaGlzaGVkLg0KPj4+IA0KPj4+IE5vdyB0aGUgYXR0YWNr ZXIgdHJpZXMgdG8gdXNlIHRoZSBjb2RlLXYgYW5kIGNvZGVfdmVyaWZpZXItdi4NCj4+PiANCj4+ PiAjIyMgQ2FzZSBBOg0KPj4+IDcuICAgICBUaGUgQmFkQVMgYXMgYSBjbGllbnQgc2VuZHMgY2xp ZW50X2lkLXYgKyDigKYgYnV0IGhlIGRvZXMgbm90IGhhdmUgY2xpZW50IHNlY3JldCBmb3IgdGhl IGdvb2QgY2xpZW50LCBzbyBpdCBmYWlscy4NCj4+PiANCj4+PiAjIyMgQ2FzZSBCOg0KPj4+IDgu ICAgICBUaGUgQmFkQVMgYXMgYSBjbGllbnQgc2VuZHMgY2xpZW50X2lkLWIgKyBjb2RlLXYgKyBj b2RlX3ZlcmlmaWVyLWIgKyBzZWNyZXQtYiBldGMuIHRvIEdvb2RBUy4NCj4+PiA5LiAgICAgR29v ZEFTIHZlcmlmaWVzIHRoZSBjb2RlX3ZlcmlmaWVyLWIgaXMgYXNzb2NpYXRlZCB3aXRoIGNvZGUt diwgYnV0IHRoYXQgY29kZS12IGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggY2xpZW50X2lkLWIsIHNv IHRoZSB0b2tlbiByZXF1ZXN0IGZhaWxzLg0KPj4+IA0KPj4+ICMjIyBDYXNlIEM6IGN1dC1uLXBh c3RlDQo+Pj4gMTAuICBUaGUgYXR0YWNrZXIgbGF1bmNoZXMgY3V0LW4tcGFzdGUgYXR0YWNrIGJ5 IHJlcGxhY2luZyB0aGUgY29kZS1iIHdpdGggY29kZS12Lg0KPj4+IDExLiAgVGhlIHZlcmlmaWVy cyBkb2VzIG5vdCBtYXRjaCwgc28gZmFpbHMuDQo+Pj4gDQo+Pj4gUGxlYXNlIGxldCBtZSBrbm93 IHdoYXQgSSBhbSBtaXNzaW5nLg0KPj4gDQo+PiBJbiBhIHN0ZXAgMCB0aGUgYXR0YWNrZXIgaGFz IHRoZSBnb29kIGNsaWVudCBjcmVhdGUgYW5vdGhlciByZXF1ZXN0IA0KPj4gaW4gdGhlIGF0dGFj a2VycyB1c2VyIGFnZW50IHRvIGdldCBzdGF0ZS0wIGFuZCBjb2RlX2NoYWxsYW5nZS0wDQo+PiAN Cj4+IFN0ZXAgMiBpcyBub3QgcmVxdWlyZWQuDQo+PiBTdGVwIDMgQmFkIEFTIHJlZGlyZWN0cyB0 byBnb29kIEFTIHdpdGggY2xpZW50X2lkX3YgKyBzdGF0ZS12ICsgDQo+PiBjb2RlX2NoYWxsZW5n ZS0wIFN0ZXAgNCBHb29kQVMgc3RvcmVzIGNvZGVfY2hhbGxlbmdlLTAgU3RlcCA1IEdvb2RBUyAN Cj4+IHJldHVybnMgY29kZS12ICsgc3RhdGUtdiB0byB0aGUgY2xpZW50cyByZWRpcmVjdF91cmkg U3RlcCA2IFRoZSANCj4+IGNsaWVudCBmaW5kcyB0aGUgQVMgZnJvbSB0aGUgc3RhdGUgYW5kIHNl bmRzIGNvZGUtdiArIGNvZGVfdmVyaWZpZXItdiArIHNlY3JldC1iIHRvIHRoZSBCYWRBUyB0b2tl biBlbmRwb2ludC4gTm93LCBjb2RlLXYgYW5kIGNvZGVfdmVyaWZlci12IGlzIHBoaXNoZWQuDQo+ PiANCj4+IENhc2UgQzEgOiAgY3V0IGFuZCBwYXN0ZQ0KPj4gMTAuICBUaGUgYXR0YWNrZXIgbGF1 bmNoZXMgY3V0LW4tcGFzdGUgYXR0YWNrIGJ5IGluc2VydGluZyBjb2RlLXYgDQo+PiBpbnRvIGEg cmVzcG9uc2UgdXNpbmcgc3RhdGUtMCAxMS4gVGhlIGNsaWVudCBzZW5kcyBjb2RlLXYgYW5kIGJh c2VkIG9uIHN0YXRlLTAgaXQgc2VuZHMgY29kZV92ZXJpZnllci0wIHRvIHRoZSBnb29kIEFTIHRv a2VuIGVuZHBvaW50Lg0KPj4gMTIuIFRoZSBHb29kQVMgdmVyaWZpZXMgdGhhdCBjb2RlLXZlcmlm eWVyLTAgaXMgY29ycmVjdCBmb3IgDQo+PiBjb2RlX2NoYWxsYW5nZS0wIHRoYXQgaXQgYm91bmQg dG8gY29kZSBpbiBzdGVwIDQgMTMuIFRoZSBHb29kQVMgcmVjZWl2ZXMgUlQgKyBBVC4NCj4+IDE0 LiBUaGUgYXR0YWNrZXIgaGFzIG5vdyB1c2VkIHRoZSBjbGllbnQgdG8gYmluZCB0aGUgdXNlcnMg cmVzb3VyY2UgdG8gaXTigJlzIGFjY291bnQgYW5kIGlzIHRyYW5zZmVycmluZyBtb25leSBvciBs b29raW5nIGF0IHlvdXIgZGF0YS4NCj4+IA0KPj4gVGhpcyBjb3VsZCBiZSAzcmQgcGFydHkgZmlu YW5jaWFsIGFwcCBsaWtlIE1pbnQgYXMgYW4gZXhhbXBsZSBvciBwaG90b3Mgb3IgYW55IG90aGVy IFBJSSB0aGF0IGNvdWxkIHRoZW4gYmUgdXNlZCB0byBlc2NhbGF0ZSBpZGVudGl0eSB0aGVmdC4N Cj4+IA0KPj4gVGhpcyB2YXJpYXRpb24gb2YgdGhlIGF0dGFjayBjb21iaW5pbmcgY3V0IGFuZCBw YXN0ZSB3aXRoIGNvbmZ1c2VkIGNsaWVudCB3YXMgbm90IG1lbnRpb25lZCBpbiB0aGUgcmVzZWFy Y2ggcGFwZXJzLg0KPj4gDQo+PiBJIGZvdW5kIGl0IGxvb2tpbmcgdG8gc2VlIGlmIFBLQ0UgY291 bGQgYmUgdXNlZCB0byBtaXRpZ2F0ZSB0aGUgY29uZnVzZWQgY2xpZW50IGF0dGFjay4NCj4+IA0K Pj4gQXMgSSBtZW50aW9uZWQgaW4gYSByZXNwb25zZSB0byBXaWxsaWFtLCB3aGlsZSB0aGUgY3Vy cmVudCBQS0NFIENoYWxsZW5nZSBtZXRob2RzIG9ubHkgbWFrZSB0aGUgYXR0YWNrIGhhcmRlciBi eSBmb3JjaW5nIHRoZSBhdHRhY2tlciB0byBnZXQgdGhlIGNsaWVudCB0byBtYWtlIGEgc3RlcCAw IHJlcXVlc3QgdG8gZ2V0IGEgY29kZV9jaGFsbGVuZ2UgdG8gdXNlIGluIHRoZSByZXF1ZXN0LCAg d2UgY291bGQgZGVmaW5lIGEgbmV3IGNoYWxsZW5nZSBtZXRob2QgdGhhdCB3b3VsZCBiZSBlZmZl Y3RpdmUuDQo+PiANCj4+IFRoYXQgd291bGQgcmVtb3ZlIHRoZSBuZWVkIHRvIGhhdmUgYSBzZXBh cmF0ZSBtZWNoYW5pc20gdG8gcHJldmVudCBjdXQgYW5kIHBhc3RlLg0KPj4gDQo+PiBUaGUgcHJv YmxlbSBpcyB0aGF0IHRoZSBQS0NFIGNoYWxsZW5nZSBpcyBpbmRlcGVuZGVudCBvZiBzdGF0ZSBz byBiZWNvbWVzIHZ1bG5lcmFibGUgdG8gdGhlIGNvbmZ1c2VkIGNsaWVudC4NCj4+IA0KPj4gV2hh dCB3ZSB3b3VsZCBuZWVkIHRvIGRvIGlzIGluY2x1ZGUgc3RhdGUgaW4gdGhlIGNoYWxsZW5nZSBz byB0aGF0IGlmIHRoZSBBUyByZWNlaXZlcyBtaXNtYXRjaGVkIHN0YXRlIGFuZCBjb2RlX2NoYWxs YW5nZSBpbiBzdGVwIDMgdGhlIHZlcmlmaWNhdGlvbiBvZiBjb2RlIHZlcmlmaWVyIHdpbGwgZmFp bC4gRWZmZWN0aXZlbHkgY29tYmluaW5nIHRoZSBjdXQgYW5kIHBhc3RlIG1pdGlnYXRpb24gd2l0 aCBQS0NFLg0KPj4gDQo+PiBJIGhhdmVu4oCZdCBoYWQgdGltZSB0byB3cml0ZSB0aGlzIHVwLCBi dXQgaWYgdGhlIGNvZGVfY2hhbGxlbmdlID09IA0KPj4gU0hBMjU2IChTSEEyNTYoc3RhdGUpIHx8 IHRva2VuX2VuZHBvaW50IFVSSSB8fCBBdXRob3JpemF0aW9uX2VuZHBvaW50IA0KPj4gVVJJIHx8 IGNsaWVudF9pZCB8fCBjb2RlLXZlcml5ZXIpICwgIHRoZW4gdGhlIGF0dGFja2VyIGNvdWxkIG5v dCANCj4+IGNoYW5nZSBzdGF0ZSwgY2xpZW50X2lkLCBvciB0b2tlbl9lbmRwb2ludCAgaW5kZXBl bmRlbnRseSBvZiANCj4+IGNvZGVfY2hhbGxlbmdlLiAgKG5vdGUgSSBhbSB1c2luZyBhIGhhc2gg b2Ygc3RhdGUgdG8gbWFrZSBzdG9yYWdlIA0KPj4gc2l6ZSBkZXRlcm1pbmlzdGljIGZvciB0aGUg QVMgb24gdGhlIGdyb3VuZHMgdGhhdCB0aGUgY2xpZW50IGFscmVhZHkgDQo+PiBuZWVkcyB0byBi ZSBhYmxlIHRvIGRvIHRoZSBoYXNoKSAoU29tZSBhdHRhY2tzICBjaGFuZ2UgdGhlIGNsaWVudF9p ZCANCj4+IGluIHRoZSByZXF1ZXN0IHNvIEkgYW0gaW5jbHVkaW5nIGl0IGluIHRoZSBoYXNoKQ0K Pj4gDQo+PiBUaGlzIGlzIHNsaWdodGx5IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGFuIFMyNTYs IGJ1dCBub3QgdGhhdCBtdWNoLiAgSSB3aXNoIEkgaGFkIHRob3VnaHQgb2YgdGhpcyB3aGVuIHdl IHdlcmUgZG9pbmcgUEtDRS4gICBIaXQgbWUgd2l0aCB0aGUgc3R1cGlkIHN0aWNrLCBteSBmYXVs dC4NCj4+IA0KPj4gSSBkb27igJl0IGtub3cgaWYgaXQgc3RvcHMgYWxsIHRoZSBjb25mdXNlZCBj bGllbnQgYXR0YWNrcyB0aG91Z2guDQo+PiANCj4+IElmIHRoZSBjbGllbnQgaXMgY29uZmlkZW50 aWFsIHRoZW4gaXQgZ2l2ZXMgdXAgaXTigJlzIGNsaWVudCBzZWNyZXQgYXNzdW1pbmcgY29tcHJv bWlzZWQgcmVnaXN0cmF0aW9uLCBzbyB3ZSBjYW7igJl0IHJlYWxseSBjb3VudCBvbiB0aGF0IGZv ciBzeW1tZXRyaWMgY2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KPj4gDQo+PiBCeSBpbmNsdWRpbmcg dGhlIHRva2VuIGVuZHBvaW50IGluIHRoZSBjb21wYXJpc29uIGlmIHRoZSBjbGllbnQgaXMgc2Vu ZGluZyB0aGUgY29kZSB0byB0aGUgYXR0YWNrZXIgdGhlIGNsaWVudCB3aWxsIHVzZSBhIGRpZmZl cmVudCB0b2tlbiBlbmRwb2ludF91cmkgaW4gdG8gY2FsY3VsYXRlIHRoZSBjb2RlX2NoYWxsZW5n ZSB0aGFuIHRoZSBHb29kQVMgd2lsbCB1c2UgdG8gdmVyaWZ5IGl0LiAgICBUaGlzIHdvdWxkIHN0 b3AgYm90aCBjdXQgYW5kIHBhc3RlIGFzIHdlbGwgYXMgc3RvcHBpbmcgdGhlIGF0dGFja2VyIGZy b20gdXNpbmcgdGhlIGNvZGUgaWYgdGhleSBnZXQgaXQuICAgVGhlIGF0dGFja2VyIGNhbuKAmXQg Z2V0IFNlY3JldCBmb3Igc3RhdGUtMCwgc28gaXQgY2Fu4oCZdCBjcmVhdGUgY29kZV9jaGFsbGVu Z2UgdGhhdCB3b3VsZCBiZSB2YWxpZC4NCj4+IA0KPj4gVGhpcyBzdG9wcyB0aGUgcmVnaXN0cmF0 aW9uIGF0dGFjayB3aGVyZSB0aGUgY2xpZW50IGdldHMgYSBiYWQgQVMgZGlzY292ZXJ5IGVuZHBv aW50IHRoYXQgaGFzIGFsbCB0aGUgR29vZCBBUyBpbmZvIGluY2x1ZGluZyBkeW5hbWljIHJlZ2lz dHJhdGlvbiBlbmRwb2ludCBidXQgdGhlIGJhZCBBUyB0b2tlbiBlbmRwb2ludC4gICBUaGUgYmFk IEFTIHdvdWxkIGdldCB0aGUgdG9rZW4sIGNsaWVudF9zZWNyZXQgYW5kIGNvZGVfdmVyaWVyLCBi dXQgd2lsbCBmYWlsIHBrY2UgdmVyaWZpY2F0aW9uIGJlY2F1c2UgdGhlIHRva2VuIGVuZHBvaW50 IHdpbGwgYmUgd3JvbmcuDQo+PiANCj4+IFRoZSBhdHRhY2sgd2hlcmUgdGhlIGNsaWVudCByZWdp c3RlcnMgd2l0aCB0aGUgZ29vZCBBUyBidXQgd2l0aCBiYWQgdG9rZW4gZW5kcG9pbnQgYW5kIEF1 dGhvcml6YXRpb24gZW5kcG9pbnQgZ2l2ZXMgdGhlIGF0dGFja2VyIHRoZSBhYmlsaXR5IHRvIGNo YW5nZSB0aGUgY29kZV9jaGFsbGVuZ2UgdGhhdCB0aGUgR29vZCBBUyBpcyBnb2luZyB0byBzZWUu ICAgSXQgd291bGQgbmVlZCB0byBtYWtlIGEgbmV3IGNoYWxsZW5nZSB1c2luZyBzdGF0ZSBhbmQg dGhlIEdvb2RBUyB0b2tlbiBlbmRwb2ludCBhbmQgaXTigJlzIGNsaWVudF9pZC4NCj4+IFRvIGRv IHRoYXQgaXQgbmVlZHMgdGhlIGNvZGVfdmVyaWZpZXIgdG8gdXNlIHRvIGNhbGN1bGF0ZSB0aGUg aGFzaCB0byB1c2UgYXMgdGhlIGNvZGVfY2hhbGxlbmdlIHZhbHVlLiAgQXMgbG9uZyBhcyB0aGUg Y2xpZW50IGlzIG5vdCB0cmlja2VkIGludG8gYWNjZXB0aW5nIGEgcmVwbGF5IG9mIHRoZSBhdXRo ZW50aWNhdGlvbiByZXNwb25zZSB3ZSBzaG91bGQgYmUgc2FmZS4gIFRoZSBjbGllbnQgd291bGQg bmVlZCB0byBkbyByZXBsYXkgcHJvdGVjdGlvbiBvbiB0aGUgY29kZV92ZXJpZmllciB2YWx1ZXMg YmVmb3JlIGl0IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQuDQo+PiANCj4+ IFRoZSBCYWRBUyBjb3VsZCBob3dldmVyIG1ha2UgdXAgYSBuZXcgY29kZV9jaGFsbGVuZ2UgYW5k IGNvZGVfdmVyaWZpZXIgYW5kIHVzZSB0aGF0IGluIHRoZSByZXF1ZXN0LiBGb3IgdGhpcyBvbmUg dGhlIEFTIHdvdWxkIG5lZWQgdG8gZG8gcHVsbCBkaXNjb3Zlcnkgb24gdGhlIGNsaWVudCB0byBn ZXQgYSBrZXksIG9yIHRoZSBBUyBuZWVkcyB0byByZXR1cm4gc29tZXRoaW5nIGluIHRoZSByZXNw b25zZS4gIFRoaXMgYXR0YWNrIGNhbiBjb21wbGV0ZWx5IHByb3h5IGFsbCB0aGUgZW5kcG9pbnRz IGFzIGZhciBhcyB0aGUgY2xpZW50IGlzIGNvbmNlcm5lZCBhbmQgaXMgdGFraW5nIGFkdmFudGFn ZSBvZiB0aGUgQVMgc2F5aW5nIHlvdSBhcmUgZ3JhbnRpbmcgcGVybWlzc2lvbiB0byBzaXRlIFgg YmFzZWQgb24gdGhlIHJlZGlyZWN0IFVSSS4NCj4+IA0KPj4gSSBjYW7igJl0IHNlZSBQS0NFIG9u IGl04oCZcyBvd24gYmVpbmcgYWJsZSB0byBzdG9wIGEgY2xpZW50IGZyb20gYmVpbmcgdXNlZCBh cyBhIHJlZGlyZWN0b3IgYmFjayB0byB0aGUgYXR0YWNrZXIgdW5sZXNzIHlvdSBhbHNvIHJldHVy bmVkIHRoZSBjb2RlX2NoYWxsZW5nZSBpbiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludC4NCj4+IA0KPj4gSHlwb3RoZXRpY2FsbHkgaWYgd2UgcmV0dXJuZWQgY29k ZV9jaGFsbGVuZ2UgaW4gdGhlIHJlc3BvbnNlIGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgYW5kIGhhdmUgYSBuZXcgUEtDRSBjaGFsbGVuZ2UgbWV0aG9kIHdlIG1pZ2h0IGZpbmQgaXQg Y292ZXJzIGFsbCBvZiB0aGUgYXR0YWNrcy4NCj4+IA0KPj4gV2Ugd291bGQgbmVlZCB0byBwdXQg c29tZSBzZXJpb3VzIGFuYWx5c2lzIGludG8gdGhpcyB0byBzZWUgaWYgaXQgcmVhbGx5IGNvdmVy cyBhbGwgdGhlIGF0dGFja3MuDQo+PiANCj4+IEl0IGhvd2V2ZXIgZG9lc27igJl0IGFkZHJlc3Mg dGhlIOKAnHRva2Vu4oCdIHJlc3BvbnNlX3R5cGUgb3Igc3RlZWxpbmcgdGhlIGFjY2VzcyB0b2tl biBieSBpbXBlcnNvbmF0aW5nIHRoZSBSUy4NCj4+IA0KPj4gSSB0aGluayB0aGUgY29ycmVjdCB3 YXkgdG8gc3RvcCB0aGUgcHJvYmxlbSB3aXRoIGFjY2VzcyB0b2tlbnMgaXMgYnkgYXVkaWVuY2Ug cmVzdHJpY3RpbmcgdGhlbS4NCj4+IFRvIGRvIHRoYXQgdGhlIGNsaWVudCBuZWVkcyB0byBwcm92 aWRlIGFuIGF1ZGllbmNlIGluIGl04oCZcyByZXF1ZXN0IGFuZCB0aGUgQVMgbmVlZHMgdG8gaW5j bHVkZSB0aGF0IGluIHRoZSBBVC4NCj4+IA0KPj4gSSBpbmNsdWRlZCB0aGUgQXV0aG9yaXphdGlv bl9lbmRwb2ludCBVUkkgaW4gdGhlIGhhc2ggdG8gZGV0ZWN0IGlmIHRoZSBhdXRoIHJlcXVlc3Qg bWF5IGhhdmUgYmVlbiB0YW1wZXJlZCB3aXRoIHRvIGNoYW5nZSB0aGUgYXVkaWVuY2UgZm9yIHRo ZSBBVC4NCj4+IA0KPj4gRm9yIGltcGxpY2l0IHdlIGNvdWxkIGhhdmUgYSB2ZXJzaW9uIG9mIFBL Q0Ugd2hlcmUgdGhlIEFTIHJldHVybnMgYSBwYXJhbWV0ZXIgd2l0aCBTMjU2KCBjbGllbnRfaWQg fHwgYXV0aG9yaXphdGlvbl9lbmRwb2ludCBVUkkgfHwgcmVzb3VyY2UgZW5kcG9pbnQgVVJJKSB0 byB2ZXJpZnkgdGhlIHJlcXVlc3Qgd2FzIG5vdCB0YW1wZXJlZCB3aXRoLCBhbmQgdGhhdCB3b3Vs ZCBhbGxvdyB0aGUgQVQgdG8gYmUgcHJvcGVybHkgYXVkaWVuY2UgcmVzdHJpY3RlZC4NCj4+IA0K Pj4gDQo+PiBUaGlzIHdvdWxkIGJlIGEgY29tcGxldGVseSBuZXcgYXBwcm9hY2ggbm90IGludm9s dmluZyBkaXNjb3ZlcnksIGxvZ2ljYWwgbmFtZXMgZm9yIEFTLCBvciBsaW5rIHJlbGF0aW9ucy4N Cj4+IA0KPj4gRWZmZWN0aXZlbHkgdGhpcyBjb2RlX2NoYWxsZW5nZSBtZXRob2QgYmVjb21lcyBh IHNpZ25hdHVyZSBvdmVyIHBhcnRzIG9mIHRoZSByZXF1ZXN0IGFuZCB0aGUgaW1wbGljaXQgYXVk aWVuY2Ugb2YgdGhlIHRva2VuX2VuZHBvaW50IFVSSS4NCj4+IA0KPj4gUGVvcGxlIGtlZXAgYXNr aW5nIHdoeSBQS0NFIGRvZXNu4oCZdCBzdG9wIHRoZXNlIGF0dGFja3MsIGFuZCBpdCB3b27igJl0 IHdpdGggdGhlIGN1cnJlbnQgUEtDRSBtZXRob2RzLCAgaG93ZXZlciBhIG5ldyBtZXRob2QgYWxv bmcgdGhlIGxpbmVzIEkgc2tldGNoZWQgb3V0IG1heSBsZXQgaXQgd29yaywgb3IgSSBjb3VsZCBi ZSBjb21wbGV0ZWx5IHdyb25nLg0KPiANCj4gT25jZSB5b3UgaGF2ZSB3cml0dGVuIGRvd24gc29t ZXRoaW5nIG1vcmUgZGVmaW5pdGUgSSBwcm9taXNlIHRvIA0KPiBpbXBsZW1lbnQgaXQgcHJvbXB0 bHkgc3VjaCB0aGF0IHdlIGNhbiBkbyBpbnRlcm9wIHRlc3RpbmcgZWFybHkgaW4gdGhlIHByb2Nl c3MuDQo+IA0KPiBCZWZvcmUgSm9obiBicm91Z2h0IHVwIHRoaXMgbmV3IFBLQ0UgbW9kZSBJIHdh cyBvbiB0aGUgT3B0aW9uIEEgc2lkZSANCj4gb2YgdGhlIGZlbmNlIG5vdyBJ4oCZZCBsaWtlIHRv IHNlZSBtb3JlIG9mIHRoaXMgUEtDRSBpZGVhIGJlZm9yZSBjb21taXR0aW5nIHRvIG9uZSBvciB0 aGUgb3RoZXIuDQo+IA0KPiDigJQgUm9sYW5kDQo+IA0KPiDigJ1FdmVyeWJvZHkgc2hvdWxkIGJl IHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIg0KPiBGcm9tIOKAmU9wZW4g SG91c2UgZm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzDQo+IA0KDQo= From nobody Wed Feb 24 02:27:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6091A1B11 for ; Wed, 24 Feb 2016 02:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9E8UaY3cTMD for ; Wed, 24 Feb 2016 02:27:46 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 D5F741A1B0B for ; Wed, 24 Feb 2016 02:27:45 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id y89so10102568qge.2 for ; Wed, 24 Feb 2016 02:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=EF23NAyDclrUKdum8dK/PKtZVH1oeokECDVWsqpP2qE=; b=jBWsb0kptsaSTSW2YtSsfZjchTg8b4+D0egnGs/rqkH8HmlDZTa4kID42+FhcUGQJU 5nWHehvwMVmRs6YfCWTF++vJaKFGzwGwJknFEQHIbPTmJ4UoJQfQva5RFSCBfvygDz9x 6+eLnYMAafodAGpLXEHCzVAFoqMajjqvqoqZ8o4COpK0uP5ur95pUfh9I3gR31n4qEea uty5lif6SX2a09OnWoNYtwz5NtQCTUSI6NvDb59i6BffeJq5WO7VLcnoa5Oz4Fkq2k3R 0qESBuR5kbX4eBdoK/754v8j4dpKRiESArwLOskwys44VgyeLGwQMvPPP6oD0FOKAsCo SgGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=EF23NAyDclrUKdum8dK/PKtZVH1oeokECDVWsqpP2qE=; b=D/6qX532H/RAA1Uf3VKGdKM4f9tUk0p7yzQRzX/TLRgZpHEjyqe/C8s/KXnAZyvHNJ 98+0dyZbP0m7DheYogiaseIJdHmj50EcVF3DlmguKogGuCUQbpp7Lm1MZ/CXrSx62see +jiTBSxuaM8dXAXA0ct56oXY90V1ALmRfbaPCJXxpNYIUnRaeTKI1SeSkdWtKJSCOD0H fRE3l046izS+vuXyOwvPGGQ72jclRgQTTu+dFhYShSr90qfnQtqQybfmVHfYaqcUGu35 W1N8yNsF6ewoy4DmVbJZR7fodmoA2AeTtJivVmi8hdMFxEGVsIKPCB6rP98hmtrdoJE4 EP8w== X-Gm-Message-State: AG10YOQgcIyvYpiStHtQr2zb/O9dR2tU2MTZitylOUXFaOzKk8zRTKdm+K8xlYNrqADOONgnjiuuO3QfdiDvuA== X-Received: by 10.140.165.205 with SMTP id l196mr51044905qhl.58.1456309664868; Wed, 24 Feb 2016 02:27:44 -0800 (PST) MIME-Version: 1.0 References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> In-Reply-To: <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> From: Nat Sakimura Date: Wed, 24 Feb 2016 10:27:34 +0000 Message-ID: To: John Bradley , Roland Hedberg Content-Type: multipart/alternative; boundary=001a1134f04c41efa8052c818422 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 10:27:52 -0000 --001a1134f04c41efa8052c818422 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 8:17 John Bradley : [..snip..] > > This is not stoping the attack it is protecting code. > IMHO, this is the right approach. We should solve the problem architecturally rather than bandaging the hols. > > I should point out that some of the attacks like man in the middling > registration can still compromise the client secret, making it possible f= or > an attacker to impersonate a client. In case of the dyn-reg, the client really should make sure the identity of the registration endpoint it is talking to through TLS certs checking. This is the right way of addressing the man-in-the-middle in this case. Manual case is hard to fix with a bearer client secret. We probably need to do public key crypto. Instead of giving a bearer client secret, have the client regiser the public key, just like we register ssh public key all the time with github etc. It should not be too hard at all. > Nat=E2=80=99s option B doesn=E2=80=99t have a solution to that ether as f= ar as I can tell. > > I think the only option for that is to have a logical identifier for the > AS and some sort of discovery check at registration to be certain that yo= u > are using the correct registration location. > How does it help with preventing the client credential theft through mitm during the registration? Client secret is already gone by the time you do the discovery. > > Option A plus discovery works for that and mitigates confused client but > not cut and paste. > > We still have a problem with AT leaking. I think that needs to be dealt > with separately. > Access tokens should have a audience (by value or by introspection) the > client needs to tell the AS what resource it want s to use the token at a= nd > have that included as the audience or the request rejected because it is = an > invalid audience. > Is not the scope the implicit combination of the resource, the endpoint form which you can access the resource, and operation? > > That should happen at the token endpoint for code. > And, that's why we can send scope there. The response can also include scope, which is good but my problem here is that scope value in the response would be a bit too vague. Either having the uri from which the client can get the list of the resource endpoint, or get them as RFC5988 header would be nicer. > For implicit it would need to be at the authoriation endpoint and the > audience would need to be echoed back to prevent tampering. > For a javascript client that is interacting with the authorization endpoint, getting them in the response header would be great. For a client that is getting the response through browser redirect, the audience value needs to be protected by PKCE response or something. > > The AT can also be protected by POP so I think that code and AT should be > kept separate issues. > John B. > > > > On Feb 23, 2016, at 9:59 PM, Roland Hedberg > wrote: > > > > In line ! > > > >> 22 feb 2016 kl. 05:08 skrev John Bradley : > >> > >>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura > wrote: > >>> > >>> The risk impact of [case2] is more OAuth specific. The token is stole= n > as the token is going to be sent to a rogue resource, and the resource ca= n > use that to obtain the resource that was supposed to be only available to > the proper client. > >>> > >>> The risk impact of [case3] is the most grave among these three. Now > the attacker can create his own client that impersonates the compromised > client. > >>> > >>> OAuth-mix-up > >>> --------------------------- > >>> OAuth-mix-up draft gives one way of addressing [case2] by introducing > a new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D= to RFC6749. It also returns > client_id and verifies it in 4.2, but if the BadAS has assigned a same > client_id to the client, it does not help. > >> > >> Client_id are not guaranteed to be unique. They need to be name space= d > by the AS. In OAuth currently we have no name for the AS this makes tha= t > difficult, the client can use the authorization endpoint URI, but that > logic may well break in multi tenant situations. Having a clear issuer > string makes it easier for the client. > > > > I stumbled over exactly this point when I made my implementation follow > the Mix-Up draft. > > If not discovery is involved I think an AS has to have a name which is > different from the endpoint URIs. > > > >>> One of the issue with this approach is that the central notion of > =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The = verification rule > in 4.1 states =E2=80=9CCompare the issuer URL for the authorization serve= r that the > client received when it registered at the authorization server=E2=80=9D, = but in > most existing pure OAuth cases, there is no such thing, so you cannot > compare. This means that you would have to re-register, and if you are > doing that, the per-AS redirect_uri seems to be a much simpler solution. > >> > >> The client developers I have talked to really hate per AS redirect URI > as being too awkward for deployments. > > > > I on the other hand found it quite easy to do per AS redirect URIs, so > it might well be implementation > > dependent rather then contextual. > > > >>> > >>> Per AS Redirect URI > >>> -------------------------------- > >>> This does not involve wire protocol changes. It just adds requirement= s > on the redirect uri. This by far is the simplest solution for [case2] (an= d > [case1]), IMHO. > >>> > >>> Again, it is not a general framework for finding out tainted > communication, so it may have other holes. > >> > >> This is probably the hardest for the client developer and for the > deployer. Yes it is simplest from a spec point of view. > >> We need more developer feedback on this. > > > > As I said above I found this quite simple to implement. > > > >>> (Extended) PKCE > >>> --------------------------------- > >>> To begin with, it works only with code flow. There has to be somethin= g > else to deal with implicit flow. > >>> > >>> PKCE binds the authorization request/response to the token request. > >>> If used with a confidential client, it seems to mitigate the > vulnerability. > >>> John points out that it is not the case. I must be missing something > here=E2=80=A6 but my logic goes like: > >>> > >>> > >>> 1. The good client creates code_challenge-v and > code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + > code_challenge-v + state to the BadAS Authz EP. > >>> 2. BadAS as a client prepares a code_verifier-b and > code_challenge-b=3DS256(code_verifer-b). > >>> 3. BadAS redirects to GoodAS with the client_id-v + > code_challenge-b + state-v. > >>> 4. GoodAS stores the code_challenge-b. > >>> 5. GoodAS returns code-v + state-v to the client=E2=80=99s redire= ct uri. > >>> 6. The client finds the AS from the state and sends code-v + > code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and > code_verifer-v is phished. > >>> > >>> Now the attacker tries to use the code-v and code_verifier-v. > >>> > >>> ### Case A: > >>> 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he doe= s not > have client secret for the good client, so it fails. > >>> > >>> ### Case B: > >>> 8. The BadAS as a client sends client_id-b + code-v + > code_verifier-b + secret-b etc. to GoodAS. > >>> 9. GoodAS verifies the code_verifier-b is associated with code-v, > but that code-v is not associated with client_id-b, so the token request > fails. > >>> > >>> ### Case C: cut-n-paste > >>> 10. The attacker launches cut-n-paste attack by replacing the code-b > with code-v. > >>> 11. The verifiers does not match, so fails. > >>> > >>> Please let me know what I am missing. > >> > >> In a step 0 the attacker has the good client create another request in > the attackers user agent to get state-0 and code_challange-0 > >> > >> Step 2 is not required. > >> Step 3 Bad AS redirects to good AS with client_id_v + state-v + > code_challenge-0 > >> Step 4 GoodAS stores code_challenge-0 > >> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri > >> Step 6 The client finds the AS from the state and sends code-v + > code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and > code_verifer-v is phished. > >> > >> Case C1 : cut and paste > >> 10. The attacker launches cut-n-paste attack by inserting code-v into > a response using state-0 > >> 11. The client sends code-v and based on state-0 it sends > code_verifyer-0 to the good AS token endpoint. > >> 12. The GoodAS verifies that code-verifyer-0 is correct for > code_challange-0 that it bound to code in step 4 > >> 13. The GoodAS receives RT + AT. > >> 14. The attacker has now used the client to bind the users resource to > it=E2=80=99s account and is transferring money or looking at your data. > >> > >> This could be 3rd party financial app like Mint as an example or photo= s > or any other PII that could then be used to escalate identity theft. > >> > >> This variation of the attack combining cut and paste with confused > client was not mentioned in the research papers. > >> > >> I found it looking to see if PKCE could be used to mitigate the > confused client attack. > >> > >> As I mentioned in a response to William, while the current PKCE > Challenge methods only make the attack harder by forcing the attacker to > get the client to make a step 0 request to get a code_challenge to use in > the request, we could define a new challenge method that would be > effective. > >> > >> That would remove the need to have a separate mechanism to prevent cut > and paste. > >> > >> The problem is that the PKCE challenge is independent of state so > becomes vulnerable to the confused client. > >> > >> What we would need to do is include state in the challenge so that if > the AS receives mismatched state and code_challange in step 3 the > verification of code verifier will fail. Effectively combining the cut an= d > paste mitigation with PKCE. > >> > >> I haven=E2=80=99t had time to write this up, but if the code_challenge= =3D=3D > SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI > || client_id || code-veriyer) , then the attacker could not change state= , > client_id, or token_endpoint independently of code_challenge. (note I a= m > using a hash of state to make storage size deterministic for the AS on th= e > grounds that the client already needs to be able to do the hash) (Some > attacks change the client_id in the request so I am including it in the > hash) > >> > >> This is slightly more complicated than than S256, but not that much. = I > wish I had thought of this when we were doing PKCE. Hit me with the > stupid stick, my fault. > >> > >> I don=E2=80=99t know if it stops all the confused client attacks thoug= h. > >> > >> If the client is confidential then it gives up it=E2=80=99s client sec= ret > assuming compromised registration, so we can=E2=80=99t really count on th= at for > symmetric client authentication. > >> > >> By including the token endpoint in the comparison if the client is > sending the code to the attacker the client will use a different token > endpoint_uri in to calculate the code_challenge than the GoodAS will use = to > verify it. This would stop both cut and paste as well as stopping the > attacker from using the code if they get it. The attacker can=E2=80=99t= get > Secret for state-0, so it can=E2=80=99t create code_challenge that would = be valid. > >> > >> This stops the registration attack where the client gets a bad AS > discovery endpoint that has all the Good AS info including dynamic > registration endpoint but the bad AS token endpoint. The bad AS would g= et > the token, client_secret and code_verier, but will fail pkce verification > because the token endpoint will be wrong. > >> > >> The attack where the client registers with the good AS but with bad > token endpoint and Authorization endpoint gives the attacker the ability = to > change the code_challenge that the Good AS is going to see. It would ne= ed > to make a new challenge using state and the GoodAS token endpoint and it= =E2=80=99s > client_id. > >> To do that it needs the code_verifier to use to calculate the hash to > use as the code_challenge value. As long as the client is not tricked in= to > accepting a replay of the authentication response we should be safe. The > client would need to do replay protection on the code_verifier values > before it makes a request to the token endpoint. > >> > >> The BadAS could however make up a new code_challenge and code_verifier > and use that in the request. For this one the AS would need to do pull > discovery on the client to get a key, or the AS needs to return something > in the response. This attack can completely proxy all the endpoints as f= ar > as the client is concerned and is taking advantage of the AS saying you a= re > granting permission to site X based on the redirect URI. > >> > >> I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a clie= nt from being > used as a redirector back to the attacker unless you also returned the > code_challenge in the response from the authorization endpoint. > >> > >> Hypothetically if we returned code_challenge in the response from the > authorization endpoint and have a new PKCE challenge method we might find > it covers all of the attacks. > >> > >> We would need to put some serious analysis into this to see if it > really covers all the attacks. > >> > >> It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D respons= e_type or steeling the > access token by impersonating the RS. > >> > >> I think the correct way to stop the problem with access tokens is by > audience restricting them. > >> To do that the client needs to provide an audience in it=E2=80=99s req= uest and > the AS needs to include that in the AT. > >> > >> I included the Authorization_endpoint URI in the hash to detect if the > auth request may have been tampered with to change the audience for the A= T. > >> > >> For implicit we could have a version of PKCE where the AS returns a > parameter with S256( client_id || authorization_endpoint URI || resource > endpoint URI) to verify the request was not tampered with, and that would > allow the AT to be properly audience restricted. > >> > >> > >> This would be a completely new approach not involving discovery, > logical names for AS, or link relations. > >> > >> Effectively this code_challenge method becomes a signature over parts > of the request and the implicit audience of the token_endpoint URI. > >> > >> People keep asking why PKCE doesn=E2=80=99t stop these attacks, and it= won=E2=80=99t > with the current PKCE methods, however a new method along the lines I > sketched out may let it work, or I could be completely wrong. > > > > Once you have written down something more definite I promise to > implement it promptly such that we can do interop > > testing early in the process. > > > > Before John brought up this new PKCE mode I was on the Option A side of > the fence now I=E2=80=99d like to see more > > of this PKCE idea before committing to one or the other. > > > > =E2=80=94 Roland > > > > =E2=80=9DEverybody should be quiet near a little stream and listen." > > From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1134f04c41efa8052c818422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2016= =E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 8:17 John Bradley <ve7jtb@ve7jtb.com>:
[..snip.= .]=C2=A0

This is not stoping the attack it is protecting code.
=
IMHO, this is the right approach. We should solve the proble= m architecturally rather than bandaging the hols.=C2=A0
=C2=A0

I should point out that some of the attacks like man in the middling regist= ration can still compromise the client secret, making it possible for an at= tacker to impersonate a client.

In case of the dyn-reg, the client really should make sure th= e identity of the registration endpoint it is talking to through TLS certs = checking. This is the right way of addressing the man-in-the-middle in this= case.=C2=A0
Manual case is hard to fix with a bearer client secr= et. We probably need to do public key crypto. Instead of giving a bearer cl= ient secret, have the client regiser the public key, just like we register = ssh public key all the time with github etc. It should not be too hard at a= ll.=C2=A0


Nat=E2=80=99s option B doesn=E2=80=99t have a solution to that ether as far= as I can tell.

I think the only option for that is to have a logical identifier for the AS= and some sort of discovery check at registration to be certain that you ar= e using the correct registration location.

<= div>How does it help with preventing the client credential theft through mi= tm during the registration? Client secret is already gone by the time you d= o the discovery.=C2=A0
=C2=A0

Option A plus discovery works for that and mitigates confused client but no= t cut and paste.

We still have a problem with AT leaking.=C2=A0 =C2=A0I think that needs to = be dealt with separately.
Access tokens should have a audience (by value or by introspection) the cli= ent needs to tell the AS what resource it want s to use the token at and ha= ve that included as the audience or the request rejected because it is an i= nvalid audience.

Is not the scope the i= mplicit combination of the resource, the endpoint form which you can access= the resource, =C2=A0and operation?=C2=A0
=C2=A0

That should happen at the token endpoint for code.
And, that's why we can send scope there.=C2=A0
Th= e response can also include scope, which is good but my problem here is tha= t scope value in the response would be a bit too vague. Either having the u= ri from which the client can get the list of the resource endpoint, or get = them as RFC5988 header would be nicer.=C2=A0
=C2=A0
For implicit it would need to be at the authoriation endpoint and the audie= nce would need to be echoed back to prevent tampering.

For a javascript client that is interacting with the author= ization endpoint, getting them in the response header would be great.=C2=A0=
For a client that is getting the response through browser redire= ct, the audience value needs to be protected by PKCE response or something.= =C2=A0
=C2=A0

The AT can also be protected by POP so I think that code and AT should be k= ept separate issues.=C2=A0

John B.


> On Feb 23, 2016, at 9:59 PM, Roland Hedberg <roland.hedberg@umu.se> wrote: >
> In line !
>
>> 22 feb 2016 kl. 05:08 skrev John Bradley <ve7jtb@ve7jtb.com>:
>>
>>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrot= e:
>>>
>>> The risk impact of [case2] is more OAuth specific. The token i= s stolen as the token is going to be sent to a rogue resource, and the reso= urce can use that to obtain the resource that was supposed to be only avail= able to the proper client.
>>>
>>> The risk impact of [case3] is the most grave among these three= . Now the attacker can create his own client that impersonates the compromi= sed client.
>>>
>>> OAuth-mix-up
>>> ---------------------------
>>> OAuth-mix-up draft gives one way of addressing [case2] by intr= oducing a new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2= =80=9D to RFC6749. It also returns client_id and verifies it in 4.2, but if= the BadAS has assigned a same client_id to the client, it does not help. >>
>> Client_id are not guaranteed to be unique.=C2=A0 They need to be n= ame spaced by the AS.=C2=A0 =C2=A0In OAuth currently we have no name for th= e AS this makes that difficult, the client can use the authorization endpoi= nt URI, but that logic may well break in multi tenant situations.=C2=A0 =C2= =A0Having a clear issuer string makes it easier for the client.
>
> I stumbled over exactly this point when I made my implementation follo= w the Mix-Up draft.
> If not discovery is involved I think an AS has to have a name which is= different from the endpoint URIs.
>
>>> One of the issue with this approach is that the central notion= of =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. Th= e verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the a= uthorization server that the client received when it registered at the auth= orization server=E2=80=9D, but in most existing pure OAuth cases, there is = no such thing, so you cannot compare. This means that you would have to re-= register, and if you are doing that, the per-AS redirect_uri seems to be a = much simpler solution.
>>
>> The client developers I have talked to really hate per AS redirect= URI as being too awkward for deployments.
>
> I on the other hand found it quite easy to do per AS redirect URIs, so= it might well be implementation
> dependent rather then contextual.
>
>>>
>>> Per AS Redirect URI
>>> --------------------------------
>>> This does not involve wire protocol changes. It just adds requ= irements on the redirect uri. This by far is the simplest solution for [cas= e2] (and [case1]), IMHO.
>>>
>>> Again, it is not a general framework for finding out tainted c= ommunication, so it may have other holes.
>>
>> This is probably the hardest for the client developer and for the = deployer.=C2=A0 Yes it is simplest from a spec point of view.
>> We need more developer feedback on this.
>
> As I said above I found this quite simple to implement.
>
>>> (Extended) PKCE
>>> ---------------------------------
>>> To begin with, it works only with code flow. There has to be s= omething else to deal with implicit flow.
>>>
>>> PKCE binds the authorization request/response to the token req= uest.
>>> If used with a confidential client, it seems to mitigate the v= ulnerability.
>>> John points out that it is not the case. I must be missing som= ething here=E2=80=A6 but my logic goes like:
>>>
>>>
>>> 1.=C2=A0 =C2=A0 =C2=A0The good client creates code_challenge-v= and code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + c= ode_challenge-v + state to the BadAS Authz EP.
>>> 2.=C2=A0 =C2=A0 =C2=A0BadAS as a client prepares a code_verifi= er-b and code_challenge-b=3DS256(code_verifer-b).
>>> 3.=C2=A0 =C2=A0 =C2=A0BadAS redirects to GoodAS with the clien= t_id-v + code_challenge-b + state-v.
>>> 4.=C2=A0 =C2=A0 =C2=A0GoodAS stores the code_challenge-b.
>>> 5.=C2=A0 =C2=A0 =C2=A0GoodAS returns code-v + state-v to the c= lient=E2=80=99s redirect uri.
>>> 6.=C2=A0 =C2=A0 =C2=A0The client finds the AS from the state a= nd sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. N= ow, code-v and code_verifer-v is phished.
>>>
>>> Now the attacker tries to use the code-v and code_verifier-v.<= br> >>>
>>> ### Case A:
>>> 7.=C2=A0 =C2=A0 =C2=A0The BadAS as a client sends client_id-v = + =E2=80=A6 but he does not have client secret for the good client, so it f= ails.
>>>
>>> ### Case B:
>>> 8.=C2=A0 =C2=A0 =C2=A0The BadAS as a client sends client_id-b = + code-v + code_verifier-b + secret-b etc. to GoodAS.
>>> 9.=C2=A0 =C2=A0 =C2=A0GoodAS verifies the code_verifier-b is a= ssociated with code-v, but that code-v is not associated with client_id-b, = so the token request fails.
>>>
>>> ### Case C: cut-n-paste
>>> 10.=C2=A0 The attacker launches cut-n-paste attack by replacin= g the code-b with code-v.
>>> 11.=C2=A0 The verifiers does not match, so fails.
>>>
>>> Please let me know what I am missing.
>>
>> In a step 0 the attacker has the good client create another reques= t in the attackers user agent to get state-0 and code_challange-0
>>
>> Step 2 is not required.
>> Step 3 Bad AS redirects to good AS with client_id_v + state-v + co= de_challenge-0
>> Step 4 GoodAS stores code_challenge-0
>> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri=
>> Step 6 The client finds the AS from the state and sends code-v + c= ode_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code= _verifer-v is phished.
>>
>> Case C1 :=C2=A0 cut and paste
>> 10.=C2=A0 The attacker launches cut-n-paste attack by inserting co= de-v into a response using state-0
>> 11. The client sends code-v and based on state-0 it sends code_ver= ifyer-0 to the good AS token endpoint.
>> 12. The GoodAS verifies that code-verifyer-0 is correct for code_c= hallange-0 that it bound to code in step 4
>> 13. The GoodAS receives RT + AT.
>> 14. The attacker has now used the client to bind the users resourc= e to it=E2=80=99s account and is transferring money or looking at your data= .
>>
>> This could be 3rd party financial app like Mint as an example or p= hotos or any other PII that could then be used to escalate identity theft.<= br> >>
>> This variation of the attack combining cut and paste with confused= client was not mentioned in the research papers.
>>
>> I found it looking to see if PKCE could be used to mitigate the co= nfused client attack.
>>
>> As I mentioned in a response to William, while the current PKCE Ch= allenge methods only make the attack harder by forcing the attacker to get = the client to make a step 0 request to get a code_challenge to use in the r= equest,=C2=A0 we could define a new challenge method that would be effectiv= e.
>>
>> That would remove the need to have a separate mechanism to prevent= cut and paste.
>>
>> The problem is that the PKCE challenge is independent of state so = becomes vulnerable to the confused client.
>>
>> What we would need to do is include state in the challenge so that= if the AS receives mismatched state and code_challange in step 3 the verif= ication of code verifier will fail. Effectively combining the cut and paste= mitigation with PKCE.
>>
>> I haven=E2=80=99t had time to write this up, but if the code_chall= enge =3D=3D SHA256 (SHA256(state) || token_endpoint URI || Authorization_en= dpoint URI || client_id || code-veriyer) ,=C2=A0 then the attacker could no= t change state, client_id, or token_endpoint=C2=A0 independently of code_ch= allenge.=C2=A0 (note I am using a hash of state to make storage size determ= inistic for the AS on the grounds that the client already needs to be able = to do the hash) (Some attacks=C2=A0 change the client_id in the request so = I am including it in the hash)
>>
>> This is slightly more complicated than than S256, but not that muc= h.=C2=A0 I wish I had thought of this when we were doing PKCE.=C2=A0 =C2=A0= Hit me with the stupid stick, my fault.
>>
>> I don=E2=80=99t know if it stops all the confused client attacks t= hough.
>>
>> If the client is confidential then it gives up it=E2=80=99s client= secret assuming compromised registration, so we can=E2=80=99t really count= on that for symmetric client authentication.
>>
>> By including the token endpoint in the comparison if the client is= sending the code to the attacker the client will use a different token end= point_uri in to calculate the code_challenge than the GoodAS will use to ve= rify it.=C2=A0 =C2=A0 This would stop both cut and paste as well as stoppin= g the attacker from using the code if they get it.=C2=A0 =C2=A0The attacker= can=E2=80=99t get Secret for state-0, so it can=E2=80=99t create code_chal= lenge that would be valid.
>>
>> This stops the registration attack where the client gets a bad AS = discovery endpoint that has all the Good AS info including dynamic registra= tion endpoint but the bad AS token endpoint.=C2=A0 =C2=A0The bad AS would g= et the token, client_secret and code_verier, but will fail pkce verificatio= n because the token endpoint will be wrong.
>>
>> The attack where the client registers with the good AS but with ba= d token endpoint and Authorization endpoint gives the attacker the ability = to change the code_challenge that the Good AS is going to see.=C2=A0 =C2=A0= It would need to make a new challenge using state and the GoodAS token endp= oint and it=E2=80=99s client_id.
>> To do that it needs the code_verifier to use to calculate the hash= to use as the code_challenge value.=C2=A0 As long as the client is not tri= cked into accepting a replay of the authentication response we should be sa= fe.=C2=A0 The client would need to do replay protection on the code_verifie= r values before it makes a request to the token endpoint.
>>
>> The BadAS could however make up a new code_challenge and code_veri= fier and use that in the request. For this one the AS would need to do pull= discovery on the client to get a key, or the AS needs to return something = in the response.=C2=A0 This attack can completely proxy all the endpoints a= s far as the client is concerned and is taking advantage of the AS saying y= ou are granting permission to site X based on the redirect URI.
>>
>> I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a = client from being used as a redirector back to the attacker unless you also= returned the code_challenge in the response from the authorization endpoin= t.
>>
>> Hypothetically if we returned code_challenge in the response from = the authorization endpoint and have a new PKCE challenge method we might fi= nd it covers all of the attacks.
>>
>> We would need to put some serious analysis into this to see if it = really covers all the attacks.
>>
>> It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D res= ponse_type or steeling the access token by impersonating the RS.
>>
>> I think the correct way to stop the problem with access tokens is = by audience restricting them.
>> To do that the client needs to provide an audience in it=E2=80=99s= request and the AS needs to include that in the AT.
>>
>> I included the Authorization_endpoint URI in the hash to detect if= the auth request may have been tampered with to change the audience for th= e AT.
>>
>> For implicit we could have a version of PKCE where the AS returns = a parameter with S256( client_id || authorization_endpoint URI || resource = endpoint URI) to verify the request was not tampered with, and that would a= llow the AT to be properly audience restricted.
>>
>>
>> This would be a completely new approach not involving discovery, l= ogical names for AS, or link relations.
>>
>> Effectively this code_challenge method becomes a signature over pa= rts of the request and the implicit audience of the token_endpoint URI.
>>
>> People keep asking why PKCE doesn=E2=80=99t stop these attacks, an= d it won=E2=80=99t with the current PKCE methods,=C2=A0 however a new metho= d along the lines I sketched out may let it work, or I could be completely = wrong.
>
> Once you have written down something more definite I promise to implem= ent it promptly such that we can do interop
> testing early in the process.
>
> Before John brought up this new PKCE mode I was on the Option A side o= f the fence now I=E2=80=99d like to see more
> of this PKCE idea before committing to one or the other.
>
> =E2=80=94 Roland
>
> =E2=80=9DEverybody should be quiet near a little stream and listen.&qu= ot;
> From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1134f04c41efa8052c818422-- From nobody Wed Feb 24 03:47:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799331A906E for ; Wed, 24 Feb 2016 03:47:24 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YMgHj3T7Ex5 for ; Wed, 24 Feb 2016 03:47:22 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB16B1A9067 for ; Wed, 24 Feb 2016 03:47:21 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id b205so30982005wmb.1 for ; Wed, 24 Feb 2016 03:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pyAFEjbZZXS5FxUOn2Us0mJG/u9gbih5NPKujf14qVI=; b=NeFObEJONY+IqymYHdzd4bmm+QMoXE1QQpMof22I8B0eG3R9BlN9iCNifLmpep1fR2 TIN7zhsWBnM/DxJnW8YPL6ovLoaBmM3NHe0G4sFGHnbpl3Q9hIwoX1rQbSREXVw4JiWo tk6jwE2FtFvz8T3h9Ms1/B7pMmPE2uLDQDLzjAO7Uaz59W1YbA6sgE946Ca6Cgb8WvJm 9F+2KnMyAe73A5/A2eEQGhzCr0dAPawHprx9j7n5+EW6scdHyk0kc7tzle8N8weLgnix wHbfl9jh5PKngyq7TUa1PU69EDvDNA0PpUhEJ6UVuHuoOXhetaGcB8o/S27ySgoZNtfQ UZIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pyAFEjbZZXS5FxUOn2Us0mJG/u9gbih5NPKujf14qVI=; b=FRxufGWtxeX0E2A8PrNbxvSG9VtHBB35hU9bhj7NslhWu/wOXtw7tsrJ99oly1gvwo IpzfLMgZ+iaaamybYM5vzrwr+vEj8yTnzI48OENp+thl27wfopDWo9TWXGlZXb+/xq4f eoQY2gmUxvSwGUgt9brqpm+J+xzd/kE2sqyA90A/Mt/oUr0DKAOPnWJETTCXYZSjBCDr wTbktRy66p4fgjjIpMWeP9Avc1kt9PeLTpEY3gaNyxDpBGGhvcnWgGWqwU5ZqekCVPFj qIA0lYCurxQgmNdbAUnJNtGvFE8k/5OhXDe7IMWkQXpDMknqDaGWHTEkWi0d4ZS71GcV KPyA== X-Gm-Message-State: AG10YOQlaVZiM6FJ9uciID/WzNK6yPb/+R3jAj7eagTc5oWR9gYb5pi22lJWmGZT7/y+ug== X-Received: by 10.194.185.199 with SMTP id fe7mr38483685wjc.50.1456314440227; Wed, 24 Feb 2016 03:47:20 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id t12sm30826561wmt.20.2016.02.24.03.47.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 03:47:19 -0800 (PST) References: <56CD9557.3080709@connect2id.com> To: "oauth@ietf.org" From: Sergey Beryozkin X-Forwarded-Message-Id: <56CD9557.3080709@connect2id.com> Message-ID: <56CD9847.1010206@gmail.com> Date: Wed, 24 Feb 2016 11:47:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CD9557.3080709@connect2id.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] JWS Access Token concerns X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:47:24 -0000 Hi All I inadvertently started a private thread when replying to Vladimir, I spotted it only now. Forwarding it back to the list. Vladimir - many thanks Sergey -------- Forwarded Message -------- Subject: Re: [OAUTH-WG] JWS Access Token concerns Date: Wed, 24 Feb 2016 13:34:47 +0200 From: Vladimir Dzhuvinov Organization: Connect2id Ltd. To: Sergey Beryozkin I see, tokens encrypted to self! Yes, that can work pretty well. And you can still have revocation, by keeping a table or cache of the revoked tokens (identified by "jti" or hash). Happy coding! On 24/02/16 12:35, Sergey Beryozkin wrote: > Hi Vladimir > > Yes - it helps :-) I was not really planning to start a 'campaign' > against JWS tokens but rather reacted to the fact that I was able to > see more inside the JWS token on the OAuth2 client side than were > visible in the standard access token response (access_token, > expires_in, etc, with access_token carrying a lot more inside itself). > > We are planning to support self-contained tokens but right now I'm > inclined to offer a JWE option only (without JWS) and also a JWS if > needed (of course without sticking the sensitive parts inside of it :-)). > > The reason I think a JWE-only option is effective is because I'm not > sure RS needs to do an immediate validation it was issued by a given > AS - it can simply post this JWE token to AS it is linked to and AS, > if it can decrypt it using its private key will tell back, using the > standard introspection response all RS needs to know, no need to share > the encryption key with RS. > > Same for JWS tokens. Though not sure how PoP tokens will be validated > - we haven't started using them yet and as far as I recall the > introspection spec is not talking about them. > > > Cheers, Sergey > > > On 24/02/16 10:19, Vladimir Dzhuvinov wrote: >> RFC 6749 is essentially a framework (it even says it in the title), >> which means there are plenty of ways to shoot yourself in the foot :) >> >> If our experience can be of help: The Connect2id server can issue >> identifier as well as JWT access tokens, depending on policy. >> >> The JWT is signed by default. There are no claims in it that the client >> doesn't know already - subject, client_id, granted scope. >> >> There is also an optional "dat" (data) field if the AS / OP wants to >> stick additional data for use by the RS. >> >> If integrators want confidentiality of that "data", the JWT can be >> additionally encrypted with a key that is shared between OP and RS >> instances. That way the token authenticity can still be verified by RS >> after decryption. The encryption key is shared, based on the assumption >> that the "data" is shared knowledge between AS / OP and all RS >> instances. There haven't been requests from customers to make data >> confidential for a specific RS (yet). >> >> Now back to reading more sec papers :) Universe must have a way through >> the latest sec issues. >> >> Vladimir >> >> On 24/02/16 11:47, Sergey Beryozkin wrote: >>> Hi >>> On 24/02/16 05:07, Vladimir Dzhuvinov wrote: >>>> Hi there, >>>> >>>> On 23/02/16 23:35, Sergey Beryozkin wrote: >>>>> Hi Vladimir >>>>> >>>>> May be I did not express my query well. >>>>> When we talk about the access tokens, it is what OAuth2 access token >>>>> service returns to the client - it does not have to be JWT, right ? >>>> >>>> No, as long as it can work as a token. That is, allow the RS to >>>> determine whether the client can run the request or not, and be sure >>>> that token (and the associated authorisation) come from the AS. >>>> >>>> You've probably looked at the spec: >>>> >>>> http://tools.ietf.org/html/rfc6749#section-1.4 >>>> >>>> http://tools.ietf.org/html/rfc6749#section-7.1 >>>> >>> Thanks for your patient explanation, but I'm sorry I was not looking >>> for that :-), I'd like to believe I've got what access tokens are for >>> and how they are supposed to be validated :-). I'm sorry, it is my >>> fault. >>> >>> >>>> >>>>> It is perfectly fine to return a DB pointer, OAuth2 talks about such >>>>> access tokens. >>>> Yes. Identifier (key) based tokens have the effect that revoking them >>>> has an immediate effect, so for high security apps their are optimal. >>>> But processing them on the RS side them takes a network call to the >>>> inspection point. >>>> >>>> RSA signed JWTs take on the other hand about 50us to verify. >>>> >>>>> The client should not care. The client is not supposed to start >>>>> processing access_token the way it can process the id_token. >>>>> It is only something the client will use when accessing RS and >>>>> clearly >>>>> the 'plain' bearer tokens are full citizens here. >>>>> >>>>> What I'm saying that in fact a client can easily read a JWS-signed >>>>> access token content - today I saw some internal properties of a 3rd >>>>> party provider which I'm not sure are meant to be visible to the >>>>> client at all. >>>> >>>> If that's sensitive information that shouldn't be seen by client or >>>> user, then I suggest you report your finding. >>>> >>> This is what I'm doing here. I've no time engaging with the individual >>> provider's implementers but rather is trying to ask a question to the >>> group, how sensitive can it be that someone like me can just paste a >>> content of the JWS token into my code and check how AT is represented >>> internally. >>> >>>>> I don't mind much - but it seems it goes completely against the >>>>> OAuth2 >>>>> saying the access tokens are supposed to be opaque to the client - >>>>> JWS-signed tokens are not. >>>> >>>> Well, the exact qualifier is "usually opaque" :) >>> >>> Well, it is not :-) >>> >>> Either way, thanks for the time... >>> >>> Sergey >>> >>>> >>>>> The string is usually opaque to the client. >>>> >>>> >>>> Vladimir >>>>> >>>>> Sergey >>>>> >>>>> On 23/02/16 19:41, Vladimir Dzhuvinov wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> JWE will indeed make the token content confidential to clients. >>>>>> However, >>>>>> without a proper signature (RSA or EC, HMAC in JWS doesn't >>>>>> qualify), the >>>>>> RS cannot establish the origin of the token. With symmetric crypto >>>>>> (e.g. >>>>>> JWE alg=dir) anyone who has the shared key will be able to create a >>>>>> token (e.g. other RS in the domain that rely on the AS). With >>>>>> asymmetric >>>>>> crypto, anyone with access to the public key of the RS will be >>>>>> able to >>>>>> encrypt for the recipient. >>>>>> >>>>>> Hope this helps, >>>>>> >>>>>> On 23/02/16 19:15, Sergey Beryozkin wrote: >>>>>>> Hi >>>>>>> >>>>>>> Some OAuth2 providers may return self-contained access tokens which >>>>>>> are JWS Compact-encoded. >>>>>>> I wonder is it really a good idea and would it not be better to >>>>>>> only >>>>>>> JWE-encrypt the tokens. I'm not sure JWS signing the claims is >>>>>>> necessarily faster then only encrypting the claims, assuming the >>>>>>> symmetric algorithms are used in both cases. >>>>>>> >>>>>>> For example, my colleague and myself, while dealing with the issue >>>>>>> related to parsing an access token response from a 3rd party >>>>>>> provider >>>>>>> were able to easily check the content of the JWS-signed >>>>>>> access_token >>>>>>> by simply submitting an easily recognized JWS Compact-formatted >>>>>>> value >>>>>>> (3 dots) into our JWS reader - we did not have to worry about >>>>>>> decrypting it neither the fact we did not validate the signature >>>>>>> mattered. >>>>>>> >>>>>>> But access tokens are opaque values as far as the clients are >>>>>>> concerned and if the introspection is needed then the introspection >>>>>>> endpoint does exist for that purpose... >>>>>>> >>>>>>> Thanks, Sergey >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>> >>> >> > -- Vladimir Dzhuvinov :: vladimir@connect2id.com From nobody Wed Feb 24 03:55:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BE01A912A for ; Wed, 24 Feb 2016 03:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhJ5JrKUmNzH for ; Wed, 24 Feb 2016 03:55:00 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 B51691A9128 for ; Wed, 24 Feb 2016 03:54:59 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id b67so11439763qgb.1 for ; Wed, 24 Feb 2016 03:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=EtkqNABlZUlOP7zOw/xCqxuNxLjqbvRbWyQFOK3KXeI=; b=WAqCB9Yr/NQPCDIEDQaUs22dPcHkmO05rAfxPI32SR3ZwS1jVz6AqBjFxGCJUahJIj IcUs21efKsHiAxPmpXPwqQl551z2rK5u+lmogqZL30jK9Lvq0geG1FHvMUhCN0jeNUSc EnC4D/XApBtBPAmeUSbkxdMURQeFdD3nuP6bygtBsFdJjtSxkl27BGI29p2fFrl0yFXh 3MSya73RK/aJPLUZCF8j/F4inoma3hiczF8pHMx9ZW9hZc7cKEOAtnbKkweknyhG1DPj bEMdWnAM4jP5bOSMukBbPUD/iy2V8K9w+P0ksRJu7BeSjHVZmhPsvXQv84xJHnTjyyIq 2C/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=EtkqNABlZUlOP7zOw/xCqxuNxLjqbvRbWyQFOK3KXeI=; b=SFNfirvuQE00VhHYbyojBADWzLOflYeQQ9SeSF/eKd+h+hN0xJu9qvu8yQGBQTjDAu +fRXcf56Z0hIBjxJpksAo3ziCLq8bMKYUku9q8ZFTeRdLav8MC729z/6AQcUjCUhaCtM MXeJR3wjinTOP5ZAEhCm1DXSA2BHbbi1or2aR/CGmoJiQDVx7laQhv9G9V2dIDp+eKrY KrJlBADsNctSu0S25t4R82rumHQbhoAShawcRgPpbvUXm+77aB537sn7ZDvbRjfX1Zfn SNQi50z2vdWpYHO8/NfXb7/+cVUG5hepp3QV06Xk0JFK1BPCZSCb3af1Tqse2cuDsPhg gPlw== X-Gm-Message-State: AG10YOSnUEH9ah0OIzCc9z12D7r9wYGwNs4BBpUeNK+w4Oio6SyXPrSisPL4k2D9RCpVLIQ7bdVQBlXWjltdMw== X-Received: by 10.140.96.84 with SMTP id j78mr46595533qge.93.1456314898861; Wed, 24 Feb 2016 03:54:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Wed, 24 Feb 2016 11:54:49 +0000 Message-ID: To: Thomas Broyer , Justin Richer , "" Content-Type: multipart/alternative; boundary=001a113ab5443a5618052c82bcf5 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:55:06 -0000 --001a113ab5443a5618052c82bcf5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thomas, inline: 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer : > Couldn't the document only describe the metadata? > I quite like the idea of draft-sakimura-oauth-meta if you really want to > do discovery, and leave it open to implementers / to other specs to defin= e > a .well-known URL for "auto-configuration". > The metadata described here would then either be used as-is, at any URL, > returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis f= or > other metadata specs (like OpenID Connect). > With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of > WWW-Authenticate response header, you have everything you need to proceed > Yup. That's one of the requirements to be RESTful, is it not? In OAuth's case, the resource and the authorization server are usually tightly coupled. (Otherwise, you need another specs like UMA.) So, the resource server should be able to tell either the location of the authz endpoint. In some trusted environment, the resource may as well return the location of the authz server configuration data. In these cases, you do not have to decide on what .well-known uri as you say. This frees up developers from configuration file location collisions etc. We should strive not to pollute the uri space as much as possible. > (well, except if there are several ASs each with different scopes; sounds > like an edge-case to me though; maybe RFC6750 should instead be updated > with such a parameter such that an RS could return several > WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?) > Yeah, I guess it is an edge case. I would rather like to see these authz servers to develop a trust framework under which they can agree on a single set of common scope parameter values. Cheers, Nat > > On Fri, Feb 19, 2016 at 10:59 PM Justin Richer wrote: > >> The newly-trimmed OAuth Discovery document is helpful and moving in the >> right direction. It does, however, still have too many vestiges of its >> OpenID Connect origins. One issue in particular still really bothers me: >> the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the di= scovery portion. Is >> this an OAuth discovery document, or an OpenID Connect one? There is >> absolutely no compelling reason to tie the URL to the OIDC discovery >> mechanism. >> >> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server= =E2=80=9D as the >> default discovery location, and state that the document MAY also be >> reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if th= e server also >> provides OpenID Connect on the same domain. Other applications SHOULD us= e >> the same parameter names to describe OAuth endpoints and functions insid= e >> their service-specific discovery document. >> >> =E2=80=94 Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113ab5443a5618052c82bcf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Thomas,=C2=A0

inline:=C2=A0

2016=E5=B9=B42=E6=9C= =8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com>:
Couldn't the document only describe the metadata= ?
I quite like the idea of=C2=A0draft-sakimura-oauth-meta if you really= want to do discovery, and leave it open to implementers / to other specs t= o define a .well-known URL for "auto-configuration".
Th= e metadata described here would then either be used as-is, at any URL, retu= rned as=C2=A0draft-sakimura-oauth-meta metadata at the RS; or as a basis fo= r other metadata specs (like OpenID Connect).=C2=A0
With=C2=A0draft-= sakimura-oauth-meta's "duri" and the "scope" attrib= ute of WWW-Authenticate response header, you have everything you need to pr= oceed

Yup. That's on= e of the requirements to be RESTful, is it not? =C2=A0

=
In OAuth's case, the resource and the authorization server are usu= ally tightly coupled. (Otherwise, you need another specs like UMA.)=C2=A0
So, the resource server should be able to tell either the location= of the authz endpoint. In some trusted environment, the resource may as we= ll return the location of the authz server configuration data. In these cas= es, you do not have to decide on what .well-known uri as you say. This free= s up developers from configuration file location collisions etc. We should = strive not to pollute the uri space as much as possible.=C2=A0
= =C2=A0
(well= , except if there are several ASs each with different scopes; sounds like a= n edge-case to me though; maybe RFC6750 should instead be updated with such= a parameter such that an RS could return several WWW-Authenticate: Bearer,= each with its own "scope" and "duri" value?)

Yeah, I guess it is an edge case. = I would rather like to see these authz servers to develop a trust framework= under which they can agree on a single set of common scope parameter value= s.=C2=A0

Cheers,=C2=A0

Na= t

=


On Fri, Feb 19, 20= 16 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in= the right direction. It does, however, still have too many vestiges of its= OpenID Connect origins. One issue in particular still really bothers me: t= he use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discov= ery portion. Is this an OAuth discovery document, or an OpenID Connect one?= There is absolutely no compelling reason to tie the URL to the OIDC discov= ery mechanism.

I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2= =80=9D as the default discovery location, and state that the document MAY a= lso be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D i= f the server also provides OpenID Connect on the same domain. Other applica= tions SHOULD use the same parameter names to describe OAuth endpoints and f= unctions inside their service-specific discovery document.

=C2=A0=E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113ab5443a5618052c82bcf5-- From nobody Wed Feb 24 04:40:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDA81ACEE6 for ; Wed, 24 Feb 2016 04:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgXr7DySKsHB for ; Wed, 24 Feb 2016 04:40:07 -0800 (PST) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47221ACEE7 for ; Wed, 24 Feb 2016 04:40:06 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa07-07.prod.phx3.secureserver.net with id NCg41s00915ZTut01Cg5At; Wed, 24 Feb 2016 05:40:06 -0700 To: oauth@ietf.org References: <56C7702B.2000401@gmx.net> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56CDA4A3.9010702@connect2id.com> Date: Wed, 24 Feb 2016 14:40:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080301070506030703040206" Archived-At: Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 12:40:13 -0000 This is a cryptographically signed message in MIME format. --------------ms080301070506030703040206 Content-Type: multipart/alternative; boundary="------------020109030101030803040706" This is a multi-part message in MIME format. --------------020109030101030803040706 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments inline. On 24/02/16 12:27, Nat Sakimura wrote: > 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 8:17 John Bradley : > [..snip..] > >> This is not stoping the attack it is protecting code. >> > IMHO, this is the right approach. We should solve the problem > architecturally rather than bandaging the hols. > > >> I should point out that some of the attacks like man in the middling >> registration can still compromise the client secret, making it possibl= e for >> an attacker to impersonate a client. > > In case of the dyn-reg, the client really should make sure the identity= of > the registration endpoint it is talking to through TLS certs checking. = Looking at the unfolding situation, I also tend to agree with that. Once initial AS / IdP discovery (and subsequent client reg) is compromised, I don't see a way to reliably recover from that further down the line: * The bad AS/IdP can act as a reg proxy, and rewrite reg requests / responses. Even if the client requests private_key_jwt auth, the attacker can rewrite that to client_secret_basic. Unless private_key_jwt is made mandatory for all dynamic regs :) * The bad AS/IdP can also potentially proxy the redirect to / from the honest authorisation endpoint. Augmented PKCE and returning select AS parameters will not prevent the ultimate impersonation of the user in that case. * The token requests to the AS/IdP can be intercepted, as previously discussed here and elsewhere. > This > is the right way of addressing the man-in-the-middle in this case. > Manual case is hard to fix with a bearer client secret. We probably nee= d to > do public key crypto. Instead of giving a bearer client secret, have th= e > client regiser the public key, just like we register ssh public key all= the > time with github etc. It should not be too hard at all. +1 I've got two questions: 1. Is it fundamentally possible to solve MitM attacks, without having reliable client authentication in place? 2. Is it possible to have reliable client authentication without crypto? (with client_secret_basic) It appears to me that the answer to both questions is negative, and we cannot really get around crypto and expect to solve these problems :) The extended PKCE solution that John Bradley wrote about seems to admit just that. We start hashing parameters, which is crypto already :) I think the solution will crystallise once we clear these fundamental questions. And if it turns out that there is no real way around crypto, and that is proved, that message and the required changes would be easier to communicate to the developers. > >> Nat=E2=80=99s option B doesn=E2=80=99t have a solution to that ether a= s far as I can tell. >> >> I think the only option for that is to have a logical identifier for t= he >> AS and some sort of discovery check at registration to be certain that= you >> are using the correct registration location. >> > How does it help with preventing the client credential theft through mi= tm > during the registration? Client secret is already gone by the time you = do > the discovery. > > >> Option A plus discovery works for that and mitigates confused client b= ut >> not cut and paste. >> >> We still have a problem with AT leaking. I think that needs to be de= alt >> with separately. >> Access tokens should have a audience (by value or by introspection) th= e >> client needs to tell the AS what resource it want s to use the token a= t and >> have that included as the audience or the request rejected because it = is an >> invalid audience. >> > Is not the scope the implicit combination of the resource, the endpoint= > form which you can access the resource, and operation? > > >> That should happen at the token endpoint for code. >> > And, that's why we can send scope there. > The response can also include scope, which is good but my problem here = is > that scope value in the response would be a bit too vague. Either havin= g > the uri from which the client can get the list of the resource endpoint= , or > get them as RFC5988 header would be nicer. > > >> For implicit it would need to be at the authoriation endpoint and the >> audience would need to be echoed back to prevent tampering. >> > For a javascript client that is interacting with the authorization > endpoint, getting them in the response header would be great. > For a client that is getting the response through browser redirect, the= > audience value needs to be protected by PKCE response or something. > > >> The AT can also be protected by POP so I think that code and AT should= be >> kept separate issues. > >> John B. >> >> >>> On Feb 23, 2016, at 9:59 PM, Roland Hedberg >> wrote: >>> In line ! >>> >>>> 22 feb 2016 kl. 05:08 skrev John Bradley : >>>> >>>>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura >> wrote: >>>>> The risk impact of [case2] is more OAuth specific. The token is sto= len >> as the token is going to be sent to a rogue resource, and the resource= can >> use that to obtain the resource that was supposed to be only available= to >> the proper client. >>>>> The risk impact of [case3] is the most grave among these three. Now= >> the attacker can create his own client that impersonates the compromis= ed >> client. >>>>> OAuth-mix-up >>>>> --------------------------- >>>>> OAuth-mix-up draft gives one way of addressing [case2] by introduci= ng >> a new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80= =9D to RFC6749. It also returns >> client_id and verifies it in 4.2, but if the BadAS has assigned a same= >> client_id to the client, it does not help. >>>> Client_id are not guaranteed to be unique. They need to be name spa= ced >> by the AS. In OAuth currently we have no name for the AS this makes = that >> difficult, the client can use the authorization endpoint URI, but that= >> logic may well break in multi tenant situations. Having a clear issu= er >> string makes it easier for the client. >>> I stumbled over exactly this point when I made my implementation foll= ow >> the Mix-Up draft. >>> If not discovery is involved I think an AS has to have a name which i= s >> different from the endpoint URIs. >>>>> One of the issue with this approach is that the central notion of >> =E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. T= he verification rule >> in 4.1 states =E2=80=9CCompare the issuer URL for the authorization se= rver that the >> client received when it registered at the authorization server=E2=80=9D= , but in >> most existing pure OAuth cases, there is no such thing, so you cannot >> compare. This means that you would have to re-register, and if you are= >> doing that, the per-AS redirect_uri seems to be a much simpler solutio= n. >>>> The client developers I have talked to really hate per AS redirect U= RI >> as being too awkward for deployments. >>> I on the other hand found it quite easy to do per AS redirect URIs, s= o >> it might well be implementation >>> dependent rather then contextual. >>> >>>>> Per AS Redirect URI >>>>> -------------------------------- >>>>> This does not involve wire protocol changes. It just adds requireme= nts >> on the redirect uri. This by far is the simplest solution for [case2] = (and >> [case1]), IMHO. >>>>> Again, it is not a general framework for finding out tainted >> communication, so it may have other holes. >>>> This is probably the hardest for the client developer and for the >> deployer. Yes it is simplest from a spec point of view. >>>> We need more developer feedback on this. >>> As I said above I found this quite simple to implement. >>> >>>>> (Extended) PKCE >>>>> --------------------------------- >>>>> To begin with, it works only with code flow. There has to be someth= ing >> else to deal with implicit flow. >>>>> PKCE binds the authorization request/response to the token request.= >>>>> If used with a confidential client, it seems to mitigate the >> vulnerability. >>>>> John points out that it is not the case. I must be missing somethin= g >> here=E2=80=A6 but my logic goes like: >>>>> >>>>> 1. The good client creates code_challenge-v and >> code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + >> code_challenge-v + state to the BadAS Authz EP. >>>>> 2. BadAS as a client prepares a code_verifier-b and >> code_challenge-b=3DS256(code_verifer-b). >>>>> 3. BadAS redirects to GoodAS with the client_id-v + >> code_challenge-b + state-v. >>>>> 4. GoodAS stores the code_challenge-b. >>>>> 5. GoodAS returns code-v + state-v to the client=E2=80=99s redi= rect uri. >>>>> 6. The client finds the AS from the state and sends code-v + >> code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v an= d >> code_verifer-v is phished. >>>>> Now the attacker tries to use the code-v and code_verifier-v. >>>>> >>>>> ### Case A: >>>>> 7. The BadAS as a client sends client_id-v + =E2=80=A6 but he d= oes not >> have client secret for the good client, so it fails. >>>>> ### Case B: >>>>> 8. The BadAS as a client sends client_id-b + code-v + >> code_verifier-b + secret-b etc. to GoodAS. >>>>> 9. GoodAS verifies the code_verifier-b is associated with code-= v, >> but that code-v is not associated with client_id-b, so the token reque= st >> fails. >>>>> ### Case C: cut-n-paste >>>>> 10. The attacker launches cut-n-paste attack by replacing the code= -b >> with code-v. >>>>> 11. The verifiers does not match, so fails. >>>>> >>>>> Please let me know what I am missing. >>>> In a step 0 the attacker has the good client create another request = in >> the attackers user agent to get state-0 and code_challange-0 >>>> Step 2 is not required. >>>> Step 3 Bad AS redirects to good AS with client_id_v + state-v + >> code_challenge-0 >>>> Step 4 GoodAS stores code_challenge-0 >>>> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri >>>> Step 6 The client finds the AS from the state and sends code-v + >> code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v an= d >> code_verifer-v is phished. >>>> Case C1 : cut and paste >>>> 10. The attacker launches cut-n-paste attack by inserting code-v in= to >> a response using state-0 >>>> 11. The client sends code-v and based on state-0 it sends >> code_verifyer-0 to the good AS token endpoint. >>>> 12. The GoodAS verifies that code-verifyer-0 is correct for >> code_challange-0 that it bound to code in step 4 >>>> 13. The GoodAS receives RT + AT. >>>> 14. The attacker has now used the client to bind the users resource = to >> it=E2=80=99s account and is transferring money or looking at your data= =2E >>>> This could be 3rd party financial app like Mint as an example or pho= tos >> or any other PII that could then be used to escalate identity theft. >>>> This variation of the attack combining cut and paste with confused >> client was not mentioned in the research papers. >>>> I found it looking to see if PKCE could be used to mitigate the >> confused client attack. >>>> As I mentioned in a response to William, while the current PKCE >> Challenge methods only make the attack harder by forcing the attacker = to >> get the client to make a step 0 request to get a code_challenge to use= in >> the request, we could define a new challenge method that would be >> effective. >>>> That would remove the need to have a separate mechanism to prevent c= ut >> and paste. >>>> The problem is that the PKCE challenge is independent of state so >> becomes vulnerable to the confused client. >>>> What we would need to do is include state in the challenge so that i= f >> the AS receives mismatched state and code_challange in step 3 the >> verification of code verifier will fail. Effectively combining the cut= and >> paste mitigation with PKCE. >>>> I haven=E2=80=99t had time to write this up, but if the code_challen= ge =3D=3D >> SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint = URI >> || client_id || code-veriyer) , then the attacker could not change st= ate, >> client_id, or token_endpoint independently of code_challenge. (note = I am >> using a hash of state to make storage size deterministic for the AS on= the >> grounds that the client already needs to be able to do the hash) (Some= >> attacks change the client_id in the request so I am including it in t= he >> hash) >>>> This is slightly more complicated than than S256, but not that much.= I >> wish I had thought of this when we were doing PKCE. Hit me with the >> stupid stick, my fault. >>>> I don=E2=80=99t know if it stops all the confused client attacks tho= ugh. >>>> >>>> If the client is confidential then it gives up it=E2=80=99s client s= ecret >> assuming compromised registration, so we can=E2=80=99t really count on= that for >> symmetric client authentication. >>>> By including the token endpoint in the comparison if the client is >> sending the code to the attacker the client will use a different token= >> endpoint_uri in to calculate the code_challenge than the GoodAS will u= se to >> verify it. This would stop both cut and paste as well as stopping t= he >> attacker from using the code if they get it. The attacker can=E2=80=99= t get >> Secret for state-0, so it can=E2=80=99t create code_challenge that wou= ld be valid. >>>> This stops the registration attack where the client gets a bad AS >> discovery endpoint that has all the Good AS info including dynamic >> registration endpoint but the bad AS token endpoint. The bad AS woul= d get >> the token, client_secret and code_verier, but will fail pkce verificat= ion >> because the token endpoint will be wrong. >>>> The attack where the client registers with the good AS but with bad >> token endpoint and Authorization endpoint gives the attacker the abili= ty to >> change the code_challenge that the Good AS is going to see. It would= need >> to make a new challenge using state and the GoodAS token endpoint and = it=E2=80=99s >> client_id. >>>> To do that it needs the code_verifier to use to calculate the hash t= o >> use as the code_challenge value. As long as the client is not tricked= into >> accepting a replay of the authentication response we should be safe. = The >> client would need to do replay protection on the code_verifier values >> before it makes a request to the token endpoint. >>>> The BadAS could however make up a new code_challenge and code_verifi= er >> and use that in the request. For this one the AS would need to do pull= >> discovery on the client to get a key, or the AS needs to return someth= ing >> in the response. This attack can completely proxy all the endpoints a= s far >> as the client is concerned and is taking advantage of the AS saying yo= u are >> granting permission to site X based on the redirect URI. >>>> I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a cl= ient from being >> used as a redirector back to the attacker unless you also returned the= >> code_challenge in the response from the authorization endpoint. >>>> Hypothetically if we returned code_challenge in the response from th= e >> authorization endpoint and have a new PKCE challenge method we might f= ind >> it covers all of the attacks. >>>> We would need to put some serious analysis into this to see if it >> really covers all the attacks. >>>> It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D respo= nse_type or steeling the >> access token by impersonating the RS. >>>> I think the correct way to stop the problem with access tokens is by= >> audience restricting them. >>>> To do that the client needs to provide an audience in it=E2=80=99s r= equest and >> the AS needs to include that in the AT. >>>> I included the Authorization_endpoint URI in the hash to detect if t= he >> auth request may have been tampered with to change the audience for th= e AT. >>>> For implicit we could have a version of PKCE where the AS returns a >> parameter with S256( client_id || authorization_endpoint URI || resour= ce >> endpoint URI) to verify the request was not tampered with, and that wo= uld >> allow the AT to be properly audience restricted. >>>> >>>> This would be a completely new approach not involving discovery, >> logical names for AS, or link relations. >>>> Effectively this code_challenge method becomes a signature over part= s >> of the request and the implicit audience of the token_endpoint URI. >>>> People keep asking why PKCE doesn=E2=80=99t stop these attacks, and = it won=E2=80=99t >> with the current PKCE methods, however a new method along the lines I= >> sketched out may let it work, or I could be completely wrong. >>> Once you have written down something more definite I promise to >> implement it promptly such that we can do interop >>> testing early in the process. >>> >>> Before John brought up this new PKCE mode I was on the Option A side = of >> the fence now I=E2=80=99d like to see more >>> of this PKCE idea before committing to one or the other. >>> >>> =E2=80=94 Roland >>> >>> =E2=80=9DEverybody should be quiet near a little stream and listen." >>> From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020109030101030803040706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments inline.

On 24/02/16 12:27, Nat Sakimura wrote:= 
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 8:17 J=
ohn Bradley <ve7jtb@ve7jtb.com>:
[..snip..]


This is not stoping the attack it is protecting code.


IMHO, this is the right approach. We should solve the problem
architecturally rather than bandaging the hols.



I should point out that some of the attacks like man in the middling
registration can still compromise the client secret, making it possible f=
or
an attacker to impersonate a client.


In case of the dyn-reg, the client really should make sure the identity o=
f
the registration endpoint it is talking to through TLS certs checking.

Looking at the unfolding situation, I also tend to agree with that.

Once initial AS / IdP discovery (and subsequent client reg) is compromised, I don't see a way to reliably recover from that further down the line:

* The bad AS/IdP can act as a reg proxy, and rewrite reg requests / responses. Even if the client requests private_key_jwt auth, the attacker can rewrite that to client_secret_basic. Unless private_key_jwt is made mandatory for all dynamic regs :)

* The bad AS/IdP can also potentially proxy the redirect to / from the honest authorisation endpoint. Augmented PKCE and returning select AS parameters will not prevent the ultimate impersonation of the user in that case.

* The token requests to the AS/IdP can be intercepted, as previously discussed here and elsewhere.

This
is the right way of addressing the man-in-the-middle in this case.
Manual case is hard to fix with a bearer client secret. We probably need =
to
do public key crypto. Instead of giving a bearer client secret, have the
client regiser the public key, just like we register ssh public key all t=
he
time with github etc. It should not be too hard at all.

+1

I've got two questions:

1. Is it fundamentally possible to solve MitM attacks, without having reliable client authentication in place?

2. Is it possible to have reliable client authentication without crypto? (with client_secret_basic)


It appears to me that the answer to both questions is negative, and we cannot really get around crypto and expect to solve these problems :)

The extended PKCE solution that John Bradley wrote about seems to admit just that. We start hashing parameters, which is crypto already :)


I think the solution will crystallise once we clear these fundamental questions. And if it turns out that there is no real way around crypto, and that is proved, that message and the required changes would be easier to communicate to the developers.



Nat=E2=80=99s option B doesn=E2=80=99t have a solu=
tion to that ether as far as I can tell.

I think the only option for that is to have a logical identifier for the
AS and some sort of discovery check at registration to be certain that yo=
u
are using the correct registration location.


How does it help with preventing the client credential theft through mitm=

during the registration? Client secret is already gone by the time you do=

the discovery.



Option A plus discovery works for that and mitigates confused client but
not cut and paste.

We still have a problem with AT leaking.   I think that needs to be dealt=

with separately.
Access tokens should have a audience (by value or by introspection) the
client needs to tell the AS what resource it want s to use the token at a=
nd
have that included as the audience or the request rejected because it is =
an
invalid audience.


Is not the scope the implicit combination of the resource, the endpoint
form which you can access the resource,  and operation?



That should happen at the token endpoint for code.


And, that's why we can send scope there.
The response can also include scope, which is good but my problem here is=

that scope value in the response would be a bit too vague. Either having
the uri from which the client can get the list of the resource endpoint, =
or
get them as RFC5988 header would be nicer.



For implicit it would need to be at the authoriati=
on endpoint and the
audience would need to be echoed back to prevent tampering.


For a javascript client that is interacting with the authorization
endpoint, getting them in the response header would be great.
For a client that is getting the response through browser redirect, the
audience value needs to be protected by PKCE response or something.



The AT can also be protected by POP so I think that code and AT should be=

kept separate issues.



John B.



On Feb 23, 2016, at 9:59 PM, Roland Hedberg <=
roland.hedberg@umu.se>

wrote:

In line !


22 feb 2016 kl. 05:08 skrev John Bradley <ve7jt=
b@ve7jtb.com>:


On Feb 22, 2016, at 9:22 AM, Nat Sakimura <=
;n-sakimura@nri.co.jp>

wrote:

The risk impact of [case2] is more OAuth specific. The token is stolen

as the token is going to be sent to a rogue resour=
ce, and the resource can
use that to obtain the resource that was supposed to be only available to=

the proper client.

The risk impact of [case3] is the most grave among these three. Now

the attacker can create his own client that impers=
onates the compromised
client.

OAuth-mix-up
---------------------------
OAuth-mix-up draft gives one way of addressing [case2] by introducing

a new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=
=9Cdiscovery=E2=80=9D to RFC6749. It also returns
client_id and verifies it in 4.2, but if the BadAS has assigned a same
client_id to the client, it does not help.

Client_id are not guaranteed to be unique.  They need to be name spaced

by the AS.   In OAuth currently we have no name fo=
r the AS this makes that
difficult, the client can use the authorization endpoint URI, but that
logic may well break in multi tenant situations.   Having a clear issuer
string makes it easier for the client.

I stumbled over exactly this point when I made my implementation follow

the Mix-Up draft.

If not discovery is involved I think an AS has t=
o have a name which is

different from the endpoint URIs.


          

            

              
One of the issue with this approach is that =
the central notion of


            

          

        

        
=E2=80=9Cissuer=E2=80=9D is new to the existing se=
rvers and clients. The verification rule
in 4.1 states =E2=80=9CCompare the issuer URL for the authorization serve=
r that the
client received when it registered at the authorization server=E2=80=9D, =
but in
most existing pure OAuth cases, there is no such thing, so you cannot
compare. This means that you would have to re-register, and if you are
doing that, the per-AS redirect_uri seems to be a much simpler solution.


        

          

            
The client developers I have talked to really hate per AS redirect URI


          

        

        
as being too awkward for deployments.


        

          
I on the other hand found it quite easy to do per AS redirect URIs, so


        

        
it might well be implementation


        

          
dependent rather then contextual.



          

            

              
Per AS Redirect URI
--------------------------------
This does not involve wire protocol changes. It just adds requirements


            

          

        

        
on the redirect uri. This by far is the simplest s=
olution for [case2] (and
[case1]), IMHO.


        

          

            

              
Again, it is not a general framework for finding out tainted


            

          

        

        
communication, so it may have other holes.


        

          

            
This is probably the hardest for the client developer and for the


          

        

        
deployer.  Yes it is simplest from a spec point of=
 view.


        

          

            
We need more developer feedback on this.


          

          
As I said above I found this quite simple to implement.



          

            

              
(Extended) PKCE
---------------------------------
To begin with, it works only with code flow. There has to be something


            

          

        

        
else to deal with implicit flow.


        

          

            

              
PKCE binds the authorization request/response to the token request.
If used with a confidential client, it seems to mitigate the


            

          

        

        
vulnerability.


        

          

            

              
John points out that it is not the case. I m=
ust be missing something


            

          

        

        
here=E2=80=A6 but my logic goes like:


        

          

            

              

1.     The good client creates code_challenge-v and


            

          

        

        
code_verifier-v=3DS256(code_challenge-v) and sends=
 the client_id-v +
code_challenge-v + state to the BadAS Authz EP.


        

          

            

              
2.     BadAS as a client prepares a code_ver=
ifier-b and


            

          

        

        
code_challenge-b=3DS256(code_verifer-b).


        

          

            

              
3.     BadAS redirects to GoodAS with the cl=
ient_id-v +


            

          

        

        
code_challenge-b + state-v.


        

          

            

              
4.     GoodAS stores the code_challenge-b.
5.     GoodAS returns code-v + state-v to the client=E2=80=99s redirect u=
ri.
6.     The client finds the AS from the state and sends code-v +


            

          

        

        
code_verifier-v + secret-b to the BadAS token endp=
oint. Now, code-v and
code_verifer-v is phished.


        

          

            

              
Now the attacker tries to use the code-v and code_verifier-v.

### Case A:
7.     The BadAS as a client sends client_id-v + =E2=80=A6 but he does no=
t


            

          

        

        
have client secret for the good client, so it fail=
s.


        

          

            

              
### Case B:
8.     The BadAS as a client sends client_id-b + code-v +


            

          

        

        
code_verifier-b + secret-b etc. to GoodAS.


        

          

            

              
9.     GoodAS verifies the code_verifier-b i=
s associated with code-v,


            

          

        

        
but that code-v is not associated with client_id-b=
, so the token request
fails.


        

          

            

              
### Case C: cut-n-paste
10.  The attacker launches cut-n-paste attack by replacing the code-b


            

          

        

        
with code-v.


        

          

            

              
11.  The verifiers does not match, so fails.=


Please let me know what I am missing.


            

            
In a step 0 the attacker has the good client create another request in


          

        

        
the attackers user agent to get state-0 and code_c=
hallange-0


        

          

            
Step 2 is not required.
Step 3 Bad AS redirects to good AS with client_id_v + state-v +


          

        

        
code_challenge-0


        

          

            
Step 4 GoodAS stores code_challenge-0
Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
Step 6 The client finds the AS from the state and sends code-v +


          

        

        
code_verifier-v + secret-b to the BadAS token endp=
oint. Now, code-v and
code_verifer-v is phished.


        

          

            
Case C1 :  cut and paste
10.  The attacker launches cut-n-paste attack by inserting code-v into


          

        

        
a response using state-0


        

          

            
11. The client sends code-v and based on state=
-0 it sends


          

        

        
code_verifyer-0 to the good AS token endpoint.


        

          

            
12. The GoodAS verifies that code-verifyer-0 i=
s correct for


          

        

        
code_challange-0 that it bound to code in step 4


        

          

            
13. The GoodAS receives RT + AT.
14. The attacker has now used the client to bind the users resource to


          

        

        
it=E2=80=99s account and is transferring money or =
looking at your data.


        

          

            
This could be 3rd party financial app like Mint as an example or photos


          

        

        
or any other PII that could then be used to escala=
te identity theft.


        

          

            
This variation of the attack combining cut and paste with confused


          

        

        
client was not mentioned in the research papers.


        

          

            
I found it looking to see if PKCE could be used to mitigate the


          

        

        
confused client attack.


        

          

            
As I mentioned in a response to William, while the current PKCE


          

        

        
Challenge methods only make the attack harder by f=
orcing the attacker to
get the client to make a step 0 request to get a code_challenge to use in=

the request,  we could define a new challenge method that would be
effective.


        

          

            
That would remove the need to have a separate mechanism to prevent cut


          

        

        
and paste.


        

          

            
The problem is that the PKCE challenge is independent of state so


          

        

        
becomes vulnerable to the confused client.


        

          

            
What we would need to do is include state in the challenge so that if


          

        

        
the AS receives mismatched state and code_challang=
e in step 3 the
verification of code verifier will fail. Effectively combining the cut an=
d
paste mitigation with PKCE.


        

          

            
I haven=E2=80=99t had time to write this up, but if the code_challenge =3D=
=3D


          

        

        
SHA256 (SHA256(state) || token_endpoint URI || Aut=
horization_endpoint URI
|| client_id || code-veriyer) ,  then the attacker could not change state=
,
client_id, or token_endpoint  independently of code_challenge.  (note I a=
m
using a hash of state to make storage size deterministic for the AS on th=
e
grounds that the client already needs to be able to do the hash) (Some
attacks  change the client_id in the request so I am including it in the
hash)


        

          

            
This is slightly more complicated than than S256, but not that much.  I


          

        

        
wish I had thought of this when we were doing PKCE=
=2E   Hit me with the
stupid stick, my fault.


        

          

            
I don=E2=80=99t know if it stops all the confused client attacks though.

If the client is confidential then it gives up it=E2=80=99s client secret=



          

        

        
assuming compromised registration, so we can=E2=80=
=99t really count on that for
symmetric client authentication.


        

          

            
By including the token endpoint in the comparison if the client is


          

        

        
sending the code to the attacker the client will u=
se a different token
endpoint_uri in to calculate the code_challenge than the GoodAS will use =
to
verify it.    This would stop both cut and paste as well as stopping the
attacker from using the code if they get it.   The attacker can=E2=80=99t=
 get
Secret for state-0, so it can=E2=80=99t create code_challenge that would =
be valid.


        

          

            
This stops the registration attack where the client gets a bad AS


          

        

        
discovery endpoint that has all the Good AS info i=
ncluding dynamic
registration endpoint but the bad AS token endpoint.   The bad AS would g=
et
the token, client_secret and code_verier, but will fail pkce verification=

because the token endpoint will be wrong.


        

          

            
The attack where the client registers with the good AS but with bad


          

        

        
token endpoint and Authorization endpoint gives th=
e attacker the ability to
change the code_challenge that the Good AS is going to see.   It would ne=
ed
to make a new challenge using state and the GoodAS token endpoint and it=E2=
=80=99s
client_id.


        

          

            
To do that it needs the code_verifier to use t=
o calculate the hash to


          

        

        
use as the code_challenge value.  As long as the c=
lient is not tricked into
accepting a replay of the authentication response we should be safe.  The=

client would need to do replay protection on the code_verifier values
before it makes a request to the token endpoint.


        

          

            
The BadAS could however make up a new code_challenge and code_verifier


          

        

        
and use that in the request. For this one the AS w=
ould need to do pull
discovery on the client to get a key, or the AS needs to return something=

in the response.  This attack can completely proxy all the endpoints as f=
ar
as the client is concerned and is taking advantage of the AS saying you a=
re
granting permission to site X based on the redirect URI.


        

          

            
I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a client =
from being


          

        

        
used as a redirector back to the attacker unless y=
ou also returned the
code_challenge in the response from the authorization endpoint.


        

          

            
Hypothetically if we returned code_challenge in the response from the


          

        

        
authorization endpoint and have a new PKCE challen=
ge method we might find
it covers all of the attacks.


        

          

            
We would need to put some serious analysis into this to see if it


          

        

        
really covers all the attacks.


        

          

            
It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D response_t=
ype or steeling the


          

        

        
access token by impersonating the RS.


        

          

            
I think the correct way to stop the problem with access tokens is by


          

        

        
audience restricting them.


        

          

            
To do that the client needs to provide an audi=
ence in it=E2=80=99s request and


          

        

        
the AS needs to include that in the AT.


        

          

            
I included the Authorization_endpoint URI in the hash to detect if the


          

        

        
auth request may have been tampered with to change=
 the audience for the AT.


        

          

            
For implicit we could have a version of PKCE where the AS returns a


          

        

        
parameter with S256( client_id || authorization_en=
dpoint URI || resource
endpoint URI) to verify the request was not tampered with, and that would=

allow the AT to be properly audience restricted.


        

          

            

This would be a completely new approach not involving discovery,


          

        

        
logical names for AS, or link relations.


        

          

            
Effectively this code_challenge method becomes a signature over parts


          

        

        
of the request and the implicit audience of the to=
ken_endpoint URI.


        

          

            
People keep asking why PKCE doesn=E2=80=99t stop these attacks, and it wo=
n=E2=80=99t


          

        

        
with the current PKCE methods,  however a new meth=
od along the lines I
sketched out may let it work, or I could be completely wrong.


        

          
Once you have written down something more definite I promise to


        

        
implement it promptly such that we can do interop


        

          
testing early in the process.

Before John brought up this new PKCE mode I was on the Option A side of


        

        
the fence now I=E2=80=99d like to see more


        

          
of this PKCE idea before committing to one or th=
e other.

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss



        

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



      

      

      

      

      

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


    

    

    

  


--------------020109030101030803040706--

--------------ms080301070506030703040206
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjQxMjQwMDNaMC8GCSqGSIb3DQEJBDEiBCAHShGPgZsWVNCm0lbeA8AS/rX5xBRQ
LnW9igMtnjUKVjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCP6Cm4i1s7
D62r0eyHeK1A+eJzbAmjvfzNjyvS7EHwaasXpyzRen5yOpVh2adKyrW71hYNlHQZ/KsoThD5
LGSnJ6TH1JFQXS+U3O6rYO0E88bmtS9RITQvidSd6qoxiGuoYh0LxSVJFrVtkJ5vWNeH91xb
yOubQjncVzYsmAlg7r+CBD9RaSKlLkhnn54fKeLGh82k/epIdjXsfqp7IzDZSUiZ7GI6vgVP
QUL3BnvoaVAwiKZtp439J1tDCf4fMBKyKw9PcWjBQvnc+MzOZo8H2I1/z5sNlFCyWDjxEtmQ
oR9MyikrE9eDbGwnY+fqMhUv7LqCh5RrRYNKgnuSGBX9AAAAAAAA
--------------ms080301070506030703040206--


From nobody Wed Feb 24 06:59:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CEE1B2D17 for ; Wed, 24 Feb 2016 06:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngq5x5dldL0t for ; Wed, 24 Feb 2016 06:59:53 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2CF1B2F71 for ; Wed, 24 Feb 2016 06:59:52 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1OExomY012023 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 14:59:51 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1OExnZZ032126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 14:59:49 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1OExnXE006524; Wed, 24 Feb 2016 14:59:49 GMT
Received: from [192.168.0.25] (/24.67.230.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 06:59:48 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_927BD50B-29EF-4233-A31B-FB8811603319"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Wed, 24 Feb 2016 06:59:46 -0800
Message-Id: 
References:   
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 14:59:55 -0000

--Apple-Mail=_927BD50B-29EF-4233-A31B-FB8811603319
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Nat,

I=E2=80=99m not sure that having the resource server tell the client =
where its authorization server is secure by itself. The relationship =
between the Authorization Server and the Resource server need to be =
bound together in one of the discovery endpoints (the resource and/or =
the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real =
resource server the current discovery spec will not lead the client to =
understand it has the wrong resource server. Rather the fake resource =
service will just have a fake discovery service. The hacker can now =
intercept resource payload as well as tokens because they were able to =
convince the client to use the legit authorization service but use the =
token against the hackers proxy.

The OAuth Discovery service needs to confirm to the client that the =
server is able to issue tokens for a stated resource endpoint.

This not only works in normal OAuth but should add security even to UMA =
situations.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>=20
>=20
> Hi Thomas,=20
>=20
> inline:=20
>=20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any =
URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a =
basis for other metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed=20
>=20
> Yup. That's one of the requirements to be RESTful, is it not? =20
>=20
> In OAuth's case, the resource and the authorization server are usually =
tightly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as =
well return the location of the authz server configuration data. In =
these cases, you do not have to decide on what .well-known uri as you =
say. This frees up developers from configuration file location =
collisions etc. We should strive not to pollute the uri space as much as =
possible.=20
> =20
> (well, except if there are several ASs each with different scopes; =
sounds like an edge-case to me though; maybe RFC6750 should instead be =
updated with such a parameter such that an RS could return several =
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>=20
> Yeah, I guess it is an edge case. I would rather like to see these =
authz servers to develop a trust framework under which they can agree on =
a single set of common scope parameter values.=20
>=20
> Cheers,=20
>=20
> Nat
>=20
>=20
>=20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer > wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
>=20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery =
document.
>=20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_927BD50B-29EF-4233-A31B-FB8811603319
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Nat,

I=E2=80=99m not sure that having the resource server =
tell the client where its authorization server is secure by itself. The =
relationship between the Authorization Server and the Resource server =
need to be bound together in one of the discovery endpoints (the =
resource and/or the oauth service discovery).

If a client discovers a =
fake resource server that is proxying for a real resource server the =
current discovery spec will not lead the client to understand it has the =
wrong resource server. Rather the fake resource service will just have a =
fake discovery service. The hacker can now intercept resource payload as =
well as tokens because they were able to convince the client to use the =
legit authorization service but use the token against the hackers =
proxy.

The =
OAuth Discovery service needs to confirm to the client that the server =
is able to issue tokens for a stated resource endpoint.

This not only works in =
normal OAuth but should add security even to UMA situations.








On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:


Hi Thomas, 

inline: 

2016=E5=B9=B42=E6=9C=882=
2=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if =
you really want to do discovery, and leave it open to implementers / to =
other specs to define a .well-known URL for =
"auto-configuration".
The metadata described here =
would then either be used as-is, at any URL, returned =
as draft-sakimura-oauth-meta metadata at the RS; or as a basis for =
other metadata specs (like OpenID =
Connect). 
With draft-sakimura-oauth-meta's "duri" and the "scope" =
attribute of WWW-Authenticate response header, you have everything you =
need to proceed 

Yup. That's one =
of the requirements to be RESTful, is it not?  

In OAuth's case, the =
resource and the authorization server are usually tightly coupled. =
(Otherwise, you need another specs like UMA.) 
So, the resource server should be able to tell either the =
location of the authz endpoint. In some trusted environment, the =
resource may as well return the location of the authz server =
configuration data. In these cases, you do not have to decide on what =
.well-known uri as you say. This frees up developers from configuration =
file location collisions etc. We should strive not to pollute the uri =
space as much as possible. 
 
(well, except if there are =
several ASs each with different scopes; sounds like an edge-case to me =
though; maybe RFC6750 should instead be updated with such a parameter =
such that an RS could return several WWW-Authenticate: Bearer, each with =
its own "scope" and "duri" value?)

Yeah, I guess it is an =
edge case. I would rather like to see these authz servers to develop a =
trust framework under which they can agree on a single set of common =
scope parameter values. 

Cheers, 

Nat



On =
Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:
The newly-trimmed OAuth =
Discovery document is helpful and moving in the right direction. It =
does, however, still have too many vestiges of its OpenID Connect =
origins. One issue in particular still really bothers me: the use of =
=E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery =
portion. Is this an OAuth discovery document, or an OpenID Connect one? =
There is absolutely no compelling reason to tie the URL to the OIDC =
discovery mechanism.

I propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery document.

 =E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
__________________________=
_____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_927BD50B-29EF-4233-A31B-FB8811603319--


From nobody Wed Feb 24 07:01:21 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9874B1A03F9 for ; Wed, 24 Feb 2016 07:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_6SQWW4My96 for ; Wed, 24 Feb 2016 07:01:14 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 EB7A21ACEB3 for ; Wed, 24 Feb 2016 07:01:13 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id m1so13635134lfg.0 for ; Wed, 24 Feb 2016 07:01:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=ymqWEdilIyyeympSpWc0nuQ5+tzmfEQNg4ky4DSGnJk=; b=Dphk0iJioO9dkzX/4jzKgzZVUntmo9jbkprqbruSoukOzROPUg+f+d23U5515ukYzw Tu9WUuknaPZ60hOPMW6ynV/iSPTGjb+XmQdvdooSBlbGUk2uZGKbF5H4zU00BfzYLgRc ArEmvVhN9LGXfO7Z07ZqW3ZXaaSUdKMTJA59eGmzJkWfm0rOe/uWtf0rw1rKZ+kpdYRp l8wM8IlkbG1Yg6WviZJ4zI8/XlJWlRqsWIejrqUcJaGcXmpu0QYIduoaA5rc1W+Xw1OE MRRybdxWWbPDJhQZ7F3Ff7LCiYs4VYBX1A7H54oH9FLHhgIllY3/26s3fSKkRtl/nDHS 7RGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=ymqWEdilIyyeympSpWc0nuQ5+tzmfEQNg4ky4DSGnJk=; b=j9Oj0+o6pXq/jgWQanDEZXH4nQIk1yU5e9SI3R6/Wroa8tMV+Us+EoH/xt8itxoBFf FQGqGOZJmVVFTF/QjLHtpfRbAkXzItKeQB/gFIXSDe5FidcMDMikeQOsW7GOA0FgZLY+ uM8wN9Ig0X/Z9WzVpgCD+EvhOSeRSNCbu3kWNIi3DO4LG0EsiMNrgb1x8ZpZyoBpdfcT ar/tKJ+X+9safZgeXZ1ND9d1hd7omgt8bnQ/46DPDIFFbD/gXDKwj8h18nsjhFWqTX/V LKZbH8vO9+FI0hRfK7uwrvl8NrPyKX9FSa3AUesBVXNSJWdbF0B9wTaZoBp18uNTV5UY cXdQ==
X-Gm-Message-State: AG10YOSOdipH7Oc40tr1eQoe1HSSFfxFS7px0doyvs13KySdIz8iVMw8jWt/eoaDt4g8pIrErbITXqxpfJVe1Q==
X-Received: by 10.25.43.20 with SMTP id r20mr14862562lfr.30.1456326068693; Wed, 24 Feb 2016 07:01:08 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Thomas Broyer 
Date: Wed, 24 Feb 2016 15:00:58 +0000
Message-ID: 
To: Nat Sakimura , Justin Richer ,  "" 
Content-Type: multipart/alternative; boundary=001a114116bc03cd39052c8556ea
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:01:20 -0000

--001a114116bc03cd39052c8556ea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nat,

On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura  wrote:

>
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
>
>
>> (well, except if there are several ASs each with different scopes; sound=
s
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an RS could return several
>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>
>
> Yeah, I guess it is an edge case. I would rather like to see these authz
> servers to develop a trust framework under which they can agree on a sing=
le
> set of common scope parameter values.
>

Well, except that adding the "duri" and "auri" metadata links to the
"WWW-Authenticate: Bearer" response header(s) would easily solve those
issues (without judging here whether they're edge-case or not), and I don't
really see any other use-case for that metadata outside the unauthorized
use of a resource (your draft admits it's the "typical use-case").

--001a114116bc03cd39052c8556ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Nat,

On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura <sakimura@gmail.com> wrote:

2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
<t.broyer@gmail.=
com>:
=C2=A0
=

(well, except if there are several ASs each with different scopes=
; sounds like an edge-case to me though; maybe RFC6750 should instead be up=
dated with such a parameter such that an RS could return several WWW-Authen=
ticate: Bearer, each with its own "scope" and "duri" va=
lue?)

Yeah, I guess it is an edge=
 case. I would rather like to see these authz servers to develop a trust fr=
amework under which they can agree on a single set of common scope paramete=
r values.

Well, exc=
ept that adding the "duri" and "auri" metadata links to=
 the "WWW-Authenticate: Bearer" response header(s) would easily s=
olve those issues (without judging here whether they're edge-case or no=
t), and I don't really see any other use-case for that metadata outside=
 the unauthorized use of a resource (your draft admits it's the "t=
ypical use-case").


--001a114116bc03cd39052c8556ea--


From nobody Wed Feb 24 07:52:04 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAB91A877F for ; Wed, 24 Feb 2016 07:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7JgMoINS2E0 for ; Wed, 24 Feb 2016 07:52:01 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 167C21A1AB2 for ; Wed, 24 Feb 2016 07:52:01 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id b35so16856859qge.0 for ; Wed, 24 Feb 2016 07:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=2gYPj1GVUyzDy5Cpf3jDMOADmopLwNLNSagbr97Pb/s=; b=d4zxl2aoslbADCy949jmB26A5wXXVy5pZSx0hQvh7SYImoAHPXJojC6WARpySQhuYE ahMTmUldE7KoFuXYjqR9uimChXKikJQuGbmb00veM1BlEzYAW/5PpXJzOtjIqU9Sd7e/ TlDWvAatwbvCyoveADmR52PzsmRdSz+Vn0biXuVx+XLLHyWChJpLelf5cTQWvJjzqDPm lbhCVlK0xHGJ6gFP3+6j/VPR+3uo8uXgHsZ9zmsySKhN+gNekVaARsjKQFGN+NShGbwj gXgvMPb4Myo9vgqa0zm5x36J25DCxFd3SicLZZmBf4NLTOHxgtHECFl5sJqbEzFvdgS0 MoKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=2gYPj1GVUyzDy5Cpf3jDMOADmopLwNLNSagbr97Pb/s=; b=TXy0nNBXSRVAfCZy6UwyHUmaYfDLsnW6FE/x1QZXT8UFbNC3rNm7qxG7jft6/sQ0q5 f7oU3ZaM8MQixxAQdLjU1kB57t1zZvk2wF3EEV6nxsjlL/A9FECuApDrLGyA/75WUIsf jUNEmEFMc6UcDjOKVuy/IXuj+y0rm1FlOfL0RRD0pA7UsermNa+IKPMnGVwpGtJYNjvt oD5AFC+NtRMp8+CKWWUIEyo25pCCYd/L/keSDzcTcXeoMS8MzZrC3AMO65m/fzhpnS1e fGViI6S8s97qeRWK+Ghqwzxgi2KztuQMPSI/fg09zD2OAYBppXjU9iKa1nJIgTrv9kQf MIZA==
X-Gm-Message-State: AG10YORvy18uZGg0gBy39x7YF8O8ZCtIXWSAjmILx+q5H1VjN+ini+ENJH2xKKoeO/F1o1MRnMQNkdYi+xcn6w==
X-Received: by 10.140.221.16 with SMTP id r16mr22222430qhb.67.1456329119803; Wed, 24 Feb 2016 07:51:59 -0800 (PST)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 24 Feb 2016 15:51:49 +0000
Message-ID: 
To: Thomas Broyer , Justin Richer ,  "" 
Content-Type: multipart/alternative; boundary=001a11378416dcb0db052c860b50
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 15:52:03 -0000

--001a11378416dcb0db052c860b50
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Right. As there can be multiple WWW-authenticate header, it is doable that
way. Maybe that's better in this respect, though it becomes a bit different
than other metadata. Alternatively, the scope can be added as a parameter
in the auri Web  Link header.
Good things about the Link Header is that you can just configure the web
server config to return them. There is no code needed.

2016=E5=B9=B42=E6=9C=8825=E6=97=A5(=E6=9C=A8) 0:01 Thomas Broyer :

> Hi Nat,
>
> On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura  wrote:
>
>>
>> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
>>
>
>>
>>> (well, except if there are several ASs each with different scopes;
>>> sounds like an edge-case to me though; maybe RFC6750 should instead be
>>> updated with such a parameter such that an RS could return several
>>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>>
>>
>> Yeah, I guess it is an edge case. I would rather like to see these authz
>> servers to develop a trust framework under which they can agree on a sin=
gle
>> set of common scope parameter values.
>>
>
> Well, except that adding the "duri" and "auri" metadata links to the
> "WWW-Authenticate: Bearer" response header(s) would easily solve those
> issues (without judging here whether they're edge-case or not), and I don=
't
> really see any other use-case for that metadata outside the unauthorized
> use of a resource (your draft admits it's the "typical use-case").
>

--001a11378416dcb0db052c860b50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Right. As there can be multiple WWW-authenticate header, i=
t is doable that way. Maybe that's better in this respect, though it be=
comes a bit different than other metadata. Alternatively, the scope can be =
added as a parameter in the auri Web =C2=A0Link header.=C2=A0
Good thin=
gs about the Link Header is that you can just configure the web server conf=
ig to return them. There is no code needed.=C2=A0

2016=E5=B9=B42=E6=9C=8825=E6=97=A5(=E6=9C=
=A8) 0:01 Thomas Broyer <t.broyer@=
gmail.com>:
Hi Nat,

On Wed, Feb 24, 2016 at 12:54 PM N=
at Sakimura <sak=
imura@gmail.com> wrote:
<=
br>
2016=E5=B9=B42=E6=9C=8822=E6=
=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com>:
<=
/blockquote>
=C2=A0
(w=
ell, except if there are several ASs each with different scopes; sounds lik=
e an edge-case to me though; maybe RFC6750 should instead be updated with s=
uch a parameter such that an RS could return several WWW-Authenticate: Bear=
er, each with its own "scope" and "duri" value?)
<=
/div>

Yeah, I guess =
it is an edge case. I would rather like to see these authz servers to devel=
op a trust framework under which they can agree on a single set of common s=
cope parameter values.

Well, except that adding the "duri" =
and "auri" metadata links to the "WWW-Authenticate: Bearer&q=
uot; response header(s) would easily solve those issues (without judging he=
re whether they're edge-case or not), and I don't really see any ot=
her use-case for that metadata outside the unauthorized use of a resource (=
your draft admits it's the "typical use-case").




--001a11378416dcb0db052c860b50--


From nobody Wed Feb 24 08:12:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE921A8AAD for ; Wed, 24 Feb 2016 08:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m8FZJiQoyi9 for ; Wed, 24 Feb 2016 08:12:53 -0800 (PST)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662691A88AF for ; Wed, 24 Feb 2016 08:12:53 -0800 (PST)
Received: by mail-qg0-x235.google.com with SMTP id b35so17389076qge.0 for ; Wed, 24 Feb 2016 08:12:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=np+IHaxTlyNpmuU+IUoXuOeEUqYA9FRRitYFYUGDGtw=; b=x+ftdRShAx4hTfsonCAlIn6t1I3WljP9+Zf2fFb7A/7yc5Y5kQ3tyspaEmH6LSSx2y +jr01ihY8z8JDdRRA/O+gZuuXpcX6WZus0PmveWanfpTnkQEr9Dca4+/3hWtNEm92I9E FD4IvjqqW54aoUVRr81tAyaGsKClF3t0dXqHZKwHu0I+jBtH4ptUXDplEsBPVzkbCPf5 Diaw5XLvvUch9LiTvdtTAlPEXwKyfhsN5L8ImJdpXlxjA+qfkJH0TLexzvdUsmRDs6va N7ixJkV6cln7ZMwtpMjPQFRtEobQOZtGyJrPlmjmLuZTVrXJXoDIfuVVEKFSLCBkoSzI lPaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=np+IHaxTlyNpmuU+IUoXuOeEUqYA9FRRitYFYUGDGtw=; b=bc/2/NyhyWUTPE1/i25sqIKw30+Y6cI6yQyYbzuu9FHceMGiJYYErwbV47TuVMumOn gsJM/Lok5VUxSzxEzAJlH6kzUM3HKkOZ3Mbx0WVggBv/emAHDNP+0fEU7M8zNR83dmDn epWnb1hAT6EKzQaDAtUMsbsbpNIxDkc42fEPCFm2Fs6DEdfOldOI4QS77udVVI45tjYg /qpTbVhkotlmmvk5DLxaJ0jnK6Y3JLS1vbW4uNGcUgh5pR54wXuqwUQw6JVTIsnfSORQ lHht7Co65DEcssXc4GPTpYXQe/QVHAJf8bU4ONMNp+nxdm3qZVzujbcjD7NUSm36HTp7 nSsA==
X-Gm-Message-State: AG10YOQB6eSWId9w031K+6WTk6adh9/vLXURBEMN/40pH/nFOpyenhl0X2iftwn8WSmJZbfqesXcUdkloFc88g==
X-Received: by 10.140.250.138 with SMTP id v132mr52633510qhc.0.1456330372481;  Wed, 24 Feb 2016 08:12:52 -0800 (PST)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 24 Feb 2016 16:12:41 +0000
Message-ID: 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a113a99d0870cd0052c8656eb
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 16:12:56 -0000

--001a113a99d0870cd0052c8656eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs?
Currently, it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS,
the client will not send the token there as the authz server will say that
is not the place the client may want to send the token to.

Nat

2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :

> Nat,
>
> I=E2=80=99m not sure that having the resource server tell the client wher=
e its
> authorization server is secure by itself. The relationship between the
> Authorization Server and the Resource server need to be bound together in
> one of the discovery endpoints (the resource and/or the oauth service
> discovery).
>
> If a client discovers a fake resource server that is proxying for a real
> resource server the current discovery spec will not lead the client to
> understand it has the wrong resource server. Rather the fake resource
> service will just have a fake discovery service. The hacker can now
> intercept resource payload as well as tokens because they were able to
> convince the client to use the legit authorization service but use the
> token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the serve=
r
> is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA
> situations.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
>
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to
>> do discovery, and leave it open to implementers / to other specs to defi=
ne
>> a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL,
>> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis =
for
>> other metadata specs (like OpenID Connect).
>>
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
>> WWW-Authenticate response header, you have everything you need to procee=
d
>>
>>
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and the authorization server are usually
> tightly coupled. (Otherwise, you need another specs like UMA.)
> So, the resource server should be able to tell either the location of the
> authz endpoint. In some trusted environment, the resource may as well
> return the location of the authz server configuration data. In these case=
s,
> you do not have to decide on what .well-known uri as you say. This frees =
up
> developers from configuration file location collisions etc. We should
> strive not to pollute the uri space as much as possible.
>
>
>> (well, except if there are several ASs each with different scopes; sound=
s
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an RS could return several
>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>
>
> Yeah, I guess it is an edge case. I would rather like to see these authz
> servers to develop a trust framework under which they can agree on a sing=
le
> set of common scope parameter values.
>
> Cheers,
>
> Nat
>
>
>>
>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
>>
>>> The newly-trimmed OAuth Discovery document is helpful and moving in the
>>> right direction. It does, however, still have too many vestiges of its
>>> OpenID Connect origins. One issue in particular still really bothers me=
:
>>> the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the d=
iscovery portion. Is
>>> this an OAuth discovery document, or an OpenID Connect one? There is
>>> absolutely no compelling reason to tie the URL to the OIDC discovery
>>> mechanism.
>>>
>>> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the
>>> default discovery location, and state that the document MAY also be
>>> reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if t=
he server also
>>> provides OpenID Connect on the same domain. Other applications SHOULD u=
se
>>> the same parameter names to describe OAuth endpoints and functions insi=
de
>>> their service-specific discovery document.
>>>
>>>  =E2=80=94 Justin
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--001a113a99d0870cd0052c8656eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Phil,=C2=A0

Are you suggesting that =
the AS metadata should include the RS URIs? Currently, it does not, but it =
can be done, I guess.=C2=A0

The way oauth-meta wor=
ks is that=C2=A0

1. RS tells the client where the =
AS is.=C2=A0
2. AS tells the client which RS endpoints the token =
can be used.=C2=A0

Even if there is a bad AS with =
a valid certs that proxies to the good RS, the client will not send the tok=
en there as the authz server will say that is not the place the client may =
want to send the token to.=C2=A0

Nat

2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=
=E6=B0=B4) 23:59 Phil Hunt <phil=
.hunt@oracle.com>:
Nat,

I=E2=80=99m not s=
ure that having the resource server tell the client where its authorization=
 server is secure by itself. The relationship between the Authorization Ser=
ver and the Resource server need to be bound together in one of the discove=
ry endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying =
for a real resource server the current discovery spec will not lead the cli=
ent to understand it has the wrong resource server. Rather the fake resourc=
e service will just have a fake discovery service. The hacker can now inter=
cept resource payload as well as tokens because they were able to convince =
the client to use the legit authorization service but use the token against=
 the hackers proxy.

The OAuth Discovery service ne=
eds to confirm to the client that the server is able to issue tokens for a =
stated resource endpoint.

This not only works in n=
ormal OAuth but should add security even to UMA situations.


On Feb 24, 2016, at 3:54 AM, Nat Sa=
kimura <sakimura=
@gmail.com> wrote:


Hi Thomas,=C2=A0
inline:=C2=A0

2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
<t.broyer@gmail.=
com>:
Couldn't the do=
cument only describe the metadata?
I quite like the idea of=C2=A0draft-=
sakimura-oauth-meta if you really want to do discovery, and leave it open t=
o implementers / to other specs to define a .well-known URL for "auto-=
configuration".
The metadata described here would then eithe=
r be used as-is, at any URL, returned as=C2=A0draft-sakimura-oauth-meta met=
adata at the RS; or as a basis for other metadata specs (like OpenID Connec=
t).=C2=A0
=

With=C2=A0draft-sakimura-oauth-meta's "duri" and the &qu=
ot;scope" attribute of WWW-Authenticate response header, you have ever=
ything you need to proceed=C2=A0

Yup. That's one of the requirements to be RESTful,=
 is it not? =C2=A0

In OAuth's case, the resour=
ce and the authorization server are usually tightly coupled. (Otherwise, yo=
u need another specs like UMA.)=C2=A0
So, the resource server sho=
uld be able to tell either the location of the authz endpoint. In some trus=
ted environment, the resource may as well return the location of the authz =
server configuration data. In these cases, you do not have to decide on wha=
t .well-known uri as you say. This frees up developers from configuration f=
ile location collisions etc. We should strive not to pollute the uri space =
as much as possible.=C2=A0
=C2=A0
(well, except if there are several ASs each with differe=
nt scopes; sounds like an edge-case to me though; maybe RFC6750 should inst=
ead be updated with such a parameter such that an RS could return several W=
WW-Authenticate: Bearer, each with its own "scope" and "duri=
" value?)

Yeah, I gu=
ess it is an edge case. I would rather like to see these authz servers to d=
evelop a trust framework under which they can agree on a single set of comm=
on scope parameter values.=C2=A0

Cheers,=C2=A0

Nat



On Fri, =
Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the =
right direction. It does, however, still have too many vestiges of its Open=
ID Connect origins. One issue in particular still really bothers me: the us=
e of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery p=
ortion. Is this an OAuth discovery document, or an OpenID Connect one? Ther=
e is absolutely no compelling reason to tie the URL to the OIDC discovery m=
echanism.

I propose that we use =E2=80=9C/.well-known/oauth-authoriz=
ation-server=E2=80=9D as the default discovery location, and state that the=
 document MAY also be reachable from =E2=80=9C/.well-known/openid-configura=
tion=E2=80=9D if the server also provides OpenID Connect on the same domain=
. Other applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery document.
=C2=A0=E2=80=94 Justin
___________________________________________=
____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman=
/listinfo/oauth
_______________=
________________________________
OAuth mailing list
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
____________________________________=
___________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/a>

=



--001a113a99d0870cd0052c8656eb--


From nobody Wed Feb 24 08:39:40 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7296F1B38F1 for ; Wed, 24 Feb 2016 08:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level: 
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpRlkG43f35a for ; Wed, 24 Feb 2016 08:39:36 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AD21B38EE for ; Wed, 24 Feb 2016 08:39:36 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1OGdUdW015137 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 16:39:30 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1OGdURx003789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 16:39:30 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1OGdSJt027119; Wed, 24 Feb 2016 16:39:29 GMT
Received: from [192.168.0.22] (/24.67.230.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 08:39:28 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-462B6A76-B946-4BFF-B3C7-126ADFA94F52
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Wed, 24 Feb 2016 08:39:15 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References:     
To: Nat Sakimura 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 16:39:39 -0000

--Apple-Mail-462B6A76-B946-4BFF-B3C7-126ADFA94F52
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I am suggesting that part of the discovery solution has to be the client ind=
icating what resource endpoint it wants the oauth configuration data for.=20=


So if res.example.evil.com is not a valid resource endpoint for as.example.c=
om the authz discovery should fail in some way (eg return nothing).=20

There may be better ways to do this. Eg combine discovery. Or change the ord=
er of discovery.=20

One of OAuth's strength's and weaknesses is that the target of authorization=
 (the resource) is never specified. It is often bound up in the client regis=
tration and an often implied 1:1 relationship between resource and as. Given=
 that in discovery phase registration has not yet occurred it seems importan=
t that the client know it has a valid combination of endpoints etc.=20

This is why I was disappointed about wglc on discovery. We had a starting po=
int for group adoption but we haven't really defined the full requirements I=
MO.=20

I am on vacation or I would put some thought into some draft changes or a ne=
w draft. I apologize I can't do it now.=20

Phil

> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>=20
> Hi Phil,=20
>=20
> Are you suggesting that the AS metadata should include the RS URIs? Curren=
tly, it does not, but it can be done, I guess.=20
>=20
> The way oauth-meta works is that=20
>=20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
>=20
> Even if there is a bad AS with a valid certs that proxies to the good RS, t=
he client will not send the token there as the authz server will say that is=
 not the place the client may want to send the token to.=20
>=20
> Nat
>=20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
>> Nat,
>>=20
>> I=E2=80=99m not sure that having the resource server tell the client wher=
e its authorization server is secure by itself. The relationship between the=
 Authorization Server and the Resource server need to be bound together in o=
ne of the discovery endpoints (the resource and/or the oauth service discove=
ry).
>>=20
>> If a client discovers a fake resource server that is proxying for a real r=
esource server the current discovery spec will not lead the client to unders=
tand it has the wrong resource server. Rather the fake resource service will=
 just have a fake discovery service. The hacker can now intercept resource p=
ayload as well as tokens because they were able to convince the client to us=
e the legit authorization service but use the token against the hackers prox=
y.
>>=20
>> The OAuth Discovery service needs to confirm to the client that the serve=
r is able to issue tokens for a stated resource endpoint.
>>=20
>> This not only works in normal OAuth but should add security even to UMA s=
ituations.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>>>=20
>>>=20
>>> Hi Thomas,=20
>>>=20
>>> inline:=20
>>>=20
>>> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
>>>> Couldn't the document only describe the metadata?
>>>> I quite like the idea of draft-sakimura-oauth-meta if you really want t=
o do discovery, and leave it open to implementers / to other specs to define=
 a .well-known URL for "auto-configuration".
>>>> The metadata described here would then either be used as-is, at any URL=
, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis fo=
r other metadata specs (like OpenID Connect).=20
>>>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WW=
W-Authenticate response header, you have everything you need to proceed=20
>>>=20
>>> Yup. That's one of the requirements to be RESTful, is it not? =20
>>>=20
>>> In OAuth's case, the resource and the authorization server are usually t=
ightly coupled. (Otherwise, you need another specs like UMA.)=20
>>> So, the resource server should be able to tell either the location of th=
e authz endpoint. In some trusted environment, the resource may as well retu=
rn the location of the authz server configuration data. In these cases, you d=
o not have to decide on what .well-known uri as you say. This frees up devel=
opers from configuration file location collisions etc. We should strive not t=
o pollute the uri space as much as possible.=20
>>> =20
>>>> (well, except if there are several ASs each with different scopes; soun=
ds like an edge-case to me though; maybe RFC6750 should instead be updated w=
ith such a parameter such that an RS could return several WWW-Authenticate: B=
earer, each with its own "scope" and "duri" value?)
>>>=20
>>> Yeah, I guess it is an edge case. I would rather like to see these authz=
 servers to develop a trust framework under which they can agree on a single=
 set of common scope parameter values.=20
>>>=20
>>> Cheers,=20
>>>=20
>>> Nat
>>>=20
>>>>=20
>>>>=20
>>>>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote=
:
>>>>> The newly-trimmed OAuth Discovery document is helpful and moving in th=
e right direction. It does, however, still have too many vestiges of its Ope=
nID Connect origins. One issue in particular still really bothers me: the us=
e of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery po=
rtion. Is this an OAuth discovery document, or an OpenID Connect one? There i=
s absolutely no compelling reason to tie the URL to the OIDC discovery mecha=
nism.
>>>>>=20
>>>>> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the default discovery location, and state that the document MAY=
 also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D i=
f the server also provides OpenID Connect on the same domain. Other applicat=
ions SHOULD use the same parameter names to describe OAuth endpoints and fun=
ctions inside their service-specific discovery document.
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-462B6A76-B946-4BFF-B3C7-126ADFA94F52
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I am suggesting that part of the disco=
very solution has to be the client indicating what resource endpoint it want=
s the oauth configuration data for. 

So if res.example.evil.com is not a valid resource endpoint for <=
a href=3D"http://as.example.com">as.example.com the authz discovery shou=
ld fail in some way (eg return nothing). 

There may be better ways to d=
o this. Eg combine discovery. Or change the order of discovery. 
<=
div id=3D"AppleMailSignature">
One o=
f OAuth's strength's and weaknesses is that the target of authorization (the=
 resource) is never specified. It is often bound up in the client registrati=
on and an often implied 1:1 relationship between resource and as. Given that=
 in discovery phase registration has not yet occurred it seems important tha=
t the client know it has a valid combination of endpoints etc. 

This i=
s why I was disappointed about wglc on discovery. We had a starting point fo=
r group adoption but we haven't really defined the full requirements IMO.&nb=
sp;

I am on vacation or I would put some thought into some draft changes or=
 a new draft. I apologize I can't do it now. 

Phil
On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:

Hi Phil, 

Are you suggesti=
ng that the AS metadata should include the RS URIs? Currently, it does not, b=
ut it can be done, I guess. 

The way oauth-met=
a works is that 

1. RS tells the client where t=
he AS is. 
2. AS tells the client which RS endpoints the toke=
n can be used. 

Even if there is a bad AS with=
 a valid certs that proxies to the good RS, the client will not send the tok=
en there as the authz server will say that is not the place the client may w=
ant to send the token to. 

Nat

2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=
=B4) 23:59 Phil Hunt <phil.hunt@o=
racle.com>:
Nat,

I=E2=80=99m not sure that ha=
ving the resource server tell the client where its authorization server is s=
ecure by itself. The relationship between the Authorization Server and the R=
esource server need to be bound together in one of the discovery endpoints (=
the resource and/or the oauth service discovery).

If=
 a client discovers a fake resource server that is proxying for a real resou=
rce server the current discovery spec will not lead the client to understand=
 it has the wrong resource server. Rather the fake resource service will jus=
t have a fake discovery service. The hacker can now intercept resource paylo=
ad as well as tokens because they were able to convince the client to use th=
e legit authorization service but use the token against the hackers proxy.

The OAuth Discovery service needs to confirm to the c=
lient that the server is able to issue tokens for a stated resource endpoint=
.

This not only works in normal OAuth but should ad=
d security even to UMA situations.


On Feb 24, 2016, at 3:54 AM, Nat Sak=
imura <sakimura@g=
mail.com> wrote:


Hi Thomas, 

inline: 

2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com&g=
t;:
Couldn't the document only desc=
ribe the metadata?
I quite like the idea of draft-sakimura-oauth-me=
ta if you really want to do discovery, and leave it open to implementers / t=
o other specs to define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, r=
eturned as draft-sakimura-oauth-meta metadata at the RS; or as a basis f=
or other metadata specs (like OpenID Connect). 
With draft-sakimura-oauth-me=
ta's "duri" and the "scope" attribute of WWW-Authenticate response header, y=
ou have everything you need to proceed 
<=
/blockquote>

Yup. That's one of the requirements to be RE=
STful, is it not?  

In OAuth's case, the resou=
rce and the authorization server are usually tightly coupled. (Otherwise, yo=
u need another specs like UMA.) 
So, the resource server shou=
ld be able to tell either the location of the authz endpoint. In some truste=
d environment, the resource may as well return the location of the authz ser=
ver configuration data. In these cases, you do not have to decide on what .w=
ell-known uri as you say. This frees up developers from configuration file l=
ocation collisions etc. We should strive not to pollute the uri space as muc=
h as possible. 
 
<=
div>
(well, except if there are several ASs each with different scopes; s=
ounds like an edge-case to me though; maybe RFC6750 should instead be update=
d with such a parameter such that an RS could return several WWW-Authenticat=
e: Bearer, each with its own "scope" and "duri" value?)

Yeah, I guess it is an edge case. I would rath=
er like to see these authz servers to develop a trust framework under which t=
hey can agree on a single set of common scope parameter values. 
<=
div>
Cheers, 

Nat

=



On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu> w=
rote:
The newly-trimmed OAuth Discovery document is h=
elpful and moving in the right direction. It does, however, still have too m=
any vestiges of its OpenID Connect origins. One issue in particular still re=
ally bothers me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D in the discovery portion. Is this an OAuth discovery document, or an Ope=
nID Connect one? There is absolutely no compelling reason to tie the URL to t=
he OIDC discovery mechanism.

I propose that we use =E2=80=9C/.well-kn=
own/oauth-authorization-server=E2=80=9D as the default discovery location, a=
nd state that the document MAY also be reachable from =E2=80=9C/.well-known/=
openid-configuration=E2=80=9D if the server also provides OpenID Connect on t=
he same domain. Other applications SHOULD use the same parameter names to de=
scribe OAuth endpoints and functions inside their service-specific discovery=
 document.

 =E2=80=94 Justin
________________________________=
_______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
________=
_______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_____________________________________=
__________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<=
/div>

=

--Apple-Mail-462B6A76-B946-4BFF-B3C7-126ADFA94F52--


From nobody Wed Feb 24 09:34:22 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0F61B3A78 for ; Wed, 24 Feb 2016 09:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q48OX5iMi3x for ; Wed, 24 Feb 2016 09:34:14 -0800 (PST)
Received: from omr-a005e.mx.aol.com (omr-a005e.mx.aol.com [204.29.186.50]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30EF1B39E4 for ; Wed, 24 Feb 2016 09:34:10 -0800 (PST)
Received: from mtaout-aak01.mx.aol.com (mtaout-aak01.mx.aol.com [172.27.2.225]) by omr-a005e.mx.aol.com (Outbound Mail Relay) with ESMTP id 7D5F73800057; Wed, 24 Feb 2016 12:34:09 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aak01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6A8953800008D; Wed, 24 Feb 2016 12:34:08 -0500 (EST)
To: John Bradley , "oauth@ietf.org" 
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com>  <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56CDE997.90704@aol.com>
Date: Wed, 24 Feb 2016 12:34:15 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------090906030302000809070306"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456335249; bh=6hcUrW9D7Msb4Cv9UDxFagaaWpJ6Wcp1IyrIIzH/Qgc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Gtyc8of6I8NGEPTXYQ84XbSCsCUxDges9p0JTEPWIDs0GC3oJ2AevBfWibBVaeA3Q TsoUMUlpoN7zCZf7pAdqOhK4LjuTa7CpPlwEGLmX5oldqc6UxNkk3cnDbRvLi55a3d ZtX9UOozNZcTZHcuztqO29A6HlKJx0RXpZLSBKp4=
x-aol-sid: 3039ac1b02e156cde99002e6
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 17:34:20 -0000

This is a multi-part message in MIME format.
--------------090906030302000809070306
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

> We still have a problem with AT leaking.   I think that needs to be dealt with separately.
> Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request rejected because it is an invalid audience.
I have some concerns with requiring an audience for AT issuance. Today a 
client can get a token with scopes "instantMessaging readMail sendMail 
readContacts writeContacts" and then use that token against multiple 
endpoints (im.example.com mail.example.com contacts.example.com). This 
is a common usage of OAuth2.

Forcing the client to get a unique AT for each service it wants to talk 
to is a change from the model that is currently in place.

Thanks,
George

On 2/23/16 6:17 PM, John Bradley wrote:
> The idea of including the state in the PKCE calculation was one I think Hans brought up at the meeting in Darmstadt.
>
> I think we discounted it as not solving the problem because the attacker could manipulate the code_challenge.
>
> As and example the attacker receives the request and changes the code_challenge to one it makes up based on the state from a second request made to the client in it’s browser.
>
> The attacker can replay the token to the client with the state that will validate the code_callenge or use the token directly at the token endpoint to get a access token as it would know both the client secret and code verifier.
>
> We moved on to look at another way to validate state by passing it to the token endpoint for validation to stop the cut and paste attack.
>
> In thinking again about William and Nat’s question about why not PKCE, I looked at the idea of using PKCE again.
>
> The problem with using PKCE as it is now is that we made the assumption that the attacker could not modify the request.
>
> That got me trying to think of a way to:
>   a) stop the attacker from modifying the request (signed request, probably too complicated to be generally deployed)
>   b) allow the client to detect if code_challenge has been modified and abort of the request was compromise.
>
> I realized that you could simply echo back the code_challenge from the authorization endpoint and that would allow the client to know if code_challenge had been altered in the request, assuming the attacker can’t modify the response from the legitimate AS.
>
> So if we add that step we now have a client where code_challenge can’t be altered.
>
> That in it selfs stops the cut and pate attack.  It however still allows an attacker to use the code it receives along with the the code_verifier and client secret to get a AT and RT from the legitimate token endpoint.
>
> So that is not enough Including state in the hash calculation helps against the cut and paste attack but we fixed that by returning code_challenge.
>
> That leaves the other things we were talking about returning from the authorization endpoint.
>
> If we include token_endpoint URI in the hash then any token the client requests thinking it is for the attackers token endpoint won’t generate the same code_challenge as the AS would based on it’s token endpoint.   The attacker would know the code_challenge and the real token endpoint URI but would have to generate a collision in the lifetime of code to use the code.   This would not be possible based on the PKCE analysis.
>
> Returning the code_challenge and including the token_endpoint URI in the hash is the minimum needed for the code flow to stop both cut and paste as well  as protect the code from being used if stolen via a confused client attack.   It doesn’t stop the theft just the use of the token.  So it is mitigating the issue a different way from A and B that are trying to stop the attacker from getting the code.
>
> Given the technique I realized it would be simple enough to also include some other paramaters in the hash
> 1) The authorization endpoint in the hash causing it not to validate if the client has been given a bad authorization endpoint so the client can modify the request.
> 2) The client_id so that it cannot be tampered with in the request.
> 3) The state  This is tied to the browser instance for XSRF protection.  Including this means it cannot be changed and is another protection against cut and paste.
>
> Including all 4 in the hash may be overkill as they overlap in protection.  I however think that not integrity protecting one of the values might bite us in the future.
>
> We could go farther and include scopes or the whole request but that gets more complicated than it is worth.  We do have a option for request signing already.
>
> So we almost had this at the Darmstadt meeting but it slipped away.
>
> This is not stoping the attack it is protecting code.
>
> I should point out that some of the attacks like man in the middling registration can still compromise the client secret, making it possible for an attacker to impersonate a client.
>
> Nat’s option B doesn’t have a solution to that ether as far as I can tell.
>
> I think the only option for that is to have a logical identifier for the AS and some sort of discovery check at registration to be certain that you are using the correct registration location.
>
> Option A plus discovery works for that and mitigates confused client but not cut and paste.
>
> We still have a problem with AT leaking.   I think that needs to be dealt with separately.
> Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request rejected because it is an invalid audience.
>
> That should happen at the token endpoint for code.
> For implicit it would need to be at the authoriation endpoint and the audience would need to be echoed back to prevent tampering.
>
> The AT can also be protected by POP so I think that code and AT should be kept separate issues.
>
> John B.
>
>
>> On Feb 23, 2016, at 9:59 PM, Roland Hedberg  wrote:
>>
>> In line !
>>
>>> 22 feb 2016 kl. 05:08 skrev John Bradley :
>>>
>>>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura  wrote:
>>>>
>>>> The risk impact of [case2] is more OAuth specific. The token is stolen as the token is going to be sent to a rogue resource, and the resource can use that to obtain the resource that was supposed to be only available to the proper client.
>>>>
>>>> The risk impact of [case3] is the most grave among these three. Now the attacker can create his own client that impersonates the compromised client.
>>>>
>>>> OAuth-mix-up
>>>> ---------------------------
>>>> OAuth-mix-up draft gives one way of addressing [case2] by introducing a new concept of “issuer†and “discovery†to RFC6749. It also returns client_id and verifies it in 4.2, but if the BadAS has assigned a same client_id to the client, it does not help.
>>> Client_id are not guaranteed to be unique.  They need to be name spaced by the AS.   In OAuth currently we have no name for the AS this makes that difficult, the client can use the authorization endpoint URI, but that logic may well break in multi tenant situations.   Having a clear issuer string makes it easier for the client.
>> I stumbled over exactly this point when I made my implementation follow the Mix-Up draft.
>> If not discovery is involved I think an AS has to have a name which is different from the endpoint URIs.
>>
>>>> One of the issue with this approach is that the central notion of “issuer†is new to the existing servers and clients. The verification rule in 4.1 states “Compare the issuer URL for the authorization server that the client received when it registered at the authorization serverâ€, but in most existing pure OAuth cases, there is no such thing, so you cannot compare. This means that you would have to re-register, and if you are doing that, the per-AS redirect_uri seems to be a much simpler solution.
>>> The client developers I have talked to really hate per AS redirect URI as being too awkward for deployments.
>> I on the other hand found it quite easy to do per AS redirect URIs, so it might well be implementation
>> dependent rather then contextual.
>>
>>>> Per AS Redirect URI
>>>> --------------------------------
>>>> This does not involve wire protocol changes. It just adds requirements on the redirect uri. This by far is the simplest solution for [case2] (and [case1]), IMHO.
>>>>
>>>> Again, it is not a general framework for finding out tainted communication, so it may have other holes.
>>> This is probably the hardest for the client developer and for the deployer.  Yes it is simplest from a spec point of view.
>>> We need more developer feedback on this.
>> As I said above I found this quite simple to implement.
>>
>>>> (Extended) PKCE
>>>> ---------------------------------
>>>> To begin with, it works only with code flow. There has to be something else to deal with implicit flow.
>>>>
>>>> PKCE binds the authorization request/response to the token request.
>>>> If used with a confidential client, it seems to mitigate the vulnerability.
>>>> John points out that it is not the case. I must be missing something here… but my logic goes like:
>>>>
>>>>
>>>> 1.     The good client creates code_challenge-v and code_verifier-v=S256(code_challenge-v) and sends the client_id-v + code_challenge-v + state to the BadAS Authz EP.
>>>> 2.     BadAS as a client prepares a code_verifier-b and code_challenge-b=S256(code_verifer-b).
>>>> 3.     BadAS redirects to GoodAS with the client_id-v + code_challenge-b + state-v.
>>>> 4.     GoodAS stores the code_challenge-b.
>>>> 5.     GoodAS returns code-v + state-v to the client’s redirect uri.
>>>> 6.     The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished.
>>>>
>>>> Now the attacker tries to use the code-v and code_verifier-v.
>>>>
>>>> ### Case A:
>>>> 7.     The BadAS as a client sends client_id-v + … but he does not have client secret for the good client, so it fails.
>>>>
>>>> ### Case B:
>>>> 8.     The BadAS as a client sends client_id-b + code-v + code_verifier-b + secret-b etc. to GoodAS.
>>>> 9.     GoodAS verifies the code_verifier-b is associated with code-v, but that code-v is not associated with client_id-b, so the token request fails.
>>>>
>>>> ### Case C: cut-n-paste
>>>> 10.  The attacker launches cut-n-paste attack by replacing the code-b with code-v.
>>>> 11.  The verifiers does not match, so fails.
>>>>
>>>> Please let me know what I am missing.
>>> In a step 0 the attacker has the good client create another request in the attackers user agent to get state-0 and code_challange-0
>>>
>>> Step 2 is not required.
>>> Step 3 Bad AS redirects to good AS with client_id_v + state-v + code_challenge-0
>>> Step 4 GoodAS stores code_challenge-0
>>> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
>>> Step 6 The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished.
>>>
>>> Case C1 :  cut and paste
>>> 10.  The attacker launches cut-n-paste attack by inserting code-v into a response using state-0
>>> 11. The client sends code-v and based on state-0 it sends code_verifyer-0 to the good AS token endpoint.
>>> 12. The GoodAS verifies that code-verifyer-0 is correct for code_challange-0 that it bound to code in step 4
>>> 13. The GoodAS receives RT + AT.
>>> 14. The attacker has now used the client to bind the users resource to it’s account and is transferring money or looking at your data.
>>>
>>> This could be 3rd party financial app like Mint as an example or photos or any other PII that could then be used to escalate identity theft.
>>>
>>> This variation of the attack combining cut and paste with confused client was not mentioned in the research papers.
>>>
>>> I found it looking to see if PKCE could be used to mitigate the confused client attack.
>>>
>>> As I mentioned in a response to William, while the current PKCE Challenge methods only make the attack harder by forcing the attacker to get the client to make a step 0 request to get a code_challenge to use in the request,  we could define a new challenge method that would be effective.
>>>
>>> That would remove the need to have a separate mechanism to prevent cut and paste.
>>>
>>> The problem is that the PKCE challenge is independent of state so becomes vulnerable to the confused client.
>>>
>>> What we would need to do is include state in the challenge so that if the AS receives mismatched state and code_challange in step 3 the verification of code verifier will fail. Effectively combining the cut and paste mitigation with PKCE.
>>>
>>> I haven’t had time to write this up, but if the code_challenge == SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || client_id || code-veriyer) ,  then the attacker could not change state, client_id, or token_endpoint  independently of code_challenge.  (note I am using a hash of state to make storage size deterministic for the AS on the grounds that the client already needs to be able to do the hash) (Some attacks  change the client_id in the request so I am including it in the hash)
>>>
>>> This is slightly more complicated than than S256, but not that much.  I wish I had thought of this when we were doing PKCE.   Hit me with the stupid stick, my fault.
>>>
>>> I don’t know if it stops all the confused client attacks though.
>>>
>>> If the client is confidential then it gives up it’s client secret assuming compromised registration, so we can’t really count on that for symmetric client authentication.
>>>
>>> By including the token endpoint in the comparison if the client is sending the code to the attacker the client will use a different token endpoint_uri in to calculate the code_challenge than the GoodAS will use to verify it.    This would stop both cut and paste as well as stopping the attacker from using the code if they get it.   The attacker can’t get Secret for state-0, so it can’t create code_challenge that would be valid.
>>>
>>> This stops the registration attack where the client gets a bad AS discovery endpoint that has all the Good AS info including dynamic registration endpoint but the bad AS token endpoint.   The bad AS would get the token, client_secret and code_verier, but will fail pkce verification because the token endpoint will be wrong.
>>>
>>> The attack where the client registers with the good AS but with bad token endpoint and Authorization endpoint gives the attacker the ability to change the code_challenge that the Good AS is going to see.   It would need to make a new challenge using state and the GoodAS token endpoint and it’s client_id.
>>> To do that it needs the code_verifier to use to calculate the hash to use as the code_challenge value.  As long as the client is not tricked into accepting a replay of the authentication response we should be safe.  The client would need to do replay protection on the code_verifier values before it makes a request to the token endpoint.
>>>
>>> The BadAS could however make up a new code_challenge and code_verifier and use that in the request. For this one the AS would need to do pull discovery on the client to get a key, or the AS needs to return something in the response.  This attack can completely proxy all the endpoints as far as the client is concerned and is taking advantage of the AS saying you are granting permission to site X based on the redirect URI.
>>>
>>> I can’t see PKCE on it’s own being able to stop a client from being used as a redirector back to the attacker unless you also returned the code_challenge in the response from the authorization endpoint.
>>>
>>> Hypothetically if we returned code_challenge in the response from the authorization endpoint and have a new PKCE challenge method we might find it covers all of the attacks.
>>>
>>> We would need to put some serious analysis into this to see if it really covers all the attacks.
>>>
>>> It however doesn’t address the “token†response_type or steeling the access token by impersonating the RS.
>>>
>>> I think the correct way to stop the problem with access tokens is by audience restricting them.
>>> To do that the client needs to provide an audience in it’s request and the AS needs to include that in the AT.
>>>
>>> I included the Authorization_endpoint URI in the hash to detect if the auth request may have been tampered with to change the audience for the AT.
>>>
>>> For implicit we could have a version of PKCE where the AS returns a parameter with S256( client_id || authorization_endpoint URI || resource endpoint URI) to verify the request was not tampered with, and that would allow the AT to be properly audience restricted.
>>>
>>>
>>> This would be a completely new approach not involving discovery, logical names for AS, or link relations.
>>>
>>> Effectively this code_challenge method becomes a signature over parts of the request and the implicit audience of the token_endpoint URI.
>>>
>>> People keep asking why PKCE doesn’t stop these attacks, and it won’t with the current PKCE methods,  however a new method along the lines I sketched out may let it work, or I could be completely wrong.
>> Once you have written down something more definite I promise to implement it promptly such that we can do interop
>> testing early in the process.
>>
>> Before John brought up this new PKCE mode I was on the Option A side of the fence now I’d like to see more
>> of this PKCE idea before committing to one or the other.
>>
>> — Roland
>>
>> â€Everybody should be quiet near a little stream and listen."
>>  From ’Open House for Butterflies’ by Ruth Krauss
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------090906030302000809070306
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
We still have a problem with AT leaking.   I think that needs to be dealt with separately. 
Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request rejected because it is an invalid audience.

    

    I have some concerns with requiring an audience for AT issuance.
    Today a client can get a token with scopes "instantMessaging
    readMail sendMail readContacts writeContacts" and then use that
    token against multiple endpoints (im.example.com mail.example.com
    contacts.example.com). This is a common usage of OAuth2. 

    

    Forcing the client to get a unique AT for each service it wants to
    talk to is a change from the model that is currently in place.

    

    Thanks,

    George

    

    
On 2/23/16 6:17 PM, John Bradley wrote:

    

    

      
The idea of including the state in the PKCE calculation was one I think Hans brought up at the meeting in Darmstadt.

I think we discounted it as not solving the problem because the attacker could manipulate the code_challenge.

As and example the attacker receives the request and changes the code_challenge to one it makes up based on the state from a second request made to the client in it’s browser. 

The attacker can replay the token to the client with the state that will validate the code_callenge or use the token directly at the token endpoint to get a access token as it would know both the client secret and code verifier.

We moved on to look at another way to validate state by passing it to the token endpoint for validation to stop the cut and paste attack.

In thinking again about William and Nat’s question about why not PKCE, I looked at the idea of using PKCE again.

The problem with using PKCE as it is now is that we made the assumption that the attacker could not modify the request.

That got me trying to think of a way to:
 a) stop the attacker from modifying the request (signed request, probably too complicated to be generally deployed)
 b) allow the client to detect if code_challenge has been modified and abort of the request was compromise.

I realized that you could simply echo back the code_challenge from the authorization endpoint and that would allow the client to know if code_challenge had been altered in the request, assuming the attacker can’t modify the response from the legitimate AS.

So if we add that step we now have a client where code_challenge can’t be altered.  

That in it selfs stops the cut and pate attack.  It however still allows an attacker to use the code it receives along with the the code_verifier and client secret to get a AT and RT from the legitimate token endpoint.

So that is not enough Including state in the hash calculation helps against the cut and paste attack but we fixed that by returning code_challenge.

That leaves the other things we were talking about returning from the authorization endpoint.

If we include token_endpoint URI in the hash then any token the client requests thinking it is for the attackers token endpoint won’t generate the same code_challenge as the AS would based on it’s token endpoint.   The attacker would know the code_challenge and the real token endpoint URI but would have to generate a collision in the lifetime of code to use the code.   This would not be possible based on the PKCE analysis.

Returning the code_challenge and including the token_endpoint URI in the hash is the minimum needed for the code flow to stop both cut and paste as well  as protect the code from being used if stolen via a confused client attack.   It doesn’t stop the theft just the use of the token.  So it is mitigating the issue a different way from A and B that are trying to stop the attacker from getting the code.

Given the technique I realized it would be simple enough to also include some other paramaters in the hash
1) The authorization endpoint in the hash causing it not to validate if the client has been given a bad authorization endpoint so the client can modify the request.  
2) The client_id so that it cannot be tampered with in the request.
3) The state  This is tied to the browser instance for XSRF protection.  Including this means it cannot be changed and is another protection against cut and paste.

Including all 4 in the hash may be overkill as they overlap in protection.  I however think that not integrity protecting one of the values might bite us in the future.

We could go farther and include scopes or the whole request but that gets more complicated than it is worth.  We do have a option for request signing already.

So we almost had this at the Darmstadt meeting but it slipped away.

This is not stoping the attack it is protecting code.   

I should point out that some of the attacks like man in the middling registration can still compromise the client secret, making it possible for an attacker to impersonate a client.

Nat’s option B doesn’t have a solution to that ether as far as I can tell.

I think the only option for that is to have a logical identifier for the AS and some sort of discovery check at registration to be certain that you are using the correct registration location.

Option A plus discovery works for that and mitigates confused client but not cut and paste.

We still have a problem with AT leaking.   I think that needs to be dealt with separately. 
Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request rejected because it is an invalid audience.

That should happen at the token endpoint for code.
For implicit it would need to be at the authoriation endpoint and the audience would need to be echoed back to prevent tampering.

The AT can also be protected by POP so I think that code and AT should be kept separate issues.

John B.




      

        
On Feb 23, 2016, at 9:59 PM, Roland Hedberg <roland.hedberg@umu.se> wrote:

In line !



        

          
22 feb 2016 kl. 05:08 skrev John Bradley <ve7jtb@ve7jtb.com>:



          

            
On Feb 22, 2016, at 9:22 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

The risk impact of [case2] is more OAuth specific. The token is stolen as the token is going to be sent to a rogue resource, and the resource can use that to obtain the resource that was supposed to be only available to the proper client.

The risk impact of [case3] is the most grave among these three. Now the attacker can create his own client that impersonates the compromised client.

OAuth-mix-up
---------------------------
OAuth-mix-up draft gives one way of addressing [case2] by introducing a new concept of “issuer†and “discovery†to RFC6749. It also returns client_id and verifies it in 4.2, but if the BadAS has assigned a same client_id to the client, it does not help.


          

          
Client_id are not guaranteed to be unique.  They need to be name spaced by the AS.   In OAuth currently we have no name for the AS this makes that difficult, the client can use the authorization endpoint URI, but that logic may well break in multi tenant situations.   Having a clear issuer string makes it easier for the client.


        

        
I stumbled over exactly this point when I made my implementation follow the Mix-Up draft.
If not discovery is involved I think an AS has to have a name which is different from the endpoint URIs.



        

          

            
One of the issue with this approach is that the central notion of “issuer†is new to the existing servers and clients. The verification rule in 4.1 states “Compare the issuer URL for the authorization server that the client received when it registered at the authorization serverâ€, but in most existing pure OAuth cases, there is no such thing, so you cannot compare. This means that you would have to re-register, and if you are doing that, the per-AS redirect_uri seems to be a much simpler solution.


          

          
The client developers I have talked to really hate per AS redirect URI as being too awkward for deployments.


        

        
I on the other hand found it quite easy to do per AS redirect URIs, so it might well be implementation
dependent rather then contextual.



        

          

            
Per AS Redirect URI
--------------------------------
This does not involve wire protocol changes. It just adds requirements on the redirect uri. This by far is the simplest solution for [case2] (and [case1]), IMHO.

Again, it is not a general framework for finding out tainted communication, so it may have other holes.


          

          
This is probably the hardest for the client developer and for the deployer.  Yes it is simplest from a spec point of view.
We need more developer feedback on this.


        

        
As I said above I found this quite simple to implement.



        

          

            
(Extended) PKCE
---------------------------------
To begin with, it works only with code flow. There has to be something else to deal with implicit flow.

PKCE binds the authorization request/response to the token request.
If used with a confidential client, it seems to mitigate the vulnerability.
John points out that it is not the case. I must be missing something here… but my logic goes like:


1.     The good client creates code_challenge-v and code_verifier-v=S256(code_challenge-v) and sends the client_id-v + code_challenge-v + state to the BadAS Authz EP.
2.     BadAS as a client prepares a code_verifier-b and code_challenge-b=S256(code_verifer-b).
3.     BadAS redirects to GoodAS with the client_id-v + code_challenge-b + state-v.
4.     GoodAS stores the code_challenge-b.
5.     GoodAS returns code-v + state-v to the client’s redirect uri.
6.     The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished.

Now the attacker tries to use the code-v and code_verifier-v.

### Case A:
7.     The BadAS as a client sends client_id-v + … but he does not have client secret for the good client, so it fails.

### Case B:
8.     The BadAS as a client sends client_id-b + code-v + code_verifier-b + secret-b etc. to GoodAS.
9.     GoodAS verifies the code_verifier-b is associated with code-v, but that code-v is not associated with client_id-b, so the token request fails.

### Case C: cut-n-paste
10.  The attacker launches cut-n-paste attack by replacing the code-b with code-v.
11.  The verifiers does not match, so fails.

Please let me know what I am missing.


          

          
In a step 0 the attacker has the good client create another request in the attackers user agent to get state-0 and code_challange-0

Step 2 is not required.
Step 3 Bad AS redirects to good AS with client_id_v + state-v + code_challenge-0
Step 4 GoodAS stores code_challenge-0
Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
Step 6 The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished.

Case C1 :  cut and paste
10.  The attacker launches cut-n-paste attack by inserting code-v into a response using state-0
11. The client sends code-v and based on state-0 it sends code_verifyer-0 to the good AS token endpoint.
12. The GoodAS verifies that code-verifyer-0 is correct for code_challange-0 that it bound to code in step 4
13. The GoodAS receives RT + AT.
14. The attacker has now used the client to bind the users resource to it’s account and is transferring money or looking at your data.

This could be 3rd party financial app like Mint as an example or photos or any other PII that could then be used to escalate identity theft.

This variation of the attack combining cut and paste with confused client was not mentioned in the research papers.

I found it looking to see if PKCE could be used to mitigate the confused client attack.

As I mentioned in a response to William, while the current PKCE Challenge methods only make the attack harder by forcing the attacker to get the client to make a step 0 request to get a code_challenge to use in the request,  we could define a new challenge method that would be effective.

That would remove the need to have a separate mechanism to prevent cut and paste.

The problem is that the PKCE challenge is independent of state so becomes vulnerable to the confused client.

What we would need to do is include state in the challenge so that if the AS receives mismatched state and code_challange in step 3 the verification of code verifier will fail. Effectively combining the cut and paste mitigation with PKCE.

I haven’t had time to write this up, but if the code_challenge == SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || client_id || code-veriyer) ,  then the attacker could not change state, client_id, or token_endpoint  independently of code_challenge.  (note I am using a hash of state to make storage size deterministic for the AS on the grounds that the client already needs to be able to do the hash) (Some attacks  change the client_id in the request so I am including it in the hash)

This is slightly more complicated than than S256, but not that much.  I wish I had thought of this when we were doing PKCE.   Hit me with the stupid stick, my fault.

I don’t know if it stops all the confused client attacks though.

If the client is confidential then it gives up it’s client secret assuming compromised registration, so we can’t really count on that for symmetric client authentication.

By including the token endpoint in the comparison if the client is sending the code to the attacker the client will use a different token endpoint_uri in to calculate the code_challenge than the GoodAS will use to verify it.    This would stop both cut and paste as well as stopping the attacker from using the code if they get it.   The attacker can’t get Secret for state-0, so it can’t create code_challenge that would be valid.

This stops the registration attack where the client gets a bad AS discovery endpoint that has all the Good AS info including dynamic registration endpoint but the bad AS token endpoint.   The bad AS would get the token, client_secret and code_verier, but will fail pkce verification because the token endpoint will be wrong.

The attack where the client registers with the good AS but with bad token endpoint and Authorization endpoint gives the attacker the ability to change the code_challenge that the Good AS is going to see.   It would need to make a new challenge using state and the GoodAS token endpoint and it’s client_id.
To do that it needs the code_verifier to use to calculate the hash to use as the code_challenge value.  As long as the client is not tricked into accepting a replay of the authentication response we should be safe.  The client would need to do replay protection on the code_verifier values before it makes a request to the token endpoint.

The BadAS could however make up a new code_challenge and code_verifier and use that in the request. For this one the AS would need to do pull discovery on the client to get a key, or the AS needs to return something in the response.  This attack can completely proxy all the endpoints as far as the client is concerned and is taking advantage of the AS saying you are granting permission to site X based on the redirect URI.

I can’t see PKCE on it’s own being able to stop a client from being used as a redirector back to the attacker unless you also returned the code_challenge in the response from the authorization endpoint.

Hypothetically if we returned code_challenge in the response from the authorization endpoint and have a new PKCE challenge method we might find it covers all of the attacks.

We would need to put some serious analysis into this to see if it really covers all the attacks.

It however doesn’t address the “token†response_type or steeling the access token by impersonating the RS.

I think the correct way to stop the problem with access tokens is by audience restricting them.
To do that the client needs to provide an audience in it’s request and the AS needs to include that in the AT.

I included the Authorization_endpoint URI in the hash to detect if the auth request may have been tampered with to change the audience for the AT.

For implicit we could have a version of PKCE where the AS returns a parameter with S256( client_id || authorization_endpoint URI || resource endpoint URI) to verify the request was not tampered with, and that would allow the AT to be properly audience restricted.


This would be a completely new approach not involving discovery, logical names for AS, or link relations.

Effectively this code_challenge method becomes a signature over parts of the request and the implicit audience of the token_endpoint URI.

People keep asking why PKCE doesn’t stop these attacks, and it won’t with the current PKCE methods,  however a new method along the lines I sketched out may let it work, or I could be completely wrong.


        

        
Once you have written down something more definite I promise to implement it promptly such that we can do interop
testing early in the process.

Before John brought up this new PKCE mode I was on the Option A side of the fence now I’d like to see more
of this PKCE idea before committing to one or the other.

— Roland

â€Everybody should be quiet near a little stream and listen."
>From ’Open House for Butterflies’ by Ruth Krauss



      

      

      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------090906030302000809070306--


From nobody Wed Feb 24 09:54:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B821B3A60 for ; Wed, 24 Feb 2016 09:53:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYFFFTou7emN for ; Wed, 24 Feb 2016 09:53:54 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC1C1B2E82 for ; Wed, 24 Feb 2016 09:53:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kk01nIX9s3hhRkAKN55lWEp+zHejV6wJVR2UwdCRfyw=; b=nF5t6mrQDxshFfxhpyzha9xhWmEZh3V68u9twleyrNZpxS1zKJhCLIn8KaqC2MUN73/9UI+WrqiGsZ+ltiRUGnGvoDqAxTnkEskOYnml63cNGFevlYin38NPAo4i+hiBQ6eCZpEf5yLFIQuV/MUZyYP0cennGBDtTpbLP9gAQyE=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 17:53:31 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 17:53:31 +0000
From: Mike Jones 
To: "Phil Hunt (IDM)" , Nat Sakimura 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoA==
Date: Wed, 24 Feb 2016 17:53:31 +0000
Message-ID: 
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: 92f4acf7-3f8c-4a0c-b955-08d33d436882
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:4O0KkqUwk5hhvM/FyFKgEQi3oX4vD0ot0vSIztDxk85If+0ToIr+MYrmwSnuonNiooReVi7eQ9LwzXyPKOd3FZ3HE+299qddQj5P0OSZSMefXmdOPsAWaPMzieB10KvYHq5jo5uq8+UupHPk7PR7fg==; 24:QU4uEm1LZiLtUIWC9t3UhBnxt0EYLyLx2AkASTH2xGJNN9XfqqTgxJXiAkZrnkbwYZssDC2d4uSUu+K/vAiBg6lwfbwyj/c74ndtjt0rnqg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(24454002)(19580405001)(19580395003)(586003)(93886004)(74316001)(3280700002)(3660700001)(3846002)(5003600100002)(19625215002)(33656002)(66066001)(1220700001)(19609705001)(4326007)(15975445007)(16601075003)(2900100001)(2950100001)(77096005)(2906002)(1680700002)(10290500002)(5008740100001)(5005710100001)(790700001)(1096002)(102836003)(6116002)(5004730100002)(122556002)(10400500002)(8990500004)(11100500001)(40100003)(76576001)(19300405004)(76176999)(92566002)(99286002)(87936001)(106116001)(5001770100001)(86612001)(19617315012)(189998001)(5001960100002)(10090500001)(50986999)(54356999)(5002640100001)(86362001)(16236675004)(336705003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44220A3CDA0552D439C9A2AF5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 17:53:31.2060 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 17:53:59 -0000

--_000_BY2PR03MB44220A3CDA0552D439C9A2AF5A50BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3Jl
IGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVk
Lg0KDQpOb25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlv
bmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0ZWQuICBJ4oCZbSBzdXJl
IGl0IHdpbGwgYmUuICBTb21lIGFwcGxpY2F0aW9ucyB3aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9j
YXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsg
aGVhZGVycy4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgYXBwbGljYXRpb24tc3BlY2lmaWMgLndl
bGwta25vd24gdmFsdWVzLiAgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2
ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4gIEFsbCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZp
bmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgZm9ybWF0IGFuZCBub25lIG9mIHRoZW0g
Y2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwg
ZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy4NCg0KU28gYnkgYWxsIG1lYW5zLCB0aGUgd29ya2lu
ZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3
IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250ZXh0cy4gIEF0
IHRoZSBzYW1lIHRpbWUsIHdlIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3
aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hh
bmlzbXMgd2lsbCBuZWVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElETSkNClNlbnQ6IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgODozOSBBTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2Fr
aW11cmFAZ21haWwuY29tPg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0K
U3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQpJ
IGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRpb24gaGFzIHRv
IGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50IGl0IHdhbnRz
IHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEgZm9yLg0KDQpTbyBpZiByZXMuZXhhbXBsZS5l
dmlsLmNvbTxodHRwOi8vcmVzLmV4YW1wbGUuZXZpbC5jb20+IGlzIG5vdCBhIHZhbGlkIHJlc291
cmNlIGVuZHBvaW50IGZvciBhcy5leGFtcGxlLmNvbTxodHRwOi8vYXMuZXhhbXBsZS5jb20+IHRo
ZSBhdXRoeiBkaXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3Ro
aW5nKS4NCg0KVGhlcmUgbWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUg
ZGlzY292ZXJ5LiBPciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4NCg0KT25lIG9mIE9B
dXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0
aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVu
IGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVk
IDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4g
ZGlzY292ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVt
cyBpbXBvcnRhbnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRp
b24gb2YgZW5kcG9pbnRzIGV0Yy4NCg0KVGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFi
b3V0IHdnbGMgb24gZGlzY292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAg
YWRvcHRpb24gYnV0IHdlIGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1l
bnRzIElNTy4NCg0KSSBhbSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQg
aW50byBzb21lIGRyYWZ0IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2Fu
J3QgZG8gaXQgbm93Lg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6MTIsIE5hdCBT
YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3
cm90ZToNCkhpIFBoaWwsDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0
YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0
IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLg0KDQpUaGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMg
dGhhdA0KDQoxLiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4NCjIuIEFTIHRl
bGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4N
Cg0KRXZlbiBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94
aWVzIHRvIHRoZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRo
ZXJlIGFzIHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRo
ZSBjbGllbnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uDQoNCk5hdA0KDQoyMDE25bm0
MuaciDI05pelKOawtCkgMjM6NTkgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCk5hdCwNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBo
YXZpbmcgdGhlIHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhv
cml6YXRpb24gc2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0
d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVl
ZCB0byBiZSBib3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMg
KHRoZSByZXNvdXJjZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KSWYg
YSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWlu
ZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3
aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJl
c291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0
IGhhdmUgYSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJj
ZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUg
YWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlv
biBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuDQoN
ClRoZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGll
bnQgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCBy
ZXNvdXJjZSBlbmRwb2ludC4NCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGgg
YnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KUGhpbA0K
DQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBl
bmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb20+DQoNCg0KDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMzo1NCBBTSwgTmF0IFNha2ltdXJh
IDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0K
DQoNCkhpIFRob21hcywNCg0KaW5saW5lOg0KDQoyMDE25bm0MuaciDIy5pelKOaciCkgMTg6NDQg
VGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5j
b20+PjoNCkNvdWxkbid0IHRoZSBkb2N1bWVudCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT8N
CkkgcXVpdGUgbGlrZSB0aGUgaWRlYSBvZiBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIGlmIHlv
dSByZWFsbHkgd2FudCB0byBkbyBkaXNjb3ZlcnksIGFuZCBsZWF2ZSBpdCBvcGVuIHRvIGltcGxl
bWVudGVycyAvIHRvIG90aGVyIHNwZWNzIHRvIGRlZmluZSBhIC53ZWxsLWtub3duIFVSTCBmb3Ig
ImF1dG8tY29uZmlndXJhdGlvbiIuDQpUaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291bGQg
dGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMgZHJhZnQt
c2FraW11cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMgZm9y
IG90aGVyIG1ldGFkYXRhIHNwZWNzIChsaWtlIE9wZW5JRCBDb25uZWN0KS4NCldpdGggZHJhZnQt
c2FraW11cmEtb2F1dGgtbWV0YSdzICJkdXJpIiBhbmQgdGhlICJzY29wZSIgYXR0cmlidXRlIG9m
IFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlv
dSBuZWVkIHRvIHByb2NlZWQNCg0KWXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1aXJlbWVudHMg
dG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90Pw0KDQpJbiBPQXV0aCdzIGNhc2UsIHRoZSByZXNvdXJj
ZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0bHkgY291cGxl
ZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4pDQpTbywgdGhl
IHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIGVpdGhlciB0aGUgbG9jYXRp
b24gb2YgdGhlIGF1dGh6IGVuZHBvaW50LiBJbiBzb21lIHRydXN0ZWQgZW52aXJvbm1lbnQsIHRo
ZSByZXNvdXJjZSBtYXkgYXMgd2VsbCByZXR1cm4gdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBz
ZXJ2ZXIgY29uZmlndXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBoYXZl
IHRvIGRlY2lkZSBvbiB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZyZWVz
IHVwIGRldmVsb3BlcnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlzaW9u
cyBldGMuIFdlIHNob3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBhcyBt
dWNoIGFzIHBvc3NpYmxlLg0KDQood2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFyZSBzZXZlcmFsIEFT
cyBlYWNoIHdpdGggZGlmZmVyZW50IHNjb3Blczsgc291bmRzIGxpa2UgYW4gZWRnZS1jYXNlIHRv
IG1lIHRob3VnaDsgbWF5YmUgUkZDNjc1MCBzaG91bGQgaW5zdGVhZCBiZSB1cGRhdGVkIHdpdGgg
c3VjaCBhIHBhcmFtZXRlciBzdWNoIHRoYXQgYW4gUlMgY291bGQgcmV0dXJuIHNldmVyYWwgV1dX
LUF1dGhlbnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRzIG93biAic2NvcGUiIGFuZCAiZHVy
aSIgdmFsdWU/KQ0KDQpZZWFoLCBJIGd1ZXNzIGl0IGlzIGFuIGVkZ2UgY2FzZS4gSSB3b3VsZCBy
YXRoZXIgbGlrZSB0byBzZWUgdGhlc2UgYXV0aHogc2VydmVycyB0byBkZXZlbG9wIGEgdHJ1c3Qg
ZnJhbWV3b3JrIHVuZGVyIHdoaWNoIHRoZXkgY2FuIGFncmVlIG9uIGEgc2luZ2xlIHNldCBvZiBj
b21tb24gc2NvcGUgcGFyYW1ldGVyIHZhbHVlcy4NCg0KQ2hlZXJzLA0KDQpOYXQNCg0KDQpPbiBG
cmksIEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l
ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVGhlIG5ld2x5LXRyaW1tZWQgT0F1
dGggRGlzY292ZXJ5IGRvY3VtZW50IGlzIGhlbHBmdWwgYW5kIG1vdmluZyBpbiB0aGUgcmlnaHQg
ZGlyZWN0aW9uLiBJdCBkb2VzLCBob3dldmVyLCBzdGlsbCBoYXZlIHRvbyBtYW55IHZlc3RpZ2Vz
IG9mIGl0cyBPcGVuSUQgQ29ubmVjdCBvcmlnaW5zLiBPbmUgaXNzdWUgaW4gcGFydGljdWxhciBz
dGlsbCByZWFsbHkgYm90aGVycyBtZTogdGhlIHVzZSBvZiDigJwvLndlbGwta25vd24vb3Blbmlk
LWNvbmZpZ3VyYXRpb27igJ0gaW4gdGhlIGRpc2NvdmVyeSBwb3J0aW9uLiBJcyB0aGlzIGFuIE9B
dXRoIGRpc2NvdmVyeSBkb2N1bWVudCwgb3IgYW4gT3BlbklEIENvbm5lY3Qgb25lPyBUaGVyZSBp
cyBhYnNvbHV0ZWx5IG5vIGNvbXBlbGxpbmcgcmVhc29uIHRvIHRpZSB0aGUgVVJMIHRvIHRoZSBP
SURDIGRpc2NvdmVyeSBtZWNoYW5pc20uDQoNCkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndl
bGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlz
Y292ZXJ5IGxvY2F0aW9uLCBhbmQgc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUg
cmVhY2hhYmxlIGZyb20g4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlm
IHRoZSBzZXJ2ZXIgYWxzbyBwcm92aWRlcyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21h
aW4uIE90aGVyIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1l
cyB0byBkZXNjcmliZSBPQXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIg
c2VydmljZS1zcGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1lbnQuDQoNCiDigJQgSnVzdGluDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoN
Cg==

--_000_BY2PR03MB44220A3CDA0552D439C9A2AF5A50BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x
DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6
aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lk
ZWx5IGRlcGxveWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+
Tm9uZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0aW5nIHRoYXQgYWRkaXRpb25hbCBy
ZWxhdGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVhdGVkLiZuYnNwOyBJ4oCZbSBzdXJl
IGl0IHdpbGwgYmUuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25zIHdpbGwgdXNlIFdlYkZpbmdlciB0
bw0KIGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiZuYnNwOyBTb21lIHdpbGwgcG9zc2li
bHkgdXNlIGxpbmsgaGVhZGVycy4mbmJzcDsgU29tZSB3aWxsIHBvc3NpYmx5IHVzZSBhcHBsaWNh
dGlvbi1zcGVjaWZpYyAud2VsbC1rbm93biB2YWx1ZXMuJm5ic3A7IEnigJltIHN1cmUgdGhlcmXi
gJlzIG90aGVyIHRoaW5ncyBJIGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuJm5ic3A7IEFs
bCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1l
bnQNCiBmb3JtYXQgYW5kIG5vbmUgb2YgdGhlbSBjaGFuZ2UgaXQg4oCTIG90aGVyIHRoYW4gcG9z
c2libHkgdG8gcmVnaXN0ZXIgYWRkaXRpb25hbCBkaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U28gYnkgYWxsIG1lYW5z
LCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcg
cG9zc2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBj
b250ZXh0cy4mbmJzcDsgQXQgdGhlIHNhbWUgdGltZSwgd2UNCiBjYW4gZmluaXNoIHN0YW5kYXJk
aXppbmcgdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0aGF0
IGFsbCBvZiB0aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQgKElE
TSk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFN
PGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDs8
YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRmLm9yZyZndDsgJmx0O29hdXRoQGlldGYub3Jn
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292
ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgYW0gc3VnZ2VzdGluZyB0aGF0IHBhcnQgb2YgdGhlIGRpc2NvdmVyeSBzb2x1
dGlvbiBoYXMgdG8gYmUgdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoYXQgcmVzb3VyY2UgZW5kcG9p
bnQgaXQgd2FudHMgdGhlIG9hdXRoIGNvbmZpZ3VyYXRpb24gZGF0YSBmb3IuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBw
bGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGlmIDxhIGhyZWY9Imh0
dHA6Ly9yZXMuZXhhbXBsZS5ldmlsLmNvbSI+cmVzLmV4YW1wbGUuZXZpbC5jb208L2E+IGlzIG5v
dCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50IGZvcg0KPGEgaHJlZj0iaHR0cDovL2FzLmV4YW1w
bGUuY29tIj5hcy5leGFtcGxlLmNvbTwvYT4gdGhlIGF1dGh6IGRpc2NvdmVyeSBzaG91bGQgZmFp
bCBpbiBzb21lIHdheSAoZWcgcmV0dXJuIG5vdGhpbmcpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h
dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8g
ZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3ZlcnkuIE9yIGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlz
Y292ZXJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxT
aWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbmUgb2YgT0F1dGgncyBzdHJlbmd0aCdzIGFuZCB3ZWFrbmVzc2VzIGlzIHRoYXQgdGhlIHRh
cmdldCBvZiBhdXRob3JpemF0aW9uICh0aGUgcmVzb3VyY2UpIGlzIG5ldmVyIHNwZWNpZmllZC4g
SXQgaXMgb2Z0ZW4gYm91bmQgdXAgaW4gdGhlIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIGFuIG9m
dGVuIGltcGxpZWQgMToxIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHJlc291cmNlIGFuZCBhcy4gR2l2
ZW4gdGhhdCBpbg0KIGRpc2NvdmVyeSBwaGFzZSByZWdpc3RyYXRpb24gaGFzIG5vdCB5ZXQgb2Nj
dXJyZWQgaXQgc2VlbXMgaW1wb3J0YW50IHRoYXQgdGhlIGNsaWVudCBrbm93IGl0IGhhcyBhIHZh
bGlkIGNvbWJpbmF0aW9uIG9mIGVuZHBvaW50cyBldGMuJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0
dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgd2h5IEkgd2FzIGRpc2FwcG9pbnRl
ZCBhYm91dCB3Z2xjIG9uIGRpc2NvdmVyeS4gV2UgaGFkIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGdy
b3VwIGFkb3B0aW9uIGJ1dCB3ZSBoYXZlbid0IHJlYWxseSBkZWZpbmVkIHRoZSBmdWxsIHJlcXVp
cmVtZW50cyBJTU8uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl
TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkkgYW0gb24gdmFjYXRpb24gb3IgSSB3b3VsZCBwdXQgc29tZSB0aG91Z2h0IGludG8g
c29tZSBkcmFmdCBjaGFuZ2VzIG9yIGEgbmV3IGRyYWZ0LiBJIGFwb2xvZ2l6ZSBJIGNhbid0IGRv
IGl0IG5vdy4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
cj4NCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6MTIsIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5IaSBQaGlsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhlIEFTIG1ldGFkYXRhIHNob3Vs
ZCBpbmNsdWRlIHRoZSBSUyBVUklzPyBDdXJyZW50bHksIGl0IGRvZXMgbm90LCBidXQgaXQgY2Fu
IGJlIGRvbmUsIEkgZ3Vlc3MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3YXkgb2F1dGgtbWV0YSB3b3JrcyBpcyB0aGF0Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjEuIFJTIHRlbGxzIHRoZSBjbGllbnQgd2hlcmUgdGhlIEFTIGlzLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gQVMgdGVsbHMgdGhl
IGNsaWVudCB3aGljaCBSUyBlbmRwb2ludHMgdGhlIHRva2VuIGNhbiBiZSB1c2VkLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVu
IGlmIHRoZXJlIGlzIGEgYmFkIEFTIHdpdGggYSB2YWxpZCBjZXJ0cyB0aGF0IHByb3hpZXMgdG8g
dGhlIGdvb2QgUlMsIHRoZSBjbGllbnQgd2lsbCBub3Qgc2VuZCB0aGUgdG9rZW4gdGhlcmUgYXMg
dGhlIGF1dGh6IHNlcnZlciB3aWxsIHNheSB0aGF0IGlzIG5vdCB0aGUgcGxhY2UgdGhlIGNsaWVu
dCBtYXkgd2FudCB0byBzZW5kIHRoZSB0b2tlbiB0by4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpOYXQ8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj7mnIg8L3NwYW4+MjQ8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuawtDwvc3Bhbj4p
IDIzOjU5IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t
Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IHN1cmUg
dGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRz
IGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNo
aXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2
ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeQ0KIGVu
ZHBvaW50cyAodGhlIHJlc291cmNlIGFuZC9vciB0aGUgb2F1dGggc2VydmljZSBkaXNjb3Zlcnkp
LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm
IGEgY2xpZW50IGRpc2NvdmVycyBhIGZha2UgcmVzb3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlp
bmcgZm9yIGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIgdGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMg
d2lsbCBub3QgbGVhZCB0aGUgY2xpZW50IHRvIHVuZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyBy
ZXNvdXJjZSBzZXJ2ZXIuIFJhdGhlciB0aGUgZmFrZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVz
dCBoYXZlDQogYSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50
ZXJjZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdl
cmUgYWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXph
dGlvbiBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHku
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo
ZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQg
dGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNv
dXJjZSBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3Vs
ZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6
Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRp
ZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxh
IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwu
aHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMjQsIDIw
MTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJh
QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PGJyPg0KSGkgVGhvbWFzLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5pbmxpbmU6Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4yMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7lubQ8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pyI
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
l6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+
5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPikNCiAxODo0NCBUaG9tYXMgQnJveWVyICZsdDs8
YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95
ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo
dDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNv
dWxkbid0IHRoZSBkb2N1bWVudCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT88bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+SSBxdWl0ZSBsaWtlIHRoZSBpZGVhIG9mJm5ic3A7ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0
YSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0
byBpbXBsZW1lbnRlcnMgLyB0byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBV
UkwgZm9yICZxdW90O2F1dG8tY29uZmlndXJhdGlvbiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5UaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291bGQgdGhlbiBlaXRoZXIgYmUgdXNlZCBh
cy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1t
ZXRhIG1ldGFkYXRhIGF0IHRoZSBSUzsgb3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEg
c3BlY3MgKGxpa2UNCiBPcGVuSUQgQ29ubmVjdCkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XaXRoJm5i
c3A7ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSdzICZxdW90O2R1cmkmcXVvdDsgYW5kIHRoZSAm
cXVvdDtzY29wZSZxdW90OyBhdHRyaWJ1dGUgb2YgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBo
ZWFkZXIsIHlvdSBoYXZlIGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8gcHJvY2VlZCZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5ZdXAuIFRoYXQncyBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyB0byBi
ZSBSRVNUZnVsLCBpcyBpdCBub3Q/ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPkluIE9BdXRoJ3MgY2FzZSwgdGhlIHJlc291cmNlIGFuZCB0aGUg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIHVzdWFsbHkgdGlnaHRseSBjb3VwbGVkLiAoT3RoZXJ3
aXNlLCB5b3UgbmVlZCBhbm90aGVyIHNwZWNzIGxpa2UgVU1BLikmbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5TbywgdGhlIHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIGVp
dGhlciB0aGUgbG9jYXRpb24gb2YgdGhlIGF1dGh6IGVuZHBvaW50LiBJbiBzb21lIHRydXN0ZWQg
ZW52aXJvbm1lbnQsIHRoZSByZXNvdXJjZSBtYXkgYXMgd2VsbCByZXR1cm4gdGhlIGxvY2F0aW9u
IG9mIHRoZQ0KIGF1dGh6IHNlcnZlciBjb25maWd1cmF0aW9uIGRhdGEuIEluIHRoZXNlIGNhc2Vz
LCB5b3UgZG8gbm90IGhhdmUgdG8gZGVjaWRlIG9uIHdoYXQgLndlbGwta25vd24gdXJpIGFzIHlv
dSBzYXkuIFRoaXMgZnJlZXMgdXAgZGV2ZWxvcGVycyBmcm9tIGNvbmZpZ3VyYXRpb24gZmlsZSBs
b2NhdGlvbiBjb2xsaXNpb25zIGV0Yy4gV2Ugc2hvdWxkIHN0cml2ZSBub3QgdG8gcG9sbHV0ZSB0
aGUgdXJpIHNwYWNlIGFzIG11Y2ggYXMgcG9zc2libGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
KHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVu
dCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJG
QzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3Vj
aA0KIHRoYXQgYW4gUlMgY291bGQgcmV0dXJuIHNldmVyYWwgV1dXLUF1dGhlbnRpY2F0ZTogQmVh
cmVyLCBlYWNoIHdpdGggaXRzIG93biAmcXVvdDtzY29wZSZxdW90OyBhbmQgJnF1b3Q7ZHVyaSZx
dW90OyB2YWx1ZT8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlllYWgsIEkgZ3Vlc3MgaXQgaXMgYW4g
ZWRnZSBjYXNlLiBJIHdvdWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2ZXJz
IHRvIGRldmVsb3AgYSB0cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdyZWUg
b24gYSBzaW5nbGUgc2V0IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXINCiB2YWx1ZXMuJm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJzLCZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5hdDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5PbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmlj
aGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+
anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
VGhlIG5ld2x5LXRyaW1tZWQgT0F1dGggRGlzY292ZXJ5IGRvY3VtZW50IGlzIGhlbHBmdWwgYW5k
IG1vdmluZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLiBJdCBkb2VzLCBob3dldmVyLCBzdGlsbCBo
YXZlIHRvbyBtYW55IHZlc3RpZ2VzIG9mIGl0cyBPcGVuSUQgQ29ubmVjdCBvcmlnaW5zLiBPbmUN
CiBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNlIG9m
IOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292ZXJ5
IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBPcGVu
SUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFzb24g
dG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5DQogbWVjaGFuaXNtLjxicj4NCjxi
cj4NCkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24vb2F1dGgtYXV0aG9yaXph
dGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxvY2F0aW9uLCBhbmQgc3Rh
dGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxlIGZyb20g4oCcLy53ZWxs
LWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2ZXIgYWxzbyBwcm92aWRl
cyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVyDQogYXBwbGljYXRpb25z
IFNIT1VMRCB1c2UgdGhlIHNhbWUgcGFyYW1ldGVyIG5hbWVzIHRvIGRlc2NyaWJlIE9BdXRoIGVu
ZHBvaW50cyBhbmQgZnVuY3Rpb25zIGluc2lkZSB0aGVpciBzZXJ2aWNlLXNwZWNpZmljIGRpc2Nv
dmVyeSBkb2N1bWVudC48YnI+DQo8YnI+DQombmJzcDvigJQgSnVzdGluPGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls
aW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BY2PR03MB44220A3CDA0552D439C9A2AF5A50BY2PR03MB442namprd_--


From nobody Wed Feb 24 10:01:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677D81A8704 for ; Wed, 24 Feb 2016 10:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 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_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 e8EK9jGh7rS3 for ; Wed, 24 Feb 2016 10:01:36 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D3E1A1B7F for ; Wed, 24 Feb 2016 10:01:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lA3s4KpKSuyFO5FGfA8VYszLiLXV8EkupHqsjZ3KnPA=; b=GAIbMmKjaoaWY8oNemXNhKaIlvNdtKQyqsEVf2jfpLx/gdhc8n4gURDQmmUQyfdiZQb08EjhjAtNpFe5Lp2rwvyyXtXhOkhpvLpfvLA1kN6WoMWwdUFDrFOKQsHnxIha/iq1Ap+8wY5zEWP4xpuS/PcQXEbdb4x1wFID8DrG66E=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 18:01:18 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 18:01:17 +0000
From: Anthony Nadalin 
To: Mike Jones , "Phil Hunt (IDM)" , Nat Sakimura 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaUuxGHT78V06lUef7azsq7p831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABTAgIAAAIAg
Date: Wed, 24 Feb 2016 18:01:17 +0000
Message-ID: 
References:       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:9::48a]
x-ms-office365-filtering-correlation-id: b17752a6-3110-46cf-d59e-08d33d447e4c
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:ziVCx23WRVAOmQRxlPROpM/hYefKMMNSlN5jGxi/DhgkBm+yTbB/H9OFtwCq8g8CbYNcJmGGfJGenCFWoFa/bVnE1AtcdsAxrMvQb3xCfdcv5NV10os0Qk1noeoEd6QBe9xbFUCFgeR1t6ou1+HPOg==; 24:8SGu6EmYIwuF2qFlyEWAFQQngt6VKwoWKUCucn6w7jKVvmKWhOUOpKZmqgcQe6/oWVGqPAIMAWUtNeiWorbf0gMQiUDuhl7dzkrfcm32Gzs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(19617315012)(92566002)(3280700002)(790700001)(74316001)(99286002)(3660700001)(6116002)(2561002)(1511001)(16236675004)(10090500001)(19580395003)(77096005)(19580405001)(10290500002)(5001770100001)(86362001)(40100003)(2950100001)(5005710100001)(15975445007)(19625215002)(2900100001)(122556002)(8990500004)(33656002)(10400500002)(76176999)(54356999)(19300405004)(1220700001)(5001960100002)(106116001)(50986999)(87936001)(102836003)(5008740100001)(5003600100002)(2906002)(4326007)(1096002)(5004730100002)(586003)(93886004)(76576001)(189998001)(5002640100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234658E888AC37750E18D4EA6A50BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 18:01:17.3219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:01:41 -0000

--_000_BN3PR0301MB1234658E888AC37750E18D4EA6A50BN3PR0301MB1234_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBUaGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNv
cmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95
ZWQuDQpUaGF0IG1heSBiZSB3aWRlbHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRlbHkg
ZGVwbG95ZWQgZm9yIE9BdXRoLiBUaGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5p
c20gZGlzY292ZXJ5IGZvciBlbmRwb2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90IGJlIGluIGFu
IE9BdXRoIHN0YW5kYXJkIHNpbmNlIGl04oCZcyByZWFsbHkgbm90IGRlYWx0IHdpdGguIE5vdyB0
aGF0IGFsbCB0aGlzIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpdCBtYWtlcyBwb2tpbmcgYXJv
dW5kIHRoZSBlbmRwb2ludCBtb3JlIGZvY3VzZWQgZm9yIHBlb3BsZSB0aGF0IHdhbnQgdG8gZGlz
cnVwdCB5b3VyIGVuZHBvaW50cywgdGhhdCBpcyByZWFsbHkgbm90IGFkZHJlc3NlZCBpbiB0aGUg
c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhdCBhbGwNCg0KRnJvbTogT0F1dGggW21h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2Vu
dDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA5OjU0IEFNDQpUbzogUGhpbCBIdW50IChJ
RE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwu
Y29tPg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQpUaGUgcG9pbnQgb2Yg
dGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1
bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuDQoNCk5vbmUgb2Yg
TmF0IG9yIEpvaG4gb3IgSSBhcmUgc3VnZ2VzdGluZyB0aGF0IGFkZGl0aW9uYWwgcmVsYXRlZCBm
dW5jdGlvbmFsaXR5IHdvbuKAmXQgYmUgY3JlYXRlZC4gIEnigJltIHN1cmUgaXQgd2lsbCBiZS4g
IFNvbWUgYXBwbGljYXRpb25zIHdpbGwgdXNlIFdlYkZpbmdlciB0byBsb2NhdGUgdGhlIGRpc2Nv
dmVyeSBtZXRhZGF0YS4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJzLiAgU29t
ZSB3aWxsIHBvc3NpYmx5IHVzZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyAud2VsbC1rbm93biB2YWx1
ZXMuICBJ4oCZbSBzdXJlIHRoZXJl4oCZcyBvdGhlciB0aGluZ3MgSSBoYXZlbuKAmXQgZXZlbiB0
aG91Z2h0IGFib3V0LiAgQWxsIG9mIHRoZXNlIGRlcGVuZCB1cG9uIGhhdmluZyBhIGRpc2NvdmVy
eSBtZXRhZGF0YSBkb2N1bWVudCBmb3JtYXQgYW5kIG5vbmUgb2YgdGhlbSBjaGFuZ2UgaXQg4oCT
IG90aGVyIHRoYW4gcG9zc2libHkgdG8gcmVnaXN0ZXIgYWRkaXRpb25hbCBkaXNjb3ZlcnkgbWV0
YWRhdGEgdmFsdWVzLg0KDQpTbyBieSBhbGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3VwIHNob3Vs
ZCBjb250aW51ZSBkaXNjdXNzaW5nIGludmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRlZCBtZWNo
YW5pc21zIHRoYXQgbWFrZSBzZW5zZSBpbiBzb21lIGNvbnRleHRzLiAgQXQgdGhlIHNhbWUgdGlt
ZSwgd2UgY2FuIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBhbHJlYWR5IHdpZGVseSBkZXBsb3ll
ZCBjb3JlIGZ1bmN0aW9uYWxpdHkgdGhhdCBhbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyB3aWxsIG5l
ZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudCAoSURNKQ0KU2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAyNCwgMjAxNiA4OjM5IEFNDQpUbzogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5j
b208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+DQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4+IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0K
DQpJIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRpb24gaGFz
IHRvIGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50IGl0IHdh
bnRzIHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEgZm9yLg0KDQpTbyBpZiByZXMuZXhhbXBs
ZS5ldmlsLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwJTNhJTJmJTJmcmVzLmV4YW1wbGUuZXZpbC5jb20mZGF0YT0wMSU3YzAxJTdjdG9u
eW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3
YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1QYyUyYjdpbG5EWWdm
allvVHNRV29abnBvYkclMmJWSnA1V3U5Y0dwRlVnejNTMCUzZD4gaXMgbm90IGEgdmFsaWQgcmVz
b3VyY2UgZW5kcG9pbnQgZm9yIGFzLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcy5leGFtcGxlLmNvbSZk
YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFh
YWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNk
YXRhPTYlMmJxeGglMmY3VkNaa3N3WGhKTXY2ciUyYjE4ZFRSYmcySXMxMldCJTJmZFptM2NKNCUz
ZD4gdGhlIGF1dGh6IGRpc2NvdmVyeSBzaG91bGQgZmFpbCBpbiBzb21lIHdheSAoZWcgcmV0dXJu
IG5vdGhpbmcpLg0KDQpUaGVyZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8gZG8gdGhpcy4gRWcgY29t
YmluZSBkaXNjb3ZlcnkuIE9yIGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlzY292ZXJ5Lg0KDQpPbmUg
b2YgT0F1dGgncyBzdHJlbmd0aCdzIGFuZCB3ZWFrbmVzc2VzIGlzIHRoYXQgdGhlIHRhcmdldCBv
ZiBhdXRob3JpemF0aW9uICh0aGUgcmVzb3VyY2UpIGlzIG5ldmVyIHNwZWNpZmllZC4gSXQgaXMg
b2Z0ZW4gYm91bmQgdXAgaW4gdGhlIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIGFuIG9mdGVuIGlt
cGxpZWQgMToxIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHJlc291cmNlIGFuZCBhcy4gR2l2ZW4gdGhh
dCBpbiBkaXNjb3ZlcnkgcGhhc2UgcmVnaXN0cmF0aW9uIGhhcyBub3QgeWV0IG9jY3VycmVkIGl0
IHNlZW1zIGltcG9ydGFudCB0aGF0IHRoZSBjbGllbnQga25vdyBpdCBoYXMgYSB2YWxpZCBjb21i
aW5hdGlvbiBvZiBlbmRwb2ludHMgZXRjLg0KDQpUaGlzIGlzIHdoeSBJIHdhcyBkaXNhcHBvaW50
ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0YXJ0aW5nIHBvaW50IGZvciBn
cm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVmaW5lZCB0aGUgZnVsbCByZXF1
aXJlbWVudHMgSU1PLg0KDQpJIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0IHNvbWUgdGhv
dWdodCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBhcG9sb2dpemUg
SSBjYW4ndCBkbyBpdCBub3cuDQoNClBoaWwNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAwODoxMiwg
TmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNv
bT4+IHdyb3RlOg0KSGkgUGhpbCwNCg0KQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhlIEFTIG1l
dGFkYXRhIHNob3VsZCBpbmNsdWRlIHRoZSBSUyBVUklzPyBDdXJyZW50bHksIGl0IGRvZXMgbm90
LCBidXQgaXQgY2FuIGJlIGRvbmUsIEkgZ3Vlc3MuDQoNClRoZSB3YXkgb2F1dGgtbWV0YSB3b3Jr
cyBpcyB0aGF0DQoNCjEuIFJTIHRlbGxzIHRoZSBjbGllbnQgd2hlcmUgdGhlIEFTIGlzLg0KMi4g
QVMgdGVsbHMgdGhlIGNsaWVudCB3aGljaCBSUyBlbmRwb2ludHMgdGhlIHRva2VuIGNhbiBiZSB1
c2VkLg0KDQpFdmVuIGlmIHRoZXJlIGlzIGEgYmFkIEFTIHdpdGggYSB2YWxpZCBjZXJ0cyB0aGF0
IHByb3hpZXMgdG8gdGhlIGdvb2QgUlMsIHRoZSBjbGllbnQgd2lsbCBub3Qgc2VuZCB0aGUgdG9r
ZW4gdGhlcmUgYXMgdGhlIGF1dGh6IHNlcnZlciB3aWxsIHNheSB0aGF0IGlzIG5vdCB0aGUgcGxh
Y2UgdGhlIGNsaWVudCBtYXkgd2FudCB0byBzZW5kIHRoZSB0b2tlbiB0by4NCg0KTmF0DQoNCjIw
MTblubQy5pyIMjTml6Uo5rC0KSAyMzo1OSBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t
PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KTmF0LA0KDQpJ4oCZbSBub3Qgc3VyZSB0
aGF0IGhhdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVyZSBpdHMg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIHNlcnZl
ciBuZWVkIHRvIGJlIGJvdW5kIHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5IGVuZHBv
aW50cyAodGhlIHJlc291cmNlIGFuZC9vciB0aGUgb2F1dGggc2VydmljZSBkaXNjb3ZlcnkpLg0K
DQpJZiBhIGNsaWVudCBkaXNjb3ZlcnMgYSBmYWtlIHJlc291cmNlIHNlcnZlciB0aGF0IGlzIHBy
b3h5aW5nIGZvciBhIHJlYWwgcmVzb3VyY2Ugc2VydmVyIHRoZSBjdXJyZW50IGRpc2NvdmVyeSBz
cGVjIHdpbGwgbm90IGxlYWQgdGhlIGNsaWVudCB0byB1bmRlcnN0YW5kIGl0IGhhcyB0aGUgd3Jv
bmcgcmVzb3VyY2Ugc2VydmVyLiBSYXRoZXIgdGhlIGZha2UgcmVzb3VyY2Ugc2VydmljZSB3aWxs
IGp1c3QgaGF2ZSBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBp
bnRlcmNlcHQgcmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkg
d2VyZSBhYmxlIHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3Jp
emF0aW9uIHNlcnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94
eS4NCg0KVGhlIE9BdXRoIERpc2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhl
IGNsaWVudCB0aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3Rh
dGVkIHJlc291cmNlIGVuZHBvaW50Lg0KDQpUaGlzIG5vdCBvbmx5IHdvcmtzIGluIG5vcm1hbCBP
QXV0aCBidXQgc2hvdWxkIGFkZCBzZWN1cml0eSBldmVuIHRvIFVNQSBzaXR1YXRpb25zLg0KDQpQ
aGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly9uYTAx
LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnd3dy5p
bmRlcGVuZGVudGlkLmNvbSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJnNkYXRhPU1KV3BGQjEydlRMQjRlY0t5WXdsWkxuUkpJbmFORXcxTXds
dnRVMjZCUEElM2Q+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb20+DQoNCg0KDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMzo1NCBBTSwgTmF0IFNha2ltdXJh
IDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0K
DQoNCkhpIFRob21hcywNCg0KaW5saW5lOg0KDQoyMDE25bm0MuaciDIy5pelKOaciCkgMTg6NDQg
VGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tPG1haWx0bzp0LmJyb3llckBnbWFpbC5j
b20+PjoNCkNvdWxkbid0IHRoZSBkb2N1bWVudCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT8N
CkkgcXVpdGUgbGlrZSB0aGUgaWRlYSBvZiBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIGlmIHlv
dSByZWFsbHkgd2FudCB0byBkbyBkaXNjb3ZlcnksIGFuZCBsZWF2ZSBpdCBvcGVuIHRvIGltcGxl
bWVudGVycyAvIHRvIG90aGVyIHNwZWNzIHRvIGRlZmluZSBhIC53ZWxsLWtub3duIFVSTCBmb3Ig
ImF1dG8tY29uZmlndXJhdGlvbiIuDQpUaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291bGQg
dGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMgZHJhZnQt
c2FraW11cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMgZm9y
IG90aGVyIG1ldGFkYXRhIHNwZWNzIChsaWtlIE9wZW5JRCBDb25uZWN0KS4NCldpdGggZHJhZnQt
c2FraW11cmEtb2F1dGgtbWV0YSdzICJkdXJpIiBhbmQgdGhlICJzY29wZSIgYXR0cmlidXRlIG9m
IFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlv
dSBuZWVkIHRvIHByb2NlZWQNCg0KWXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1aXJlbWVudHMg
dG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90Pw0KDQpJbiBPQXV0aCdzIGNhc2UsIHRoZSByZXNvdXJj
ZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0bHkgY291cGxl
ZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4pDQpTbywgdGhl
IHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIGVpdGhlciB0aGUgbG9jYXRp
b24gb2YgdGhlIGF1dGh6IGVuZHBvaW50LiBJbiBzb21lIHRydXN0ZWQgZW52aXJvbm1lbnQsIHRo
ZSByZXNvdXJjZSBtYXkgYXMgd2VsbCByZXR1cm4gdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBz
ZXJ2ZXIgY29uZmlndXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBoYXZl
IHRvIGRlY2lkZSBvbiB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZyZWVz
IHVwIGRldmVsb3BlcnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlzaW9u
cyBldGMuIFdlIHNob3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBhcyBt
dWNoIGFzIHBvc3NpYmxlLg0KDQood2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFyZSBzZXZlcmFsIEFT
cyBlYWNoIHdpdGggZGlmZmVyZW50IHNjb3Blczsgc291bmRzIGxpa2UgYW4gZWRnZS1jYXNlIHRv
IG1lIHRob3VnaDsgbWF5YmUgUkZDNjc1MCBzaG91bGQgaW5zdGVhZCBiZSB1cGRhdGVkIHdpdGgg
c3VjaCBhIHBhcmFtZXRlciBzdWNoIHRoYXQgYW4gUlMgY291bGQgcmV0dXJuIHNldmVyYWwgV1dX
LUF1dGhlbnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRzIG93biAic2NvcGUiIGFuZCAiZHVy
aSIgdmFsdWU/KQ0KDQpZZWFoLCBJIGd1ZXNzIGl0IGlzIGFuIGVkZ2UgY2FzZS4gSSB3b3VsZCBy
YXRoZXIgbGlrZSB0byBzZWUgdGhlc2UgYXV0aHogc2VydmVycyB0byBkZXZlbG9wIGEgdHJ1c3Qg
ZnJhbWV3b3JrIHVuZGVyIHdoaWNoIHRoZXkgY2FuIGFncmVlIG9uIGEgc2luZ2xlIHNldCBvZiBj
b21tb24gc2NvcGUgcGFyYW1ldGVyIHZhbHVlcy4NCg0KQ2hlZXJzLA0KDQpOYXQNCg0KDQpPbiBG
cmksIEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l
ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVGhlIG5ld2x5LXRyaW1tZWQgT0F1
dGggRGlzY292ZXJ5IGRvY3VtZW50IGlzIGhlbHBmdWwgYW5kIG1vdmluZyBpbiB0aGUgcmlnaHQg
ZGlyZWN0aW9uLiBJdCBkb2VzLCBob3dldmVyLCBzdGlsbCBoYXZlIHRvbyBtYW55IHZlc3RpZ2Vz
IG9mIGl0cyBPcGVuSUQgQ29ubmVjdCBvcmlnaW5zLiBPbmUgaXNzdWUgaW4gcGFydGljdWxhciBz
dGlsbCByZWFsbHkgYm90aGVycyBtZTogdGhlIHVzZSBvZiDigJwvLndlbGwta25vd24vb3Blbmlk
LWNvbmZpZ3VyYXRpb27igJ0gaW4gdGhlIGRpc2NvdmVyeSBwb3J0aW9uLiBJcyB0aGlzIGFuIE9B
dXRoIGRpc2NvdmVyeSBkb2N1bWVudCwgb3IgYW4gT3BlbklEIENvbm5lY3Qgb25lPyBUaGVyZSBp
cyBhYnNvbHV0ZWx5IG5vIGNvbXBlbGxpbmcgcmVhc29uIHRvIHRpZSB0aGUgVVJMIHRvIHRoZSBP
SURDIGRpc2NvdmVyeSBtZWNoYW5pc20uDQoNCkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndl
bGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlz
Y292ZXJ5IGxvY2F0aW9uLCBhbmQgc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUg
cmVhY2hhYmxlIGZyb20g4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlm
IHRoZSBzZXJ2ZXIgYWxzbyBwcm92aWRlcyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21h
aW4uIE90aGVyIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1l
cyB0byBkZXNjcmliZSBPQXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIg
c2VydmljZS1zcGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1lbnQuDQoNCiDigJQgSnVzdGluDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1nbzFGaEwlMmJEYTZ5QlNLbWNzM3dxbDcx
QnNrWTdON0VKeDQwcFpQSnh0bDQlM2Q+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgm
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBh
YWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZz
ZGF0YT1nbzFGaEwlMmJEYTZ5QlNLbWNzM3dxbDcxQnNrWTdON0VKeDQwcFpQSnh0bDQlM2Q+DQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp
bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlu
a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3Jn
JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1nbzFGaEwlMmJEYTZ5QlNLbWNzM3dx
bDcxQnNrWTdON0VKeDQwcFpQSnh0bDQlM2Q+DQoNCg==

--_000_BN3PR0301MB1234658E888AC37750E18D4EA6A50BN3PR0301MB1234_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
Z3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4gVGhlIHBvaW50IG9mIHRo
ZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5j
dGlvbmFsaXR5DQogdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MDIwNjAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGF0IG1heSBiZSB3aWRlbHkgZGVwbG95ZWQgZm9y
IE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQgZm9yIE9BdXRoLiBUaGVyZSBhcmUgc29tZSBh
dXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292ZXJ5IGZvciBlbmRwb2ludCB0aGF0IHJlYWxs
eSBzaG91bGQgbm90DQogYmUgaW4gYW4gT0F1dGggc3RhbmRhcmQgc2luY2UgaXTigJlzIHJlYWxs
eSBub3QgZGVhbHQgd2l0aC4gTm93IHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRpb24gaXMgYXZhaWxh
YmxlIGl0IG1ha2VzIHBva2luZyBhcm91bmQgdGhlIGVuZHBvaW50IG1vcmUgZm9jdXNlZCBmb3Ig
cGVvcGxlIHRoYXQgd2FudCB0byBkaXNydXB0IHlvdXIgZW5kcG9pbnRzLCB0aGF0IGlzIHJlYWxs
eSBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KIHNlY3Rpb24g
YXQgYWxsIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3Nw
YW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g
T0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5NaWtlIEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIw
MTYgOTo1NCBBTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50IChJRE0pICZsdDtwaGlsLmh1bnRA
b3JhY2xlLmNvbSZndDs7IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxi
cj4NCjxiPkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5vcmcm
Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3Zl
cnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlz
IHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5
IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm9uZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0
aW5nIHRoYXQgYWRkaXRpb25hbCByZWxhdGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVh
dGVkLiZuYnNwOyBJ4oCZbSBzdXJlIGl0IHdpbGwgYmUuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25z
IHdpbGwgdXNlIFdlYkZpbmdlciB0bw0KIGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiZu
YnNwOyBTb21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4mbmJzcDsgU29tZSB3aWxs
IHBvc3NpYmx5IHVzZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyAud2VsbC1rbm93biB2YWx1ZXMuJm5i
c3A7IEnigJltIHN1cmUgdGhlcmXigJlzIG90aGVyIHRoaW5ncyBJIGhhdmVu4oCZdCBldmVuIHRo
b3VnaHQgYWJvdXQuJm5ic3A7IEFsbCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNj
b3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQNCiBmb3JtYXQgYW5kIG5vbmUgb2YgdGhlbSBjaGFuZ2Ug
aXQg4oCTIG90aGVyIHRoYW4gcG9zc2libHkgdG8gcmVnaXN0ZXIgYWRkaXRpb25hbCBkaXNjb3Zl
cnkgbWV0YWRhdGEgdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MjA2MCI+U28gYnkgYWxsIG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUg
ZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0
IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250ZXh0cy4mbmJzcDsgQXQgdGhlIHNhbWUgdGltZSwgd2UN
CiBjYW4gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNv
cmUgZnVuY3Rpb25hbGl0eSB0aGF0IGFsbCBvZiB0aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50IChJRE0pPGJyPg0KPGI+U2VudDo8
L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgODozOSBBTTxicj4NCjxiPlRvOjwvYj4g
TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtp
bXVyYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0
bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBzdWdn
ZXN0aW5nIHRoYXQgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUg
Y2xpZW50IGluZGljYXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1
dGggY29uZmlndXJhdGlvbiBkYXRhIGZvci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaWYgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnJlcy5leGFtcGxlLmV2
aWwuY29tJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMy
YTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx
MWRiNDclN2MxJmFtcDtzZGF0YT1QYyUyYjdpbG5EWWdmallvVHNRV29abnBvYkclMmJWSnA1V3U5
Y0dwRlVnejNTMCUzZCI+DQpyZXMuZXhhbXBsZS5ldmlsLmNvbTwvYT4gaXMgbm90IGEgdmFsaWQg
cmVzb3VyY2UgZW5kcG9pbnQgZm9yIDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcy5leGFtcGxlLmNvbSZhbXA7
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBh
YWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh
bXA7c2RhdGE9NiUyYnF4aCUyZjdWQ1prc3dYaEpNdjZyJTJiMThkVFJiZzJJczEyV0IlMmZkWm0z
Y0o0JTNkIj4NCmFzLmV4YW1wbGUuY29tPC9hPiB0aGUgYXV0aHogZGlzY292ZXJ5IHNob3VsZCBm
YWlsIGluIHNvbWUgd2F5IChlZyByZXR1cm4gbm90aGluZykuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2ln
bmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIG1heSBiZSBiZXR0ZXIgd2F5cyB0
byBkbyB0aGlzLiBFZyBjb21iaW5lIGRpc2NvdmVyeS4gT3IgY2hhbmdlIHRoZSBvcmRlciBvZiBk
aXNjb3ZlcnkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFp
bFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uZSBvZiBPQXV0aCdzIHN0cmVuZ3RoJ3MgYW5kIHdlYWtuZXNzZXMgaXMgdGhhdCB0aGUg
dGFyZ2V0IG9mIGF1dGhvcml6YXRpb24gKHRoZSByZXNvdXJjZSkgaXMgbmV2ZXIgc3BlY2lmaWVk
LiBJdCBpcyBvZnRlbiBib3VuZCB1cCBpbiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgYW4g
b2Z0ZW4gaW1wbGllZCAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gcmVzb3VyY2UgYW5kIGFzLiBH
aXZlbiB0aGF0IGluDQogZGlzY292ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBv
Y2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEg
dmFsaWQgY29tYmluYXRpb24gb2YgZW5kcG9pbnRzIGV0Yy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu
YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2lu
dGVkIGFib3V0IHdnbGMgb24gZGlzY292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3Ig
Z3JvdXAgYWRvcHRpb24gYnV0IHdlIGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVx
dWlyZW1lbnRzIElNTy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBw
bGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SSBhbSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50
byBzb21lIGRyYWZ0IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3Qg
ZG8gaXQgbm93LiZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PGJyPg0KT24gRmViIDI0LCAyMDE2LCBhdCAwODoxMiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVm
PSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkhpIFBoaWwsJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5BcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hv
dWxkIGluY2x1ZGUgdGhlIFJTIFVSSXM/IEN1cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBj
YW4gYmUgZG9uZSwgSSBndWVzcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdheSBvYXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQm
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+MS4gUlMgdGVsbHMgdGhlIGNsaWVudCB3aGVyZSB0aGUgQVMgaXMuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBBUyB0ZWxscyB0
aGUgY2xpZW50IHdoaWNoIFJTIGVuZHBvaW50cyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2
ZW4gaWYgdGhlcmUgaXMgYSBiYWQgQVMgd2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0
byB0aGUgZ29vZCBSUywgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBh
cyB0aGUgYXV0aHogc2VydmVyIHdpbGwgc2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xp
ZW50IG1heSB3YW50IHRvIHNlbmQgdGhlIHRva2VuIHRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk5hdDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTY8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7lubQ8L3NwYW4+MjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpTaW1TdW4iPuaciDwvc3Bhbj4yNDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1T
dW4iPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5rC0PC9zcGFu
PikgMjM6NTkgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j
b20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQsPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJl
c291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2Vy
dmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0
aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3Vu
ZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeQ0KIGVuZHBvaW50cyAodGhlIHJlc291
cmNlIGFuZC9vciB0aGUgb2F1dGggc2VydmljZSBkaXNjb3ZlcnkpLjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGEgY2xpZW50IGRpc2NvdmVy
cyBhIGZha2UgcmVzb3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9yIGEgcmVhbCByZXNv
dXJjZSBzZXJ2ZXIgdGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBub3QgbGVhZCB0aGUg
Y2xpZW50IHRvIHVuZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJjZSBzZXJ2ZXIuIFJh
dGhlciB0aGUgZmFrZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZlDQogYSBmYWtlIGRp
c2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291cmNlIHBh
eWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBjb252aW5j
ZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIGJ1dCB1
c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPQXV0aCBEaXNjb3Zlcnkg
c2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlz
IGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBlbmRwb2ludC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBu
b3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZl
biB0byBVTUEgc2l0dWF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRp
ZC5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJh
NzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmYW1wO3NkYXRhPU1KV3BGQjEydlRMQjRlY0t5WXdsWkxuUkpJbmFORXcxTXdsdnRV
MjZCUEElM2QiIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29t
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0s
IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy
Pg0KSGkgVGhvbWFzLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5pbmxpbmU6Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj4yMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7lubQ8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pyIPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjIyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+KDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pyIPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPikNCiAxODo0NCBUaG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86
dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9h
PiZndDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5Db3VsZG4ndCB0aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0
aGUgbWV0YWRhdGE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgcXVpdGUgbGlrZSB0aGUgaWRlYSBvZiZuYnNwO2Ry
YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRpc2NvdmVy
eSwgYW5kIGxlYXZlIGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3BlY3MgdG8g
ZGVmaW5lIGEgLndlbGwta25vd24gVVJMIGZvciAmcXVvdDthdXRvLWNvbmZpZ3VyYXRpb24mcXVv
dDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxk
IHRoZW4gZWl0aGVyIGJlIHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzJm5ic3A7
ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFz
aXMgZm9yIG90aGVyIG1ldGFkYXRhIHNwZWNzIChsaWtlDQogT3BlbklEIENvbm5lY3QpLiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGgm
bmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJ3MgJnF1b3Q7ZHVyaSZxdW90OyBhbmQgdGhl
ICZxdW90O3Njb3BlJnF1b3Q7IGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNl
IGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9jZWVkJm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRv
IGJlIFJFU1RmdWwsIGlzIGl0IG5vdD8gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhl
cndpc2UsIHlvdSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKSZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPlNvLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIHRlbGwg
ZWl0aGVyIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogZW5kcG9pbnQuIEluIHNvbWUgdHJ1c3Rl
ZCBlbnZpcm9ubWVudCwgdGhlIHJlc291cmNlIG1heSBhcyB3ZWxsIHJldHVybiB0aGUgbG9jYXRp
b24gb2YgdGhlDQogYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2UgY2Fz
ZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkgYXMg
eW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBmaWxl
IGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRl
IHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KHdlbGwsIGV4Y2VwdCBpZiB0
aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBs
aWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3Rl
YWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3VjaA0KIHRoYXQgYW4gUlMgY291
bGQgcmV0dXJuIHNldmVyYWwgV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRz
IG93biAmcXVvdDtzY29wZSZxdW90OyBhbmQgJnF1b3Q7ZHVyaSZxdW90OyB2YWx1ZT8pPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPlllYWgsIEkgZ3Vlc3MgaXQgaXMgYW4gZWRnZSBjYXNlLiBJIHdvdWxk
IHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2ZXJzIHRvIGRldmVsb3AgYSB0cnVz
dCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdyZWUgb24gYSBzaW5nbGUgc2V0IG9m
IGNvbW1vbiBzY29wZSBwYXJhbWV0ZXINCiB2YWx1ZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJzLCZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5hdDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y
aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gRnJpLCBGZWIgMTksIDIwMTYgYXQg
MTA6NTkgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVk
dSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U
aGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBhbmQg
bW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxsIGhh
dmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9uZQ0K
IGlzc3VlIGluIHBhcnRpY3VsYXIgc3RpbGwgcmVhbGx5IGJvdGhlcnMgbWU6IHRoZSB1c2Ugb2Yg
4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGluIHRoZSBkaXNjb3Zlcnkg
cG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0aCBkaXNjb3ZlcnkgZG9jdW1lbnQsIG9yIGFuIE9wZW5J
RCBDb25uZWN0IG9uZT8gVGhlcmUgaXMgYWJzb2x1dGVseSBubyBjb21wZWxsaW5nIHJlYXNvbiB0
byB0aWUgdGhlIFVSTCB0byB0aGUgT0lEQyBkaXNjb3ZlcnkNCiBtZWNoYW5pc20uPGJyPg0KPGJy
Pg0KSSBwcm9wb3NlIHRoYXQgd2UgdXNlIOKAnC8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0
aW9uLXNlcnZlcuKAnSBhcyB0aGUgZGVmYXVsdCBkaXNjb3ZlcnkgbG9jYXRpb24sIGFuZCBzdGF0
ZSB0aGF0IHRoZSBkb2N1bWVudCBNQVkgYWxzbyBiZSByZWFjaGFibGUgZnJvbSDigJwvLndlbGwt
a25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0gaWYgdGhlIHNlcnZlciBhbHNvIHByb3ZpZGVz
IE9wZW5JRCBDb25uZWN0IG9uIHRoZSBzYW1lIGRvbWFpbi4gT3RoZXINCiBhcHBsaWNhdGlvbnMg
U0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5k
cG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292
ZXJ5IGRvY3VtZW50Ljxicj4NCjxicj4NCiZuYnNwO+KAlCBKdXN0aW48YnI+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg
bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0tt
Y3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v
dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxp
c3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29t
JTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZ
N043RUp4NDBwWlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T0F1dGhA
aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVm
PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
cyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtk
YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFh
YWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFt
cDtzZGF0YT1nbzFGaEwlMmJEYTZ5QlNLbWNzM3dxbDcxQnNrWTdON0VKeDQwcFpQSnh0bDQlM2Qi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_BN3PR0301MB1234658E888AC37750E18D4EA6A50BN3PR0301MB1234_--


From nobody Wed Feb 24 10:22:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A151B3B76 for ; Wed, 24 Feb 2016 10:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 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_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 FzgkR_1pbYze for ; Wed, 24 Feb 2016 10:22:36 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B581B3B6E for ; Wed, 24 Feb 2016 10:22:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UbEAj4odOZGgALAbOUK2944bem+g1zhsdiIMarhSsRo=; b=bpi6g4xu4j2Syy97rnS5GzPtf/wEZjR3jda4wWZFxcxFxh/DWDEhwI1wKQeReYLQWVHglyzjcvBFov6nFJ6fznXcAAVloMWbncgBPDiwXOXtneVEoIRtx0W5+mVtxyZErdfVUOxURnbYWCeGOC2P1jNDesvfYeYW8+Vk+KNeCwQ=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 18:22:06 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 18:22:04 +0000
From: Mike Jones 
To: Anthony Nadalin 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmA=
Date: Wed, 24 Feb 2016 18:22:04 +0000
Message-ID: 
References:        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: 6731c917-2462-40a1-df93-08d33d47656c
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:7bU1KeQF/e16hwapPZOlBELsggQ09+cPdA/Vk6/WIrtSjMN7aE/aWwJB6FDy+d2mZtcbx9x4JHAWiKOzbEXZMu26BeVV2gXghH5yf3xaeVx52Wi1Y7rN6P4XhgcJ6AQezB0hq5ftkyYtfBR0y7nACA==; 24:fEMyRb3YYBU7i6mtZD/XUGKGA6+nFDUp0rghtXVzG4l58X14q0KU1UXtna7dpyWHR5DpxLb78NBkYnaMCp9u4pKwcSXmDzTG5KbvTXHc73U=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19580405001)(1511001)(586003)(19580395003)(93886004)(74316001)(3660700001)(3280700002)(3846002)(5003600100002)(19625215002)(33656002)(66066001)(1220700001)(15975445007)(4326007)(2900100001)(77096005)(2950100001)(2561002)(450100001)(2906002)(3900700001)(10290500002)(5008740100001)(5005710100001)(790700001)(1096002)(6116002)(5004730100002)(102836003)(10400500002)(122556002)(8990500004)(40100003)(76576001)(19300405004)(76176999)(92566002)(99286002)(87936001)(106116001)(19617315012)(5001960100002)(110136002)(189998001)(10090500001)(4001450100002)(50986999)(54356999)(5002640100001)(86362001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44295F4948FB3ABEAFBA3D8F5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 18:22:04.0478 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:22:40 -0000

--_000_BY2PR03MB44295F4948FB3ABEAFBA3D8F5A50BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgd2XigJlkIGRpc2N1c3NlZCBpbiBwZXJzb24sIHRoZXJl4oCZcyBubyBlZmZlY3RpdmUgc2Vj
dXJpdHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBiZWluZyBwdWJs
aXNoZWQgaW4gYW4gYWQtaG9jIGZhc2hpb24gb24gZGV2ZWxvcGVyIHBhZ2VzIGFuZCBpdCBiZWlu
ZyBwdWJsaXNoZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQuICDigJxTZWN1cml0eSBieSBvYnNjdXJp
dHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC4NCg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog
QW50aG9ueSBOYWRhbGluDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAx
IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgUGhpbCBI
dW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFA
Z21haWwuY29tPg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVj
dDogUkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQo+IFRoZSBw
b2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBkaXNj
b3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC4NCg0K
VGhhdCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxv
eWVkIGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRp
c2NvdmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBPQXV0
aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBh
bGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0
aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1cHQg
eW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNlY3Vy
aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYXQgYWxsDQoNCkZyb206IE9BdXRoIFttYWlsdG86
b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTQ0KVG86IFBoaWwgSHVudCAoSURNKSA8
cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IE5hdCBT
YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0K
Q2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRo
IDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KVGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZp
bmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTi
gJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLg0KDQpOb25lIG9mIE5hdCBvciBKb2huIG9yIEkg
YXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27i
gJl0IGJlIGNyZWF0ZWQuICBJ4oCZbSBzdXJlIGl0IHdpbGwgYmUuICBTb21lIGFwcGxpY2F0aW9u
cyB3aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuICBT
b21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4gIFNvbWUgd2lsbCBwb3NzaWJseSB1
c2UgYXBwbGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24gdmFsdWVzLiAgSeKAmW0gc3VyZSB0
aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4gIEFs
bCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1l
bnQgZm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBvc3Np
Ymx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy4NCg0K
U28gYnkgYWxsIG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vz
c2luZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ug
c2Vuc2UgaW4gc29tZSBjb250ZXh0cy4gIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGNhbiBmaW5pc2gg
c3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFs
aXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2lsbCBuZWVkLg0KDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K
DQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBQaGlsIEh1bnQgKElETSkNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgODoz
OSBBTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb
T0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KSSBhbSBzdWdnZXN0aW5n
IHRoYXQgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50
IGluZGljYXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29u
ZmlndXJhdGlvbiBkYXRhIGZvci4NCg0KU28gaWYgcmVzLmV4YW1wbGUuZXZpbC5jb208aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy
ZnJlcy5leGFtcGxlLmV2aWwuY29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9UGMlMmI3aWxuRFlnZmpZb1RzUVdvWm5wb2JHJTJi
VkpwNVd1OWNHcEZVZ3ozUzAlM2Q+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50IGZv
ciBhcy5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXMuZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdjdG9u
eW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3
YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT02JTJicXhoJTJmN1ZD
Wmtzd1hoSk12NnIlMmIxOGRUUmJnMklzMTJXQiUyZmRabTNjSjQlM2Q+IHRoZSBhdXRoeiBkaXNj
b3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4NCg0KVGhl
cmUgbWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBP
ciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4NCg0KT25lIG9mIE9BdXRoJ3Mgc3RyZW5n
dGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAo
dGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGlu
IHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlv
bnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5IHBo
YXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQg
dGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5kcG9p
bnRzIGV0Yy4NCg0KVGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdnbGMgb24g
ZGlzY292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRpb24gYnV0
IHdlIGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElNTy4NCg0K
SSBhbSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21lIGRy
YWZ0IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQgbm93
Lg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6MTIsIE5hdCBTYWtpbXVyYSA8c2Fr
aW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFBo
aWwsDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5j
bHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBk
b25lLCBJIGd1ZXNzLg0KDQpUaGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdA0KDQoxLiBS
UyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4NCjIuIEFTIHRlbGxzIHRoZSBjbGll
bnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4NCg0KRXZlbiBpZiB0
aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRvIHRoZSBn
b29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFzIHRoZSBh
dXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5
IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uDQoNCk5hdA0KDQoyMDE25bm0MuaciDI05pelKOaw
tCkgMjM6NTkgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50
QG9yYWNsZS5jb20+PjoNCk5hdCwNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJl
c291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2Vy
dmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0
aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3Vu
ZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNvdXJj
ZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KSWYgYSBjbGllbnQgZGlz
Y292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWluZyBmb3IgYSByZWFs
IHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3aWxsIG5vdCBsZWFk
IHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJlc291cmNlIHNlcnZl
ci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0IGhhdmUgYSBmYWtl
IGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291cmNl
IHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBjb252
aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIGJ1
dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuDQoNClRoZSBPQXV0aCBE
aXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0aGUg
c2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBlbmRw
b2ludC4NCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3VsZCBh
ZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KUGhpbA0KDQpAaW5kZXBlbmRl
bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj
dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5jb20m
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBh
YWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZz
ZGF0YT1NSldwRkIxMnZUTEI0ZWNLeVl3bFpMblJKSW5hTkV3MU13bHZ0VTI2QlBBJTNkPg0KcGhp
bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpP
biBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwu
Y29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpIaSBUaG9tYXMsDQoN
CmlubGluZToNCg0KMjAxNuW5tDLmnIgyMuaXpSjmnIgpIDE4OjQ0IFRob21hcyBCcm95ZXIgPHQu
YnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQpDb3VsZG4ndCB0
aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0aGUgbWV0YWRhdGE/DQpJIHF1aXRlIGxpa2UgdGhl
IGlkZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8g
ZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0byBvdGhl
ciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICJhdXRvLWNvbmZpZ3VyYXRp
b24iLg0KVGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJlIHVz
ZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1l
dGEgbWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBtZXRhZGF0YSBz
cGVjcyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuDQpXaXRoIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1l
dGEncyAiZHVyaSIgYW5kIHRoZSAic2NvcGUiIGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGljYXRl
IHJlc3BvbnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9jZWVk
DQoNCll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWwsIGlz
IGl0IG5vdD8NCg0KSW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlv
dSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKQ0KU28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIg
c2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBl
bmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFz
IHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRp
b24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hh
dCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZy
b20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQg
c3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4N
Cg0KKHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZl
cmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJl
IFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIg
c3VjaCB0aGF0IGFuIFJTIGNvdWxkIHJldHVybiBzZXZlcmFsIFdXVy1BdXRoZW50aWNhdGU6IEJl
YXJlciwgZWFjaCB3aXRoIGl0cyBvd24gInNjb3BlIiBhbmQgImR1cmkiIHZhbHVlPykNCg0KWWVh
aCwgSSBndWVzcyBpdCBpcyBhbiBlZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2Vl
IHRoZXNlIGF1dGh6IHNlcnZlcnMgdG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3
aGljaCB0aGV5IGNhbiBhZ3JlZSBvbiBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFt
ZXRlciB2YWx1ZXMuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0KT24gRnJpLCBGZWIgMTksIDIwMTYg
YXQgMTA6NTkgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVy
QG1pdC5lZHU+PiB3cm90ZToNClRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1
bWVudCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9l
cywgaG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENv
bm5lY3Qgb3JpZ2lucy4gT25lIGlzc3VlIGluIHBhcnRpY3VsYXIgc3RpbGwgcmVhbGx5IGJvdGhl
cnMgbWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCd
IGluIHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0aCBkaXNjb3ZlcnkgZG9j
dW1lbnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhlcmUgaXMgYWJzb2x1dGVseSBubyBj
b21wZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0aGUgT0lEQyBkaXNjb3ZlcnkgbWVj
aGFuaXNtLg0KDQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1
dGhvcml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwg
YW5kIHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKA
nC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28g
cHJvdmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlciBhcHBsaWNh
dGlvbnMgU0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1
dGggZW5kcG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMg
ZGlzY292ZXJ5IGRvY3VtZW50Lg0KDQog4oCUIEp1c3Rpbg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5m
byUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJh
NzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4
dGw0JTNkPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25h
MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3
dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjkl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2
eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0
aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZh
MzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk
MDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBa
UEp4dGw0JTNkPg0KDQo=

--_000_BY2PR03MB44295F4948FB3ABEAFBA3D8F5A50BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFzIHdl4oCZZCBkaXNj
dXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZmZWN0aXZlIHNlY3VyaXR5IGRpZmZlcmVu
Y2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gYmVpbmcgcHVibGlzaGVkIGluIGFuIGFk
LWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBhbmQNCiBpdCBiZWluZyBwdWJsaXNoZWQg
aW4gYSBzdGFuZGFyZCBmb3JtYXQuJm5ic3A7IOKAnFNlY3VyaXR5IGJ5IG9ic2N1cml0eeKAnSBh
ZGRzIG5vIHJlYWwgc2VjdXJpdHkgYXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbnRob255IE5hZGFsaW4NCjxicj4N
CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFNPGJyPg0K
PGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7
OyBQaGlsIEh1bnQgKElETSkgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OzsgTmF0IFNha2lt
dXJhICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7b2F1dGhA
aWV0Zi5vcmcmZ3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4gVGhlIHBv
aW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2Nv
dmVyeSBmdW5jdGlvbmFsaXR5DQogdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGF0IG1heSBiZSB3aWRl
bHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQgZm9yIE9BdXRoLiBU
aGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292ZXJ5IGZvciBlbmRw
b2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90DQogYmUgaW4gYW4gT0F1dGggc3RhbmRhcmQgc2lu
Y2UgaXTigJlzIHJlYWxseSBub3QgZGVhbHQgd2l0aC4gTm93IHRoYXQgYWxsIHRoaXMgaW5mb3Jt
YXRpb24gaXMgYXZhaWxhYmxlIGl0IG1ha2VzIHBva2luZyBhcm91bmQgdGhlIGVuZHBvaW50IG1v
cmUgZm9jdXNlZCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0byBkaXNydXB0IHlvdXIgZW5kcG9pbnRz
LCB0aGF0IGlzIHJlYWxseSBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0
aW9ucw0KIHNlY3Rpb24gYXQgYWxsIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEg
aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNl
bnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDk6NTQgQU08YnI+DQo8Yj5Ubzo8
L2I+IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu
Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OyBOYXQgU2FraW11cmEgJmx0OzxhIGhy
ZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7
PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0
aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h
dXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgcG9p
bnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292
ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5Ob25lIG9mIE5hdCBvciBKb2hu
IG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0
eSB3b27igJl0IGJlIGNyZWF0ZWQuJm5ic3A7IEnigJltIHN1cmUgaXQgd2lsbCBiZS4mbmJzcDsg
U29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgV2ViRmluZ2VyIHRvDQogbG9jYXRlIHRoZSBkaXNj
b3ZlcnkgbWV0YWRhdGEuJm5ic3A7IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJz
LiZuYnNwOyBTb21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNwZWNpZmljIC53ZWxs
LWtub3duIHZhbHVlcy4mbmJzcDsgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkg
aGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4mbmJzcDsgQWxsIG9mIHRoZXNlIGRlcGVuZCB1
cG9uIGhhdmluZyBhIGRpc2NvdmVyeSBtZXRhZGF0YSBkb2N1bWVudA0KIGZvcm1hdCBhbmQgbm9u
ZSBvZiB0aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdpc3RlciBh
ZGRpdGlvbmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5TbyBieSBhbGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3Vw
IHNob3VsZCBjb250aW51ZSBkaXNjdXNzaW5nIGludmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRl
ZCBtZWNoYW5pc21zIHRoYXQgbWFrZSBzZW5zZSBpbiBzb21lIGNvbnRleHRzLiZuYnNwOyBBdCB0
aGUgc2FtZSB0aW1lLCB3ZQ0KIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3
aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hh
bmlzbXMgd2lsbCBuZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9B
dXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQgKElE
TSk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFN
PGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZn
dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVy
eSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRp
b24gaGFzIHRvIGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50
IGl0IHdhbnRzIHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEgZm9yLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl
TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiA8YSBocmVmPSJodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm
JTJmcmVzLmV4YW1wbGUuZXZpbC5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVBjJTJiN2lsbkRZZ2ZqWW9Uc1FX
b1pucG9iRyUyYlZKcDVXdTljR3BGVWd6M1MwJTNkIj4NCnJlcy5leGFtcGxlLmV2aWwuY29tPC9h
PiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgPGEgaHJlZj0iaHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFz
LmV4YW1wbGUuY29tJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT02JTJicXhoJTJmN1ZDWmtzd1hoSk12NnIlMmIxOGRU
UmJnMklzMTJXQiUyZmRabTNjSjQlM2QiPg0KYXMuZXhhbXBsZS5jb208L2E+IHRoZSBhdXRoeiBk
aXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgbWF5
IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBPciBjaGFu
Z2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25l
c3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBp
cyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVn
aXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiBy
ZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4NCiBkaXNjb3ZlcnkgcGhhc2UgcmVnaXN0cmF0
aW9uIGhhcyBub3QgeWV0IG9jY3VycmVkIGl0IHNlZW1zIGltcG9ydGFudCB0aGF0IHRoZSBjbGll
bnQga25vdyBpdCBoYXMgYSB2YWxpZCBjb21iaW5hdGlvbiBvZiBlbmRwb2ludHMgZXRjLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdo
eSBJIHdhcyBkaXNhcHBvaW50ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0
YXJ0aW5nIHBvaW50IGZvciBncm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVm
aW5lZCB0aGUgZnVsbCByZXF1aXJlbWVudHMgSU1PLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVy
ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0
IHNvbWUgdGhvdWdodCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBh
cG9sb2dpemUgSSBjYW4ndCBkbyBpdCBub3cuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2Fr
aW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdt
YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRo
ZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBk
b2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd2F5IG9hdXRoLW1l
dGEgd29ya3MgaXMgdGhhdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBp
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBj
YW4gYmUgdXNlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2Vy
dHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQg
dGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3Qg
dGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KTmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+MjAxNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuW5tDwvc3Bhbj4y
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5pyIPC9zcGFuPjI0PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj7msLQ8L3NwYW4+KSAyMzo1OSBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCw8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB0
aGF0IGhhdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVyZSBpdHMg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIHNlcnZl
ciBuZWVkIHRvIGJlIGJvdW5kIHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5DQogZW5k
cG9pbnRzICh0aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2aWNlIGRpc2NvdmVyeSku
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg
YSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWlu
ZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3
aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJl
c291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0
IGhhdmUNCiBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRl
cmNlcHQgcmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2Vy
ZSBhYmxlIHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0
aW9uIHNlcnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl
IE9BdXRoIERpc2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0
aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291
cmNlIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGlzIG5vdCBvbmx5IHdvcmtzIGluIG5vcm1hbCBPQXV0aCBidXQgc2hvdWxk
IGFkZCBzZWN1cml0eSBldmVuIHRvIFVNQSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5A
aW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy
Znd3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9TUpXcEZCMTJ2VExCNGVjS3lZd2xa
TG5SSkluYU5FdzFNd2x2dFUyNkJQQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVu
dGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp
bC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAyNCwg
MjAxNiwgYXQgMzo1NCBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11
cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48YnI+DQpIaSBUaG9tYXMsJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPmlubGluZTombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW5
tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
nIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYi
PuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4oPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlm
Ij7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0KIDE4OjQ0IFRob21hcyBCcm95ZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJy
b3llckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNvdWxkbid0IHRoZSBkb2N1bWVu
dCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBxdWl0ZSBsaWtlIHRo
ZSBpZGVhIG9mJm5ic3A7ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdh
bnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0
byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICZxdW90O2F1dG8t
Y29uZmlndXJhdGlvbiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbWV0YWRhdGEgZGVz
Y3JpYmVkIGhlcmUgd291bGQgdGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwg
cmV0dXJuZWQgYXMmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRo
ZSBSUzsgb3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UNCiBPcGVu
SUQgQ29ubmVjdCkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+V2l0aCZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAmcXVvdDtk
dXJpJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsgYXR0cmlidXRlIG9mIFdXVy1BdXRo
ZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBuZWVkIHRv
IHByb2NlZWQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WXVwLiBUaGF0J3Mgb25lIG9mIHRo
ZSByZXF1aXJlbWVudHMgdG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90PyAmbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiBPQXV0aCdzIGNhc2UsIHRo
ZSByZXNvdXJjZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0
bHkgY291cGxlZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4p
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxk
IGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2lu
dC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwg
cmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUNCiBhdXRoeiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBk
YXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBoYXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53
ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZyZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBj
b25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlzaW9ucyBldGMuIFdlIHNob3VsZCBzdHJp
dmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBhcyBtdWNoIGFzIHBvc3NpYmxlLiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4o
d2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFyZSBzZXZlcmFsIEFTcyBlYWNoIHdpdGggZGlmZmVyZW50
IHNjb3Blczsgc291bmRzIGxpa2UgYW4gZWRnZS1jYXNlIHRvIG1lIHRob3VnaDsgbWF5YmUgUkZD
Njc1MCBzaG91bGQgaW5zdGVhZCBiZSB1cGRhdGVkIHdpdGggc3VjaCBhIHBhcmFtZXRlciBzdWNo
DQogdGhhdCBhbiBSUyBjb3VsZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFy
ZXIsIGVhY2ggd2l0aCBpdHMgb3duICZxdW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtkdXJpJnF1
b3Q7IHZhbHVlPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBl
ZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMg
dG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBv
biBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlcg0KIHZhbHVlcy4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsJm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TmF0PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmks
IEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls
dG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPlRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVu
dCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywg
aG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5l
Y3Qgb3JpZ2lucy4gT25lDQogaXNzdWUgaW4gcGFydGljdWxhciBzdGlsbCByZWFsbHkgYm90aGVy
cyBtZTogdGhlIHVzZSBvZiDigJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0g
aW4gdGhlIGRpc2NvdmVyeSBwb3J0aW9uLiBJcyB0aGlzIGFuIE9BdXRoIGRpc2NvdmVyeSBkb2N1
bWVudCwgb3IgYW4gT3BlbklEIENvbm5lY3Qgb25lPyBUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIGNv
bXBlbGxpbmcgcmVhc29uIHRvIHRpZSB0aGUgVVJMIHRvIHRoZSBPSURDIGRpc2NvdmVyeQ0KIG1l
Y2hhbmlzbS48YnI+DQo8YnI+DQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3du
L29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBs
b2NhdGlvbiwgYW5kIHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJs
ZSBmcm9tIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2Vy
dmVyIGFsc28gcHJvdmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhl
cg0KIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBk
ZXNjcmliZSBPQXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2Vydmlj
ZS1zcGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A74oCUIEp1c3Rp
bjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl
MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3
YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMz
ZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9
Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v
cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2
eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh
bj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy
Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp
bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
ZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043
RUp4NDBwWlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BY2PR03MB44295F4948FB3ABEAFBA3D8F5A50BY2PR03MB442namprd_--


From nobody Wed Feb 24 10:25:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1681B3B55 for ; Wed, 24 Feb 2016 10:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 seIPc6vYv-yj for ; Wed, 24 Feb 2016 10:25:48 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1281B3B7A for ; Wed, 24 Feb 2016 10:25:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JJcbzlGn+MxiVIydh/1SSQ+H2BQMK5aM/JU/UCs0WYU=; b=h7BIRxpXXuS8dYaOLn/5jQDUrQK37C/Ooum82bFl+ryUc+PtfSB+6ff5dhtU2XkE0zVb6GTudVGtKlyN4Ta5qRbRqhsOhQWs2IYcAM69vr8enNok2kecQsXhhUcPIaSz97a5HL9W1bjCW/s6uydM+Ldk6li7Qd3gfgEvtri2HKM=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 18:25:45 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 18:25:43 +0000
From: Anthony Nadalin 
To: Mike Jones 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaUuxGHT78V06lUef7azsq7p831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABTAgIAAAIAggAAHegCAAAAtMA==
Date: Wed, 24 Feb 2016 18:25:42 +0000
Message-ID: 
References:         
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:9::48a]
x-ms-office365-filtering-correlation-id: 62e74969-66f4-4f96-aa89-08d33d47e7c9
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:RLUF+vMo+ZpeYgwQgYSa4oFCFxoKwcoBfcmSPWVdceiKFkfiXaYM8kjtakyGVBoTy1M+KLyQ8LWfBgauLifHbnGa0mOlbHVEpa5915qj2C7nZ9++kAxETVlqYJMculkH4CH048GRRCrEqoJsxWL+JQ==; 24:iBjmdQ5MS8LICV7ZD3KP4LUoAIJduMxjBjlM+jAFbj6jocuSXB52z5twVNAb+KF53vmJfa1Xc+rUpOSMUsZ3iD0IR62XPXfdZVmjjHFlI1o=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(102836003)(50986999)(87936001)(54356999)(19300405004)(76176999)(106116001)(110136002)(5001960100002)(1220700001)(93886004)(189998001)(5002640100001)(76576001)(1096002)(4326007)(5008740100001)(2906002)(586003)(5004730100002)(5003600100002)(99286002)(74316001)(790700001)(1511001)(2561002)(3660700001)(6116002)(3280700002)(3900700001)(92566002)(19617315012)(16236675004)(10400500002)(122556002)(19625215002)(2900100001)(15975445007)(40100003)(2950100001)(5005710100001)(33656002)(8990500004)(450100001)(4001450100002)(10090500001)(19580405001)(19580395003)(77096005)(86362001)(10290500002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123439E7F8083A5C557EED28A6A50BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 18:25:42.8222 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:25:56 -0000

--_000_BN3PR0301MB123439E7F8083A5C557EED28A6A50BN3PR0301MB1234_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91IGhhdmUgbm93IG1hZGUgaXQgZmFyIGVhc2llciBh
bmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvZXMgbm90IGV2ZW4gYWRkcmVzcyB0aGlz
DQoNCkZyb206IE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYg
MTA6MjIgQU0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCkNj
OiA8b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbT0FVVEgt
V0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KQXMgd2XigJlkIGRpc2N1c3NlZCBp
biBwZXJzb24sIHRoZXJl4oCZcyBubyBlZmZlY3RpdmUgc2VjdXJpdHkgZGlmZmVyZW5jZSBiZXR3
ZWVuIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBiZWluZyBwdWJsaXNoZWQgaW4gYW4gYWQtaG9jIGZh
c2hpb24gb24gZGV2ZWxvcGVyIHBhZ2VzIGFuZCBpdCBiZWluZyBwdWJsaXNoZWQgaW4gYSBzdGFu
ZGFyZCBmb3JtYXQuICDigJxTZWN1cml0eSBieSBvYnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNl
Y3VyaXR5IGF0IGFsbC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluDQpTZW50
OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFNDQpUbzogTWlrZSBKb25lcyA8
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20+PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp
bC5odW50QG9yYWNsZS5jb20+PjsgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFp
bHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+DQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0
aEBpZXRmLm9yZz4+IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3Vi
amVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQo+IFRo
ZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBk
aXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC4N
Cg0KVGhhdCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRl
cGxveWVkIGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt
IGRpc2NvdmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBP
QXV0aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhh
dCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3Vu
ZCB0aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1
cHQgeW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNl
Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYXQgYWxsDQoNCkZyb206IE9BdXRoIFttYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6
IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTQ0KVG86IFBoaWwgSHVudCAoSURN
KSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IE5h
dCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+
Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0
Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9B
dXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KVGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRv
IGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRo
YXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLg0KDQpOb25lIG9mIE5hdCBvciBKb2huIG9y
IEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3
b27igJl0IGJlIGNyZWF0ZWQuICBJ4oCZbSBzdXJlIGl0IHdpbGwgYmUuICBTb21lIGFwcGxpY2F0
aW9ucyB3aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEu
ICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4gIFNvbWUgd2lsbCBwb3NzaWJs
eSB1c2UgYXBwbGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24gdmFsdWVzLiAgSeKAmW0gc3Vy
ZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4g
IEFsbCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9j
dW1lbnQgZm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBv
c3NpYmx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy4N
Cg0KU28gYnkgYWxsIG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlz
Y3Vzc2luZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1h
a2Ugc2Vuc2UgaW4gc29tZSBjb250ZXh0cy4gIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGNhbiBmaW5p
c2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlv
bmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2lsbCBuZWVkLg0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr
ZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBQaGlsIEh1bnQgKElETSkNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYg
ODozOSBBTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtp
bXVyYUBnbWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v
cmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJl
OiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KSSBhbSBzdWdnZXN0
aW5nIHRoYXQgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xp
ZW50IGluZGljYXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGgg
Y29uZmlndXJhdGlvbiBkYXRhIGZvci4NCg0KU28gaWYgcmVzLmV4YW1wbGUuZXZpbC5jb208aHR0
cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUy
ZiUyZnJlcy5leGFtcGxlLmV2aWwuY29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv
ZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0
MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9UGMlMmI3aWxuRFlnZmpZb1RzUVdvWm5wb2JH
JTJiVkpwNVd1OWNHcEZVZ3ozUzAlM2Q+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50
IGZvciBhcy5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXMuZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdj
dG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2Nm
OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT02JTJicXhoJTJm
N1ZDWmtzd1hoSk12NnIlMmIxOGRUUmJnMklzMTJXQiUyZmRabTNjSjQlM2Q+IHRoZSBhdXRoeiBk
aXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4NCg0K
VGhlcmUgbWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5
LiBPciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4NCg0KT25lIG9mIE9BdXRoJ3Mgc3Ry
ZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlv
biAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVw
IGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxh
dGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5
IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRh
bnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5k
cG9pbnRzIGV0Yy4NCg0KVGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdnbGMg
b24gZGlzY292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRpb24g
YnV0IHdlIGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElNTy4N
Cg0KSSBhbSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21l
IGRyYWZ0IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQg
bm93Lg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6MTIsIE5hdCBTYWtpbXVyYSA8
c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCkhp
IFBoaWwsDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0YSBzaG91bGQg
aW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0IGl0IGNhbiBi
ZSBkb25lLCBJIGd1ZXNzLg0KDQpUaGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdA0KDQox
LiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4NCjIuIEFTIHRlbGxzIHRoZSBj
bGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4NCg0KRXZlbiBp
ZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRvIHRo
ZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFzIHRo
ZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGllbnQg
bWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uDQoNCk5hdA0KDQoyMDE25bm0MuaciDI05pel
KOawtCkgMjM6NTkgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o
dW50QG9yYWNsZS5jb20+PjoNCk5hdCwNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhl
IHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24g
c2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUg
QXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBi
b3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNv
dXJjZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KSWYgYSBjbGllbnQg
ZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWluZyBmb3IgYSBy
ZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3aWxsIG5vdCBs
ZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJlc291cmNlIHNl
cnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0IGhhdmUgYSBm
YWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291
cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBj
b252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNl
IGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuDQoNClRoZSBPQXV0
aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0
aGUgc2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBl
bmRwb2ludC4NCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3Vs
ZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KUGhpbA0KDQpAaW5kZXBl
bmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5j
b20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0
ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj
MSZzZGF0YT1NSldwRkIxMnZUTEI0ZWNLeVl3bFpMblJKSW5hTkV3MU13bHZ0VTI2QlBBJTNkPg0K
cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0K
DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21h
aWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpIaSBUaG9tYXMs
DQoNCmlubGluZToNCg0KMjAxNuW5tDLmnIgyMuaXpSjmnIgpIDE4OjQ0IFRob21hcyBCcm95ZXIg
PHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQpDb3VsZG4n
dCB0aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0aGUgbWV0YWRhdGE/DQpJIHF1aXRlIGxpa2Ug
dGhlIGlkZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdhbnQg
dG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0byBv
dGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICJhdXRvLWNvbmZpZ3Vy
YXRpb24iLg0KVGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJl
IHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJhLW9hdXRo
LW1ldGEgbWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBtZXRhZGF0
YSBzcGVjcyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuDQpXaXRoIGRyYWZ0LXNha2ltdXJhLW9hdXRo
LW1ldGEncyAiZHVyaSIgYW5kIHRoZSAic2NvcGUiIGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGlj
YXRlIHJlc3BvbnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9j
ZWVkDQoNCll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWws
IGlzIGl0IG5vdD8NCg0KSW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRo
b3JpemF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2Us
IHlvdSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKQ0KU28sIHRoZSByZXNvdXJjZSBzZXJ2
ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRo
eiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5
IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogc2VydmVyIGNvbmZpZ3Vy
YXRpb24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24g
d2hhdCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJz
IGZyb20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91
bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJs
ZS4NCg0KKHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRp
ZmZlcmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1h
eWJlIFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0
ZXIgc3VjaCB0aGF0IGFuIFJTIGNvdWxkIHJldHVybiBzZXZlcmFsIFdXVy1BdXRoZW50aWNhdGU6
IEJlYXJlciwgZWFjaCB3aXRoIGl0cyBvd24gInNjb3BlIiBhbmQgImR1cmkiIHZhbHVlPykNCg0K
WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBlZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8g
c2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMgdG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRl
ciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBvbiBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBh
cmFtZXRlciB2YWx1ZXMuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0KT24gRnJpLCBGZWIgMTksIDIw
MTYgYXQgMTA6NTkgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmlj
aGVyQG1pdC5lZHU+PiB3cm90ZToNClRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBk
b2N1bWVudCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQg
ZG9lcywgaG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklE
IENvbm5lY3Qgb3JpZ2lucy4gT25lIGlzc3VlIGluIHBhcnRpY3VsYXIgc3RpbGwgcmVhbGx5IGJv
dGhlcnMgbWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
4oCdIGluIHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0aCBkaXNjb3Zlcnkg
ZG9jdW1lbnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhlcmUgaXMgYWJzb2x1dGVseSBu
byBjb21wZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0aGUgT0lEQyBkaXNjb3Zlcnkg
bWVjaGFuaXNtLg0KDQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRo
LWF1dGhvcml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlv
biwgYW5kIHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9t
IOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFs
c28gcHJvdmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlciBhcHBs
aWNhdGlvbnMgU0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUg
T0F1dGggZW5kcG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lm
aWMgZGlzY292ZXJ5IGRvY3VtZW50Lg0KDQog4oCUIEp1c3Rpbg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA
aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0
aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZh
MzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk
MDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBa
UEp4dGw0JTNkPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczov
L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUy
Znd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3
Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0Mzdj
ZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJi
RGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1
dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u
b3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZs
aXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
ZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0
MHBaUEp4dGw0JTNkPg0KDQo=

--_000_BN3PR0301MB123439E7F8083A5C557EED28A6A50BN3PR0301MB1234_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFu
LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91
IGhhdmUgbm93IG1hZGUgaXQgZmFyIGVhc2llciBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp
b25zIGRvZXMgbm90IGV2ZW4gYWRkcmVzcyB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWlrZSBKb25lcw0KPGJy
Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTA6MjIgQU08YnI+
DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0
Ozxicj4NCjxiPkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5v
cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNj
b3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QXMgd2XigJlkIGRpc2N1c3NlZCBp
biBwZXJzb24sIHRoZXJl4oCZcyBubyBlZmZlY3RpdmUgc2VjdXJpdHkgZGlmZmVyZW5jZSBiZXR3
ZWVuIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBiZWluZyBwdWJsaXNoZWQgaW4gYW4gYWQtaG9jIGZh
c2hpb24gb24gZGV2ZWxvcGVyIHBhZ2VzIGFuZA0KIGl0IGJlaW5nIHB1Ymxpc2hlZCBpbiBhIHN0
YW5kYXJkIGZvcm1hdC4mbmJzcDsg4oCcU2VjdXJpdHkgYnkgb2JzY3VyaXR54oCdIGFkZHMgbm8g
cmVhbCBzZWN1cml0eSBhdCBhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij4gQW50aG9ueSBOYWRhbGluDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFy
eSAyNCwgMjAxNiAxMDowMSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPC9hPiZndDs7IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OyBOYXQgU2Fr
aW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdt
YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo
QGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1
dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4gVGhlIHBv
aW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2Nv
dmVyeSBmdW5jdGlvbmFsaXR5DQogdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGF0IG1heSBiZSB3aWRl
bHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQgZm9yIE9BdXRoLiBU
aGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292ZXJ5IGZvciBlbmRw
b2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90DQogYmUgaW4gYW4gT0F1dGggc3RhbmRhcmQgc2lu
Y2UgaXTigJlzIHJlYWxseSBub3QgZGVhbHQgd2l0aC4gTm93IHRoYXQgYWxsIHRoaXMgaW5mb3Jt
YXRpb24gaXMgYXZhaWxhYmxlIGl0IG1ha2VzIHBva2luZyBhcm91bmQgdGhlIGVuZHBvaW50IG1v
cmUgZm9jdXNlZCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0byBkaXNydXB0IHlvdXIgZW5kcG9pbnRz
LCB0aGF0IGlzIHJlYWxseSBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0
aW9ucw0KIHNlY3Rpb24gYXQgYWxsIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEg
aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNl
bnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDk6NTQgQU08YnI+DQo8Yj5Ubzo8
L2I+IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu
Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OyBOYXQgU2FraW11cmEgJmx0OzxhIGhy
ZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7
PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0
aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h
dXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgcG9p
bnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292
ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5Ob25lIG9mIE5hdCBvciBKb2hu
IG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0
eSB3b27igJl0IGJlIGNyZWF0ZWQuJm5ic3A7IEnigJltIHN1cmUgaXQgd2lsbCBiZS4mbmJzcDsg
U29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgV2ViRmluZ2VyIHRvDQogbG9jYXRlIHRoZSBkaXNj
b3ZlcnkgbWV0YWRhdGEuJm5ic3A7IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJz
LiZuYnNwOyBTb21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNwZWNpZmljIC53ZWxs
LWtub3duIHZhbHVlcy4mbmJzcDsgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkg
aGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4mbmJzcDsgQWxsIG9mIHRoZXNlIGRlcGVuZCB1
cG9uIGhhdmluZyBhIGRpc2NvdmVyeSBtZXRhZGF0YSBkb2N1bWVudA0KIGZvcm1hdCBhbmQgbm9u
ZSBvZiB0aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdpc3RlciBh
ZGRpdGlvbmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5TbyBieSBhbGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3Vw
IHNob3VsZCBjb250aW51ZSBkaXNjdXNzaW5nIGludmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRl
ZCBtZWNoYW5pc21zIHRoYXQgbWFrZSBzZW5zZSBpbiBzb21lIGNvbnRleHRzLiZuYnNwOyBBdCB0
aGUgc2FtZSB0aW1lLCB3ZQ0KIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3
aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hh
bmlzbXMgd2lsbCBuZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9B
dXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQgKElE
TSk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFN
PGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZn
dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVy
eSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRp
b24gaGFzIHRvIGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50
IGl0IHdhbnRzIHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEgZm9yLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl
TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiA8YSBocmVmPSJodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm
JTJmcmVzLmV4YW1wbGUuZXZpbC5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVBjJTJiN2lsbkRZZ2ZqWW9Uc1FX
b1pucG9iRyUyYlZKcDVXdTljR3BGVWd6M1MwJTNkIj4NCnJlcy5leGFtcGxlLmV2aWwuY29tPC9h
PiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgPGEgaHJlZj0iaHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFz
LmV4YW1wbGUuY29tJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT02JTJicXhoJTJmN1ZDWmtzd1hoSk12NnIlMmIxOGRU
UmJnMklzMTJXQiUyZmRabTNjSjQlM2QiPg0KYXMuZXhhbXBsZS5jb208L2E+IHRoZSBhdXRoeiBk
aXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgbWF5
IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBPciBjaGFu
Z2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25l
c3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBp
cyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVn
aXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiBy
ZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4NCiBkaXNjb3ZlcnkgcGhhc2UgcmVnaXN0cmF0
aW9uIGhhcyBub3QgeWV0IG9jY3VycmVkIGl0IHNlZW1zIGltcG9ydGFudCB0aGF0IHRoZSBjbGll
bnQga25vdyBpdCBoYXMgYSB2YWxpZCBjb21iaW5hdGlvbiBvZiBlbmRwb2ludHMgZXRjLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdo
eSBJIHdhcyBkaXNhcHBvaW50ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0
YXJ0aW5nIHBvaW50IGZvciBncm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVm
aW5lZCB0aGUgZnVsbCByZXF1aXJlbWVudHMgSU1PLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVy
ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0
IHNvbWUgdGhvdWdodCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBh
cG9sb2dpemUgSSBjYW4ndCBkbyBpdCBub3cuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2Fr
aW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdt
YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRo
ZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBk
b2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd2F5IG9hdXRoLW1l
dGEgd29ya3MgaXMgdGhhdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBp
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBj
YW4gYmUgdXNlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2Vy
dHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQg
dGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3Qg
dGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KTmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+MjAxNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuW5tDwvc3Bhbj4y
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5pyIPC9zcGFuPjI0PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj7msLQ8L3NwYW4+KSAyMzo1OSBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCw8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB0
aGF0IGhhdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVyZSBpdHMg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIHNlcnZl
ciBuZWVkIHRvIGJlIGJvdW5kIHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5DQogZW5k
cG9pbnRzICh0aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2aWNlIGRpc2NvdmVyeSku
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg
YSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWlu
ZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3
aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJl
c291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0
IGhhdmUNCiBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRl
cmNlcHQgcmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2Vy
ZSBhYmxlIHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0
aW9uIHNlcnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl
IE9BdXRoIERpc2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0
aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291
cmNlIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGlzIG5vdCBvbmx5IHdvcmtzIGluIG5vcm1hbCBPQXV0aCBidXQgc2hvdWxk
IGFkZCBzZWN1cml0eSBldmVuIHRvIFVNQSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5A
aW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy
Znd3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9TUpXcEZCMTJ2VExCNGVjS3lZd2xa
TG5SSkluYU5FdzFNd2x2dFUyNkJQQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVu
dGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp
bC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAyNCwg
MjAxNiwgYXQgMzo1NCBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11
cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48YnI+DQpIaSBUaG9tYXMsJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPmlubGluZTombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW5
tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
nIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYi
PuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4oPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlm
Ij7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0KIDE4OjQ0IFRob21hcyBCcm95ZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJy
b3llckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNvdWxkbid0IHRoZSBkb2N1bWVu
dCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBxdWl0ZSBsaWtlIHRo
ZSBpZGVhIG9mJm5ic3A7ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdh
bnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0
byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICZxdW90O2F1dG8t
Y29uZmlndXJhdGlvbiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbWV0YWRhdGEgZGVz
Y3JpYmVkIGhlcmUgd291bGQgdGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwg
cmV0dXJuZWQgYXMmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRo
ZSBSUzsgb3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UNCiBPcGVu
SUQgQ29ubmVjdCkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+V2l0aCZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAmcXVvdDtk
dXJpJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsgYXR0cmlidXRlIG9mIFdXVy1BdXRo
ZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBuZWVkIHRv
IHByb2NlZWQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WXVwLiBUaGF0J3Mgb25lIG9mIHRo
ZSByZXF1aXJlbWVudHMgdG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90PyAmbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiBPQXV0aCdzIGNhc2UsIHRo
ZSByZXNvdXJjZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0
bHkgY291cGxlZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4p
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxk
IGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2lu
dC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwg
cmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUNCiBhdXRoeiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBk
YXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBoYXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53
ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZyZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBj
b25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlzaW9ucyBldGMuIFdlIHNob3VsZCBzdHJp
dmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBhcyBtdWNoIGFzIHBvc3NpYmxlLiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4o
d2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFyZSBzZXZlcmFsIEFTcyBlYWNoIHdpdGggZGlmZmVyZW50
IHNjb3Blczsgc291bmRzIGxpa2UgYW4gZWRnZS1jYXNlIHRvIG1lIHRob3VnaDsgbWF5YmUgUkZD
Njc1MCBzaG91bGQgaW5zdGVhZCBiZSB1cGRhdGVkIHdpdGggc3VjaCBhIHBhcmFtZXRlciBzdWNo
DQogdGhhdCBhbiBSUyBjb3VsZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFy
ZXIsIGVhY2ggd2l0aCBpdHMgb3duICZxdW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtkdXJpJnF1
b3Q7IHZhbHVlPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBl
ZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMg
dG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBv
biBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlcg0KIHZhbHVlcy4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsJm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TmF0PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmks
IEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls
dG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPlRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVu
dCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywg
aG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5l
Y3Qgb3JpZ2lucy4gT25lDQogaXNzdWUgaW4gcGFydGljdWxhciBzdGlsbCByZWFsbHkgYm90aGVy
cyBtZTogdGhlIHVzZSBvZiDigJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0g
aW4gdGhlIGRpc2NvdmVyeSBwb3J0aW9uLiBJcyB0aGlzIGFuIE9BdXRoIGRpc2NvdmVyeSBkb2N1
bWVudCwgb3IgYW4gT3BlbklEIENvbm5lY3Qgb25lPyBUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIGNv
bXBlbGxpbmcgcmVhc29uIHRvIHRpZSB0aGUgVVJMIHRvIHRoZSBPSURDIGRpc2NvdmVyeQ0KIG1l
Y2hhbmlzbS48YnI+DQo8YnI+DQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3du
L29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBs
b2NhdGlvbiwgYW5kIHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJs
ZSBmcm9tIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2Vy
dmVyIGFsc28gcHJvdmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhl
cg0KIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBk
ZXNjcmliZSBPQXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2Vydmlj
ZS1zcGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A74oCUIEp1c3Rp
bjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl
MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3
YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMz
ZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9
Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v
cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2
eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh
bj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy
Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp
bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
ZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043
RUp4NDBwWlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BN3PR0301MB123439E7F8083A5C557EED28A6A50BN3PR0301MB1234_--


From nobody Wed Feb 24 10:31:23 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94211B3BEB for ; Wed, 24 Feb 2016 10:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 PunvBgFUA96w for ; Wed, 24 Feb 2016 10:31:17 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6711B3A29 for ; Wed, 24 Feb 2016 10:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0PlQF7KKsxDMIhyjL3q6+y++HiUc3bGrVrRg0bRwwXA=; b=LU3ooLLgQO5Hw5xbvFZl0aK9/+V5gXhpSNzBgi25UeMPS3jhAPcyfXjnf1xp8nUBR+mYohDnfpTt77lUVjIY/TEDCYpeI/9N8IU9YTJkVAPUFK8Au/2R19dBuj97g43kUTvScmVrD9qX6AuciCGyrvsv9UfDWMenbdt4+yL2ZQ8=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 18:31:08 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 18:31:05 +0000
From: Mike Jones 
To: Anthony Nadalin 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAAQdw
Date: Wed, 24 Feb 2016 18:31:05 +0000
Message-ID: 
References:          
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: fefb2879-c051-48da-7863-08d33d48a815
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:2LEtpSfERZ3XhH4OA0kclgwSn9RK2fWzXS+yVCYHki64TsrJlY8U/J//dTiZmXuhc6m+hRy7wvpkiKwdq0f8QiChPSNxp7AG4NLr4MXhQDQoC47WUer7iKqdDvTMvq6hwKUMHpv3SAuilHzwbXm57Q==; 24:6+ElcXnbKZE9VK8T4JLcNizUcfd27qOqG2PdvPvfc4PHlVI14nXARYGsymnU3mpQTM9PfPypl9lmmvF2Mx3VqXbbHTU1/mInvRcgJhKIIb0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(72854002)(377454003)(24454002)(19580405001)(1511001)(586003)(19580395003)(93886004)(74316001)(3660700001)(3280700002)(3846002)(5003600100002)(19625215002)(33656002)(66066001)(1220700001)(15975445007)(4326007)(2900100001)(77096005)(2950100001)(2561002)(450100001)(2906002)(3900700001)(10290500002)(5008740100001)(5005710100001)(790700001)(1096002)(6116002)(5004730100002)(102836003)(10400500002)(122556002)(8990500004)(40100003)(76576001)(19300405004)(76176999)(92566002)(99286002)(87936001)(106116001)(19617315012)(5001960100002)(110136002)(189998001)(10090500001)(4001450100002)(50986999)(54356999)(5002640100001)(86362001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442FCAEAB590BE8090F0B86F5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 18:31:05.3478 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 18:31:21 -0000

--_000_BY2PR03MB442FCAEAB590BE8090F0B86F5A50BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2UgY291bGQgYWRkIGEgc3RhdGVtZW50IHNvbWV0aGluZyBsaWtlIHRoaXMgdG8gdGhlIHNlY3Vy
aXR5IGNvbnNpZGVyYXRpb25zOg0KDQrigJxQdWJsaXNoaW5nIGluZm9ybWF0aW9uIGFib3V0IHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbiBhIHN0YW5kYXJkIGZvcm1hdCBtYWtlcyBpdCBlYXNp
ZXIgZm9yIGJvdGggbGVnaXRpbWF0ZSBjbGllbnRzIGFuZCBhdHRhY2tlcnMgdG8gdXNlIHRoZSBh
dXRob3JpemF0aW9uIHNlcnZlci7igJ0NCg0KSSBiZWxpZXZlIHRoYXQgc3BlYWtzIHRvIHRoZSBw
b2ludCB5b3XigJlyZSBtYWtpbmcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEFudGhvbnkgTmFkYWxp
bg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMDoyNiBBTQ0KVG86IE1pa2Ug
Sm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiA8b2F1dGhAaWV0Zi5vcmc+
IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNj
b3ZlcnkgTG9jYXRpb24NCg0KU3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91IGhhdmUgbm93IG1h
ZGUgaXQgZmFyIGVhc2llciBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvZXMgbm90
IGV2ZW4gYWRkcmVzcyB0aGlzDQoNCkZyb206IE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwg
RmVicnVhcnkgMjQsIDIwMTYgMTA6MjIgQU0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRA
bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkNjOiA8b2F1dGhA
aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRoQGlldGYub3JnPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292
ZXJ5IExvY2F0aW9uDQoNCkFzIHdl4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMg
bm8gZWZmZWN0aXZlIHNlY3VyaXR5IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3Jt
YXRpb24gYmVpbmcgcHVibGlzaGVkIGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBw
YWdlcyBhbmQgaXQgYmVpbmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiAg4oCcU2Vj
dXJpdHkgYnkgb2JzY3VyaXR54oCdIGFkZHMgbm8gcmVhbCBzZWN1cml0eSBhdCBhbGwuDQoNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt
LSBNaWtlDQoNCkZyb206IEFudGhvbnkgTmFkYWxpbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy
eSAyNCwgMjAxNiAxMDowMSBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IFBoaWwgSHVudCAo
SURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47
IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhA
aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0dd
IE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KPiBUaGUgcG9pbnQgb2YgdGhlIFdHTEMg
aXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxp
dHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuDQoNClRoYXQgbWF5IGJlIHdpZGVs
eSBkZXBsb3llZCBmb3IgT0lEQyBidXQgbm90IHdpZGVseSBkZXBsb3llZCBmb3IgT0F1dGguIFRo
ZXJlIGFyZSBzb21lIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBkaXNjb3ZlcnkgZm9yIGVuZHBv
aW50IHRoYXQgcmVhbGx5IHNob3VsZCBub3QgYmUgaW4gYW4gT0F1dGggc3RhbmRhcmQgc2luY2Ug
aXTigJlzIHJlYWxseSBub3QgZGVhbHQgd2l0aC4gTm93IHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRp
b24gaXMgYXZhaWxhYmxlIGl0IG1ha2VzIHBva2luZyBhcm91bmQgdGhlIGVuZHBvaW50IG1vcmUg
Zm9jdXNlZCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0byBkaXNydXB0IHlvdXIgZW5kcG9pbnRzLCB0
aGF0IGlzIHJlYWxseSBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u
cyBzZWN0aW9uIGF0IGFsbA0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5
IDI0LCAyMDE2IDk6NTQgQU0NClRvOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUu
Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+OyBOYXQgU2FraW11cmEgPHNha2ltdXJh
QGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4NCkNjOiA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp
ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExv
Y2F0aW9uDQoNClRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemlu
ZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVs
eSBkZXBsb3llZC4NCg0KTm9uZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0aW5nIHRo
YXQgYWRkaXRpb25hbCByZWxhdGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVhdGVkLiAg
SeKAmW0gc3VyZSBpdCB3aWxsIGJlLiAgU29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgV2ViRmlu
Z2VyIHRvIGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiAgU29tZSB3aWxsIHBvc3NpYmx5
IHVzZSBsaW5rIGhlYWRlcnMuICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNw
ZWNpZmljIC53ZWxsLWtub3duIHZhbHVlcy4gIEnigJltIHN1cmUgdGhlcmXigJlzIG90aGVyIHRo
aW5ncyBJIGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuICBBbGwgb2YgdGhlc2UgZGVwZW5k
IHVwb24gaGF2aW5nIGEgZGlzY292ZXJ5IG1ldGFkYXRhIGRvY3VtZW50IGZvcm1hdCBhbmQgbm9u
ZSBvZiB0aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdpc3RlciBh
ZGRpdGlvbmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMuDQoNClNvIGJ5IGFsbCBtZWFucywg
dGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGNvbnRpbnVlIGRpc2N1c3NpbmcgaW52ZW50aW5nIHBv
c3NpYmxlIG5ldyByZWxhdGVkIG1lY2hhbmlzbXMgdGhhdCBtYWtlIHNlbnNlIGluIHNvbWUgY29u
dGV4dHMuICBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBjYW4gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhl
IGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0aGF0IGFsbCBvZiB0
aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50IChJRE0p
DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDg6MzkgQU0NClRvOiBOYXQgU2Fr
aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4NCkNj
OiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRoQGlldGYub3Jn
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAy
LjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCkkgYW0gc3VnZ2VzdGluZyB0aGF0IHBhcnQgb2YgdGhl
IGRpc2NvdmVyeSBzb2x1dGlvbiBoYXMgdG8gYmUgdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoYXQg
cmVzb3VyY2UgZW5kcG9pbnQgaXQgd2FudHMgdGhlIG9hdXRoIGNvbmZpZ3VyYXRpb24gZGF0YSBm
b3IuDQoNClNvIGlmIHJlcy5leGFtcGxlLmV2aWwuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZyZXMuZXhhbXBsZS5ldmls
LmNvbSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2
YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl
N2MxJnNkYXRhPVBjJTJiN2lsbkRZZ2ZqWW9Uc1FXb1pucG9iRyUyYlZKcDVXdTljR3BGVWd6M1Mw
JTNkPiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgYXMuZXhhbXBsZS5jb208
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz
YSUyZiUyZmFzLmV4YW1wbGUuY29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9NiUyYnF4aCUyZjdWQ1prc3dYaEpNdjZyJTJiMThk
VFJiZzJJczEyV0IlMmZkWm0zY0o0JTNkPiB0aGUgYXV0aHogZGlzY292ZXJ5IHNob3VsZCBmYWls
IGluIHNvbWUgd2F5IChlZyByZXR1cm4gbm90aGluZykuDQoNClRoZXJlIG1heSBiZSBiZXR0ZXIg
d2F5cyB0byBkbyB0aGlzLiBFZyBjb21iaW5lIGRpc2NvdmVyeS4gT3IgY2hhbmdlIHRoZSBvcmRl
ciBvZiBkaXNjb3ZlcnkuDQoNCk9uZSBvZiBPQXV0aCdzIHN0cmVuZ3RoJ3MgYW5kIHdlYWtuZXNz
ZXMgaXMgdGhhdCB0aGUgdGFyZ2V0IG9mIGF1dGhvcml6YXRpb24gKHRoZSByZXNvdXJjZSkgaXMg
bmV2ZXIgc3BlY2lmaWVkLiBJdCBpcyBvZnRlbiBib3VuZCB1cCBpbiB0aGUgY2xpZW50IHJlZ2lz
dHJhdGlvbiBhbmQgYW4gb2Z0ZW4gaW1wbGllZCAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gcmVz
b3VyY2UgYW5kIGFzLiBHaXZlbiB0aGF0IGluIGRpc2NvdmVyeSBwaGFzZSByZWdpc3RyYXRpb24g
aGFzIG5vdCB5ZXQgb2NjdXJyZWQgaXQgc2VlbXMgaW1wb3J0YW50IHRoYXQgdGhlIGNsaWVudCBr
bm93IGl0IGhhcyBhIHZhbGlkIGNvbWJpbmF0aW9uIG9mIGVuZHBvaW50cyBldGMuDQoNClRoaXMg
aXMgd2h5IEkgd2FzIGRpc2FwcG9pbnRlZCBhYm91dCB3Z2xjIG9uIGRpc2NvdmVyeS4gV2UgaGFk
IGEgc3RhcnRpbmcgcG9pbnQgZm9yIGdyb3VwIGFkb3B0aW9uIGJ1dCB3ZSBoYXZlbid0IHJlYWxs
eSBkZWZpbmVkIHRoZSBmdWxsIHJlcXVpcmVtZW50cyBJTU8uDQoNCkkgYW0gb24gdmFjYXRpb24g
b3IgSSB3b3VsZCBwdXQgc29tZSB0aG91Z2h0IGludG8gc29tZSBkcmFmdCBjaGFuZ2VzIG9yIGEg
bmV3IGRyYWZ0LiBJIGFwb2xvZ2l6ZSBJIGNhbid0IGRvIGl0IG5vdy4NCg0KUGhpbA0KDQpPbiBG
ZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxt
YWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBQaGlsLA0KDQpBcmUgeW91IHN1
Z2dlc3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUgdGhlIFJTIFVSSXM/
IEN1cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwgSSBndWVzcy4NCg0K
VGhlIHdheSBvYXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQNCg0KMS4gUlMgdGVsbHMgdGhlIGNsaWVu
dCB3aGVyZSB0aGUgQVMgaXMuDQoyLiBBUyB0ZWxscyB0aGUgY2xpZW50IHdoaWNoIFJTIGVuZHBv
aW50cyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuDQoNCkV2ZW4gaWYgdGhlcmUgaXMgYSBiYWQgQVMg
d2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBSUywgdGhlIGNsaWVu
dCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHogc2VydmVyIHdpbGwg
c2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50IHRvIHNlbmQgdGhl
IHRva2VuIHRvLg0KDQpOYXQNCg0KMjAxNuW5tDLmnIgyNOaXpSjmsLQpIDIzOjU5IFBoaWwgSHVu
dCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46DQpO
YXQsDQoNCknigJltIG5vdCBzdXJlIHRoYXQgaGF2aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGVs
bCB0aGUgY2xpZW50IHdoZXJlIGl0cyBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBzZWN1cmUgYnkg
aXRzZWxmLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVy
IGFuZCB0aGUgUmVzb3VyY2Ugc2VydmVyIG5lZWQgdG8gYmUgYm91bmQgdG9nZXRoZXIgaW4gb25l
IG9mIHRoZSBkaXNjb3ZlcnkgZW5kcG9pbnRzICh0aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0
aCBzZXJ2aWNlIGRpc2NvdmVyeSkuDQoNCklmIGEgY2xpZW50IGRpc2NvdmVycyBhIGZha2UgcmVz
b3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9yIGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIg
dGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBub3QgbGVhZCB0aGUgY2xpZW50IHRvIHVu
ZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJjZSBzZXJ2ZXIuIFJhdGhlciB0aGUgZmFr
ZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZlIGEgZmFrZSBkaXNjb3Zlcnkgc2Vydmlj
ZS4gVGhlIGhhY2tlciBjYW4gbm93IGludGVyY2VwdCByZXNvdXJjZSBwYXlsb2FkIGFzIHdlbGwg
YXMgdG9rZW5zIGJlY2F1c2UgdGhleSB3ZXJlIGFibGUgdG8gY29udmluY2UgdGhlIGNsaWVudCB0
byB1c2UgdGhlIGxlZ2l0IGF1dGhvcml6YXRpb24gc2VydmljZSBidXQgdXNlIHRoZSB0b2tlbiBh
Z2FpbnN0IHRoZSBoYWNrZXJzIHByb3h5Lg0KDQpUaGUgT0F1dGggRGlzY292ZXJ5IHNlcnZpY2Ug
bmVlZHMgdG8gY29uZmlybSB0byB0aGUgY2xpZW50IHRoYXQgdGhlIHNlcnZlciBpcyBhYmxlIHRv
IGlzc3VlIHRva2VucyBmb3IgYSBzdGF0ZWQgcmVzb3VyY2UgZW5kcG9pbnQuDQoNClRoaXMgbm90
IG9ubHkgd29ya3MgaW4gbm9ybWFsIE9BdXRoIGJ1dCBzaG91bGQgYWRkIHNlY3VyaXR5IGV2ZW4g
dG8gVU1BIHNpdHVhdGlvbnMuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVu
ZGVudGlkLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwJTNhJTJmJTJmd3d3LmluZGVwZW5kZW50aWQuY29tJmRhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjkl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9TUpXcEZCMTJ2VExC
NGVjS3lZd2xaTG5SSkluYU5FdzFNd2x2dFUyNkJQQSUzZD4NCnBoaWwuaHVudEBvcmFjbGUuY29t
PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBh
dCAzOjU0IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11
cmFAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KSGkgVGhvbWFzLA0KDQppbmxpbmU6DQoNCjIwMTbl
ubQy5pyIMjLml6Uo5pyIKSAxODo0NCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208
bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+Og0KQ291bGRuJ3QgdGhlIGRvY3VtZW50IG9ubHkg
ZGVzY3JpYmUgdGhlIG1ldGFkYXRhPw0KSSBxdWl0ZSBsaWtlIHRoZSBpZGVhIG9mIGRyYWZ0LXNh
a2ltdXJhLW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRpc2NvdmVyeSwgYW5k
IGxlYXZlIGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3BlY3MgdG8gZGVmaW5l
IGEgLndlbGwta25vd24gVVJMIGZvciAiYXV0by1jb25maWd1cmF0aW9uIi4NClRoZSBtZXRhZGF0
YSBkZXNjcmliZWQgaGVyZSB3b3VsZCB0aGVuIGVpdGhlciBiZSB1c2VkIGFzLWlzLCBhdCBhbnkg
VVJMLCByZXR1cm5lZCBhcyBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRo
ZSBSUzsgb3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UgT3BlbklE
IENvbm5lY3QpLg0KV2l0aCBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJ3MgImR1cmkiIGFuZCB0
aGUgInNjb3BlIiBhdHRyaWJ1dGUgb2YgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIs
IHlvdSBoYXZlIGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8gcHJvY2VlZA0KDQpZdXAuIFRoYXQncyBv
bmUgb2YgdGhlIHJlcXVpcmVtZW50cyB0byBiZSBSRVNUZnVsLCBpcyBpdCBub3Q/DQoNCkluIE9B
dXRoJ3MgY2FzZSwgdGhlIHJlc291cmNlIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJl
IHVzdWFsbHkgdGlnaHRseSBjb3VwbGVkLiAoT3RoZXJ3aXNlLCB5b3UgbmVlZCBhbm90aGVyIHNw
ZWNzIGxpa2UgVU1BLikNClNvLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBiZSBhYmxlIHRv
IHRlbGwgZWl0aGVyIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogZW5kcG9pbnQuIEluIHNvbWUg
dHJ1c3RlZCBlbnZpcm9ubWVudCwgdGhlIHJlc291cmNlIG1heSBhcyB3ZWxsIHJldHVybiB0aGUg
bG9jYXRpb24gb2YgdGhlIGF1dGh6IHNlcnZlciBjb25maWd1cmF0aW9uIGRhdGEuIEluIHRoZXNl
IGNhc2VzLCB5b3UgZG8gbm90IGhhdmUgdG8gZGVjaWRlIG9uIHdoYXQgLndlbGwta25vd24gdXJp
IGFzIHlvdSBzYXkuIFRoaXMgZnJlZXMgdXAgZGV2ZWxvcGVycyBmcm9tIGNvbmZpZ3VyYXRpb24g
ZmlsZSBsb2NhdGlvbiBjb2xsaXNpb25zIGV0Yy4gV2Ugc2hvdWxkIHN0cml2ZSBub3QgdG8gcG9s
bHV0ZSB0aGUgdXJpIHNwYWNlIGFzIG11Y2ggYXMgcG9zc2libGUuDQoNCih3ZWxsLCBleGNlcHQg
aWYgdGhlcmUgYXJlIHNldmVyYWwgQVNzIGVhY2ggd2l0aCBkaWZmZXJlbnQgc2NvcGVzOyBzb3Vu
ZHMgbGlrZSBhbiBlZGdlLWNhc2UgdG8gbWUgdGhvdWdoOyBtYXliZSBSRkM2NzUwIHNob3VsZCBp
bnN0ZWFkIGJlIHVwZGF0ZWQgd2l0aCBzdWNoIGEgcGFyYW1ldGVyIHN1Y2ggdGhhdCBhbiBSUyBj
b3VsZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBp
dHMgb3duICJzY29wZSIgYW5kICJkdXJpIiB2YWx1ZT8pDQoNClllYWgsIEkgZ3Vlc3MgaXQgaXMg
YW4gZWRnZSBjYXNlLiBJIHdvdWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2
ZXJzIHRvIGRldmVsb3AgYSB0cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdy
ZWUgb24gYSBzaW5nbGUgc2V0IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLg0KDQpD
aGVlcnMsDQoNCk5hdA0KDQoNCk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDEwOjU5IFBNIEp1c3Rp
biBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6
DQpUaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBh
bmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxs
IGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9u
ZSBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNlIG9m
IOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292ZXJ5
IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBPcGVu
SUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFzb24g
dG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlzbS4NCg0KSSBwcm9w
b3NlIHRoYXQgd2UgdXNlIOKAnC8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZl
cuKAnSBhcyB0aGUgZGVmYXVsdCBkaXNjb3ZlcnkgbG9jYXRpb24sIGFuZCBzdGF0ZSB0aGF0IHRo
ZSBkb2N1bWVudCBNQVkgYWxzbyBiZSByZWFjaGFibGUgZnJvbSDigJwvLndlbGwta25vd24vb3Bl
bmlkLWNvbmZpZ3VyYXRpb27igJ0gaWYgdGhlIHNlcnZlciBhbHNvIHByb3ZpZGVzIE9wZW5JRCBD
b25uZWN0IG9uIHRoZSBzYW1lIGRvbWFpbi4gT3RoZXIgYXBwbGljYXRpb25zIFNIT1VMRCB1c2Ug
dGhlIHNhbWUgcGFyYW1ldGVyIG5hbWVzIHRvIGRlc2NyaWJlIE9BdXRoIGVuZHBvaW50cyBhbmQg
ZnVuY3Rpb25zIGluc2lkZSB0aGVpciBzZXJ2aWNlLXNwZWNpZmljIGRpc2NvdmVyeSBkb2N1bWVu
dC4NCg0KIOKAlCBKdXN0aW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl
M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhk
MzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWdv
MUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZD4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90
ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWls
bWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0
LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFh
ZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZ
N043RUp4NDBwWlBKeHRsNCUzZD4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP
QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRh
PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3
MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh
PWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZD4NCg0K

--_000_BY2PR03MB442FCAEAB590BE8090F0B86F5A50BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt
YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFu
LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIy
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj5XZSBjb3VsZCBhZGQgYSBzdGF0ZW1lbnQgc29tZXRoaW5nIGxpa2Ug
dGhpcyB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj7igJxQdWJsaXNoaW5nIGluZm9ybWF0aW9uIGFib3V0IHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbiBhIHN0YW5kYXJkIGZvcm1hdCBtYWtlcyBpdCBlYXNp
ZXIgZm9yIGJvdGggbGVnaXRpbWF0ZSBjbGllbnRzIGFuZCBhdHRhY2tlcnMgdG8gdXNlIHRoZSBh
dXRob3JpemF0aW9uDQogc2VydmVyLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+SSBiZWxpZXZlIHRoYXQgc3BlYWtzIHRvIHRoZSBwb2ludCB5b3XigJlyZSBt
YWtpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N
YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k
Q29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+IEFudGhvbnkgTmFkYWxpbg0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh
eSwgRmVicnVhcnkgMjQsIDIwMTYgMTA6MjYgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMg
Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDtv
YXV0aEBpZXRmLm9yZyZndDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPlN1cmUgdGhlcmUgaXMsIGl0IGlzIGFzIHlvdSBoYXZlIG5vdyBtYWRlIGl0
IGZhciBlYXNpZXIgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBldmVu
IGFkZHJlc3MgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g
TWlrZSBKb25lcw0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIw
MTYgMTA6MjIgQU08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZn
dDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h
dXRoQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+
b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdH
XSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFzIHdl
4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZmZWN0aXZlIHNlY3VyaXR5
IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gYmVpbmcgcHVibGlzaGVk
IGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBhbmQNCiBpdCBiZWluZyBw
dWJsaXNoZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQuJm5ic3A7IOKAnFNlY3VyaXR5IGJ5IG9ic2N1
cml0eeKAnSBhZGRzIG5vIHJlYWwgc2VjdXJpdHkgYXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+IEFudGhvbnkgTmFkYWxpbg0KPGJyPg0KPGI+U2VudDo8L2I+IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTA6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2Ug
Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBQaGlsIEh1bnQgKElETSkgJmx0Ozxh
IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208
L2E+Jmd0OzsgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwu
Y29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhy
ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRp
b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzAwMjA2MCI+IFRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemlu
ZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eQ0KIHRoYXTigJlzIGFscmVhZHkgd2lk
ZWx5IGRlcGxveWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+
VGhhdCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxv
eWVkIGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRp
c2NvdmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdA0KIGJlIGluIGFuIE9B
dXRoIHN0YW5kYXJkIHNpbmNlIGl04oCZcyByZWFsbHkgbm90IGRlYWx0IHdpdGguIE5vdyB0aGF0
IGFsbCB0aGlzIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpdCBtYWtlcyBwb2tpbmcgYXJvdW5k
IHRoZSBlbmRwb2ludCBtb3JlIGZvY3VzZWQgZm9yIHBlb3BsZSB0aGF0IHdhbnQgdG8gZGlzcnVw
dCB5b3VyIGVuZHBvaW50cywgdGhhdCBpcyByZWFsbHkgbm90IGFkZHJlc3NlZCBpbiB0aGUgc2Vj
dXJpdHkgY29uc2lkZXJhdGlvbnMNCiBzZWN0aW9uIGF0IGFsbCA8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2Ug
Sm9uZXM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA5OjU0
IEFNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OzsgTmF0IFNh
a2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBn
bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0
aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9h
dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzAwMjA2MCI+VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5n
IHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5
IGRlcGxveWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm9u
ZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0aW5nIHRoYXQgYWRkaXRpb25hbCByZWxh
dGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVhdGVkLiZuYnNwOyBJ4oCZbSBzdXJlIGl0
IHdpbGwgYmUuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25zIHdpbGwgdXNlIFdlYkZpbmdlciB0bw0K
IGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiZuYnNwOyBTb21lIHdpbGwgcG9zc2libHkg
dXNlIGxpbmsgaGVhZGVycy4mbmJzcDsgU29tZSB3aWxsIHBvc3NpYmx5IHVzZSBhcHBsaWNhdGlv
bi1zcGVjaWZpYyAud2VsbC1rbm93biB2YWx1ZXMuJm5ic3A7IEnigJltIHN1cmUgdGhlcmXigJlz
IG90aGVyIHRoaW5ncyBJIGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuJm5ic3A7IEFsbCBv
ZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQN
CiBmb3JtYXQgYW5kIG5vbmUgb2YgdGhlbSBjaGFuZ2UgaXQg4oCTIG90aGVyIHRoYW4gcG9zc2li
bHkgdG8gcmVnaXN0ZXIgYWRkaXRpb25hbCBkaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+U28gYnkgYWxsIG1lYW5zLCB0
aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9z
c2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250
ZXh0cy4mbmJzcDsgQXQgdGhlIHNhbWUgdGltZSwgd2UNCiBjYW4gZmluaXNoIHN0YW5kYXJkaXpp
bmcgdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0aGF0IGFs
bCBvZiB0aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+UGhpbCBIdW50IChJRE0pPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkg
MjQsIDIwMTYgODozOSBBTTxicj4NCjxiPlRvOjwvYj4gTmF0IFNha2ltdXJhICZsdDs8YSBocmVm
PSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Ozxi
cj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA
aWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0
aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9B
dXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBzdWdnZXN0aW5nIHRoYXQgcGFydCBvZiB0aGUg
ZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGluZGljYXRpbmcgd2hhdCBy
ZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmlndXJhdGlvbiBkYXRhIGZv
ci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0
dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g
aWYgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t
Lz91cmw9aHR0cCUzYSUyZiUyZnJlcy5leGFtcGxlLmV2aWwuY29tJmFtcDtkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3
Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1QYyUy
YjdpbG5EWWdmallvVHNRV29abnBvYkclMmJWSnA1V3U5Y0dwRlVnejNTMCUzZCI+DQpyZXMuZXhh
bXBsZS5ldmlsLmNvbTwvYT4gaXMgbm90IGEgdmFsaWQgcmVzb3VyY2UgZW5kcG9pbnQgZm9yIDxh
IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHAlM2ElMmYlMmZhcy5leGFtcGxlLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9NiUyYnF4aCUyZjdWQ1pr
c3dYaEpNdjZyJTJiMThkVFJiZzJJczEyV0IlMmZkWm0zY0o0JTNkIj4NCmFzLmV4YW1wbGUuY29t
PC9hPiB0aGUgYXV0aHogZGlzY292ZXJ5IHNob3VsZCBmYWlsIGluIHNvbWUgd2F5IChlZyByZXR1
cm4gbm90aGluZykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl
TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoZXJlIG1heSBiZSBiZXR0ZXIgd2F5cyB0byBkbyB0aGlzLiBFZyBjb21iaW5lIGRp
c2NvdmVyeS4gT3IgY2hhbmdlIHRoZSBvcmRlciBvZiBkaXNjb3ZlcnkuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN
YWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiBPQXV0aCdzIHN0cmVu
Z3RoJ3MgYW5kIHdlYWtuZXNzZXMgaXMgdGhhdCB0aGUgdGFyZ2V0IG9mIGF1dGhvcml6YXRpb24g
KHRoZSByZXNvdXJjZSkgaXMgbmV2ZXIgc3BlY2lmaWVkLiBJdCBpcyBvZnRlbiBib3VuZCB1cCBp
biB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgYW4gb2Z0ZW4gaW1wbGllZCAxOjEgcmVsYXRp
b25zaGlwIGJldHdlZW4gcmVzb3VyY2UgYW5kIGFzLiBHaXZlbiB0aGF0IGluDQogZGlzY292ZXJ5
IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRh
bnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5k
cG9pbnRzIGV0Yy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN
YWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdnbGMgb24gZGlzY292
ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRpb24gYnV0IHdlIGhh
dmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElNTy4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJB
cHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBvbiB2YWNhdGlv
biBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21lIGRyYWZ0IGNoYW5nZXMgb3Ig
YSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQgbm93LiZuYnNwOzxicj4NCjxi
cj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRmViIDI0LCAyMDE2LCBh
dCAwODoxMiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwu
Y29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFBoaWwsJm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgeW91IHN1
Z2dlc3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUgdGhlIFJTIFVSSXM/
IEN1cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwgSSBndWVzcy4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIHdheSBvYXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gUlMgdGVsbHMgdGhlIGNsaWVu
dCB3aGVyZSB0aGUgQVMgaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBBUyB0ZWxscyB0aGUgY2xpZW50IHdoaWNoIFJTIGVuZHBv
aW50cyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4gaWYgdGhlcmUgaXMgYSBiYWQgQVMg
d2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBSUywgdGhlIGNsaWVu
dCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHogc2VydmVyIHdpbGwg
c2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50IHRvIHNlbmQgdGhl
IHRva2VuIHRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTY8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2lt
U3VuIj7lubQ8L3NwYW4+MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuaciDwvc3Bh
bj4yNDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuaXpTwvc3Bhbj4oPHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5rC0PC9zcGFuPikgMjM6NTkgUGhpbCBIdW50ICZsdDs8
YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29t
PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5OYXQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBj
bGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYu
IFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRo
ZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhl
IGRpc2NvdmVyeQ0KIGVuZHBvaW50cyAodGhlIHJlc291cmNlIGFuZC9vciB0aGUgb2F1dGggc2Vy
dmljZSBkaXNjb3ZlcnkpLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPklmIGEgY2xpZW50IGRpc2NvdmVycyBhIGZha2UgcmVzb3VyY2Ugc2VydmVy
IHRoYXQgaXMgcHJveHlpbmcgZm9yIGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIgdGhlIGN1cnJlbnQg
ZGlzY292ZXJ5IHNwZWMgd2lsbCBub3QgbGVhZCB0aGUgY2xpZW50IHRvIHVuZGVyc3RhbmQgaXQg
aGFzIHRoZSB3cm9uZyByZXNvdXJjZSBzZXJ2ZXIuIFJhdGhlciB0aGUgZmFrZSByZXNvdXJjZSBz
ZXJ2aWNlIHdpbGwganVzdCBoYXZlDQogYSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFj
a2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMg
YmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUg
bGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhl
IGhhY2tlcnMgcHJveHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJt
IHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZv
ciBhIHN0YXRlZCByZXNvdXJjZSBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwg
T0F1dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2RhdGE9MDElN2MwMSU3
Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0Mzdj
ZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPU1KV3BG
QjEydlRMQjRlY0t5WXdsWkxuUkpJbmFORXcxTXdsdnRVMjZCUEElM2QiIHRhcmdldD0iX2JsYW5r
Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdt
YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KSGkgVGhvbWFzLCZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5pbmxpbmU6Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yMDE2PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90
OyxzYW5zLXNlcmlmIj7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Mjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVv
dDssc2Fucy1zZXJpZiI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIyPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx
dW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KDwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMm
cXVvdDssc2Fucy1zZXJpZiI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPikNCiAxODo0NCBU
aG9tYXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Db3Vs
ZG4ndCB0aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0aGUgbWV0YWRhdGE/PG86cD48L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PkkgcXVpdGUgbGlrZSB0aGUgaWRlYSBvZiZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEg
aWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRpc2NvdmVyeSwgYW5kIGxlYXZlIGl0IG9wZW4gdG8g
aW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3BlY3MgdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJM
IGZvciAmcXVvdDthdXRvLWNvbmZpZ3VyYXRpb24mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
VGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJlIHVzZWQgYXMt
aXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzJm5ic3A7ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0
YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMgZm9yIG90aGVyIG1ldGFkYXRhIHNw
ZWNzIChsaWtlDQogT3BlbklEIENvbm5lY3QpLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp
bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGgmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0
aC1tZXRhJ3MgJnF1b3Q7ZHVyaSZxdW90OyBhbmQgdGhlICZxdW90O3Njb3BlJnF1b3Q7IGF0dHJp
YnV0ZSBvZiBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0
aGluZyB5b3UgbmVlZCB0byBwcm9jZWVkJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPll1cC4g
VGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWwsIGlzIGl0IG5vdD8g
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4g
T0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh
cmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlvdSBuZWVkIGFub3RoZXIg
c3BlY3MgbGlrZSBVTUEuKSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNvLCB0aGUgcmVzb3Vy
Y2Ugc2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIHRlbGwgZWl0aGVyIHRoZSBsb2NhdGlvbiBvZiB0
aGUgYXV0aHogZW5kcG9pbnQuIEluIHNvbWUgdHJ1c3RlZCBlbnZpcm9ubWVudCwgdGhlIHJlc291
cmNlIG1heSBhcyB3ZWxsIHJldHVybiB0aGUgbG9jYXRpb24gb2YgdGhlDQogYXV0aHogc2VydmVy
IGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBk
ZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBk
ZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRj
LiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBh
cyBwb3NzaWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+KHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFj
aCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0
aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2gg
YSBwYXJhbWV0ZXIgc3VjaA0KIHRoYXQgYW4gUlMgY291bGQgcmV0dXJuIHNldmVyYWwgV1dXLUF1
dGhlbnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRzIG93biAmcXVvdDtzY29wZSZxdW90OyBh
bmQgJnF1b3Q7ZHVyaSZxdW90OyB2YWx1ZT8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlllYWgsIEkg
Z3Vlc3MgaXQgaXMgYW4gZWRnZSBjYXNlLiBJIHdvdWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVz
ZSBhdXRoeiBzZXJ2ZXJzIHRvIGRldmVsb3AgYSB0cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2gg
dGhleSBjYW4gYWdyZWUgb24gYSBzaW5nbGUgc2V0IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXIN
CiB2YWx1ZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+Q2hlZXJzLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPk5hdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+T24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMTA6NTkgUE0gSnVzdGluIFJpY2hlciAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNo
ZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBE
aXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBhbmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJl
Y3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxsIGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2Yg
aXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9uZQ0KIGlzc3VlIGluIHBhcnRpY3VsYXIgc3Rp
bGwgcmVhbGx5IGJvdGhlcnMgbWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29wZW5pZC1j
b25maWd1cmF0aW9u4oCdIGluIHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0
aCBkaXNjb3ZlcnkgZG9jdW1lbnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhlcmUgaXMg
YWJzb2x1dGVseSBubyBjb21wZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0aGUgT0lE
QyBkaXNjb3ZlcnkNCiBtZWNoYW5pc20uPGJyPg0KPGJyPg0KSSBwcm9wb3NlIHRoYXQgd2UgdXNl
IOKAnC8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAnSBhcyB0aGUgZGVm
YXVsdCBkaXNjb3ZlcnkgbG9jYXRpb24sIGFuZCBzdGF0ZSB0aGF0IHRoZSBkb2N1bWVudCBNQVkg
YWxzbyBiZSByZWFjaGFibGUgZnJvbSDigJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRp
b27igJ0gaWYgdGhlIHNlcnZlciBhbHNvIHByb3ZpZGVzIE9wZW5JRCBDb25uZWN0IG9uIHRoZSBz
YW1lIGRvbWFpbi4gT3RoZXINCiBhcHBsaWNhdGlvbnMgU0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJh
bWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5kcG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5z
aWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292ZXJ5IGRvY3VtZW50Ljxicj4NCjxicj4N
CiZuYnNwO+KAlCBKdXN0aW48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0
bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1
dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcw
ZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0
NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBK
eHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0
dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh
JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9
MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcw
OGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3Nk
YXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZCIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8
L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz
LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUy
Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1nbzFGaEwlMmJEYTZ5QlNL
bWNzM3dxbDcxQnNrWTdON0VKeDQwcFpQSnh0bDQlM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BY2PR03MB442FCAEAB590BE8090F0B86F5A50BY2PR03MB442namprd_--


From nobody Wed Feb 24 11:17:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E161B3CE3 for ; Wed, 24 Feb 2016 11:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGl4ESwR5xQq for ; Wed, 24 Feb 2016 11:17:00 -0800 (PST)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C371B3C8C for ; Wed, 24 Feb 2016 11:17:00 -0800 (PST)
Received: from mtaout-aal02.mx.aol.com (mtaout-aal02.mx.aol.com [172.27.20.206]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 4CF6B3800065; Wed, 24 Feb 2016 14:16:59 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aal02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AB80F38000091; Wed, 24 Feb 2016 14:16:58 -0500 (EST)
To: Phil Hunt , Nat Sakimura 
References:    
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56CE01B1.7060501@aol.com>
Date: Wed, 24 Feb 2016 14:17:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090508070402050108000503"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456341419; bh=dwPEs9GPaVOU31R0Ztz7yTYRfFCPXljYZhB0AQUQ/3A=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=pplehTuP0zfdCijwmU5bNNWJ2DYfdLdauNjlxtiXKiWQPSLZteqyir/U2SqWLcVvN NvMsJx0vIzDEYDWULfAy6Q+IcFqv7YLLeBn3XO1nN5d+uGqSaL9G5ICBM60sbFHfjB zKdaML7eJ56B3VH4+dD+gPuGezQekp44fb8zCkZU=
x-aol-sid: 3039ac1b14ce56ce01aa43ec
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 19:17:04 -0000

This is a multi-part message in MIME format.
--------------090508070402050108000503
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I'm concerned that forcing the AS to know about all RS's endpoints that 
will accept it's tokens creates a very brittle deployment architecture. 
What if a RS moves to a new endpoint? All clients would be required to 
get new tokens (if I understand correctly). And the RS move would have 
to coordinate with the AS to make sure all the timing is perfect in the 
switch over of endpoints.

I suspect a common deployment architecture today is that each RS 
requires one or more scopes to access it's resources. The client then 
asks the user to authorize a token with a requested list of scopes. The 
client can then send the token to the appropriate RS endpoint. The RS 
will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a 
"bad" RS which will then replay the token, then I'd rather use a PoP 
mechanism because the point is that you want to ensure the correct 
client is presenting the token. Trying to ensure the client doesn't send 
the token to the wrong endpoint seems fraught with problems.

Thanks,
George

On 2/24/16 9:59 AM, Phil Hunt wrote:
> Nat,
>
> I’m not sure that having the resource server tell the client where its 
> authorization server is secure by itself. The relationship between the 
> Authorization Server and the Resource server need to be bound together 
> in one of the discovery endpoints (the resource and/or the oauth 
> service discovery).
>
> If a client discovers a fake resource server that is proxying for a 
> real resource server the current discovery spec will not lead the 
> client to understand it has the wrong resource server. Rather the fake 
> resource service will just have a fake discovery service. The hacker 
> can now intercept resource payload as well as tokens because they were 
> able to convince the client to use the legit authorization service but 
> use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the 
> server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to 
> UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura > > wrote:
>>
>>
>> Hi Thomas,
>>
>> inline:
>>
>> 2016年2月22日(月) 18:44 Thomas Broyer > >:
>>
>>     Couldn't the document only describe the metadata?
>>     I quite like the idea of draft-sakimura-oauth-meta if you really
>>     want to do discovery, and leave it open to implementers / to
>>     other specs to define a .well-known URL for "auto-configuration".
>>     The metadata described here would then either be used as-is, at
>>     any URL, returned as draft-sakimura-oauth-meta metadata at the
>>     RS; or as a basis for other metadata specs (like OpenID Connect).
>>
>>     With draft-sakimura-oauth-meta's "duri" and the "scope" attribute
>>     of WWW-Authenticate response header, you have everything you need
>>     to proceed
>>
>>
>> Yup. That's one of the requirements to be RESTful, is it not?
>>
>> In OAuth's case, the resource and the authorization server are 
>> usually tightly coupled. (Otherwise, you need another specs like UMA.)
>> So, the resource server should be able to tell either the location of 
>> the authz endpoint. In some trusted environment, the resource may as 
>> well return the location of the authz server configuration data. In 
>> these cases, you do not have to decide on what .well-known uri as you 
>> say. This frees up developers from configuration file location 
>> collisions etc. We should strive not to pollute the uri space as much 
>> as possible.
>>
>>     (well, except if there are several ASs each with different
>>     scopes; sounds like an edge-case to me though; maybe RFC6750
>>     should instead be updated with such a parameter such that an RS
>>     could return several WWW-Authenticate: Bearer, each with its own
>>     "scope" and "duri" value?)
>>
>>
>> Yeah, I guess it is an edge case. I would rather like to see these 
>> authz servers to develop a trust framework under which they can agree 
>> on a single set of common scope parameter values.
>>
>> Cheers,
>>
>> Nat
>>
>>
>>
>>     On Fri, Feb 19, 2016 at 10:59 PM Justin Richer >     > wrote:
>>
>>         The newly-trimmed OAuth Discovery document is helpful and
>>         moving in the right direction. It does, however, still have
>>         too many vestiges of its OpenID Connect origins. One issue in
>>         particular still really bothers me: the use of
>>         “/.well-known/openid-configuration†in the discovery portion.
>>         Is this an OAuth discovery document, or an OpenID Connect
>>         one? There is absolutely no compelling reason to tie the URL
>>         to the OIDC discovery mechanism.
>>
>>         I propose that we use
>>         “/.well-known/oauth-authorization-server†as the default
>>         discovery location, and state that the document MAY also be
>>         reachable from “/.well-known/openid-configuration†if the
>>         server also provides OpenID Connect on the same domain. Other
>>         applications SHOULD use the same parameter names to describe
>>         OAuth endpoints and functions inside their service-specific
>>         discovery document.
>>
>>          — Justin
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------090508070402050108000503
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I'm concerned that forcing
      the AS to know about all RS's endpoints that will accept it's
      tokens creates a very brittle deployment architecture. What if a
      RS moves to a new endpoint? All clients would be required to get
      new tokens (if I understand correctly). And the RS move would have
      to coordinate with the AS to make sure all the timing is perfect
      in the switch over of endpoints.

      

      I suspect a common deployment architecture today is that each RS
      requires one or more scopes to access it's resources. The client
      then asks the user to authorize a token with a requested list of
      scopes. The client can then send the token to the appropriate RS
      endpoint. The RS will not authorize access unless the token has
      the required scopes.

      

      If the concern is that the client may accidentally send the token
      to a "bad" RS which will then replay the token, then I'd rather
      use a PoP mechanism because the point is that you want to ensure
      the correct client is presenting the token. Trying to ensure the
      client doesn't send the token to the wrong endpoint seems fraught
      with problems.

      

      Thanks,

      George

    

    
On 2/24/16 9:59 AM, Phil Hunt wrote:

    

    

      
      
Nat,

      


      

      I’m not sure that having the resource server tell the client where
      its authorization server is secure by itself. The relationship
      between the Authorization Server and the Resource server need to
      be bound together in one of the discovery endpoints (the resource
      and/or the oauth service discovery).
      


      

      

        
If a client discovers a fake resource server that
          is proxying for a real resource server the current discovery
          spec will not lead the client to understand it has the wrong
          resource server. Rather the fake resource service will just
          have a fake discovery service. The hacker can now intercept
          resource payload as well as tokens because they were able to
          convince the client to use the legit authorization service but
          use the token against the hackers proxy.

        


        

        
The OAuth Discovery service needs to confirm to
          the client that the server is able to issue tokens for a
          stated resource endpoint.

        


        

        
This not only works in normal OAuth but should add
          security even to UMA situations.

        


          
          

          

            

              
On Feb 24, 2016, at 3:54 AM, Nat Sakimura
                <sakimura@gmail.com>
                wrote:

              

              

                


                  Hi Thomas, 
                  


                  

                  
inline: 

                  


                    

                      
2016年2月22日(月) 18:44 Thomas
                        Broyer <t.broyer@gmail.com>:

                      

                      

                        
Couldn't the document
                          only describe the metadata?
                          
I quite like the idea
                            of draft-sakimura-oauth-meta if you really
                            want to do discovery, and leave it open to
                            implementers / to other specs to define a
                            .well-known URL for "auto-configuration".

                          
The metadata described here
                            would then either be used as-is, at any URL,
                            returned as draft-sakimura-oauth-meta
                            metadata at the RS; or as a basis for other
                            metadata specs (like OpenID Connect). 

                        

                      

                      

                        

                          

                            
With draft-sakimura-oauth-meta's
                              "duri" and the "scope" attribute of
                              WWW-Authenticate response header, you have
                              everything you need to proceed 

                          

                        

                      

                      


                      

                      
Yup. That's one of the requirements
                        to be RESTful, is it not?  

                      


                      

                      
In OAuth's case, the resource and
                        the authorization server are usually tightly
                        coupled. (Otherwise, you need another specs like
                        UMA.) 

                      
So, the resource server should be
                        able to tell either the location of the authz
                        endpoint. In some trusted environment, the
                        resource may as well return the location of the
                        authz server configuration data. In these cases,
                        you do not have to decide on what .well-known
                        uri as you say. This frees up developers from
                        configuration file location collisions etc. We
                        should strive not to pollute the uri space as
                        much as possible. 

                      
 

                      

                        

                          

                            
(well, except if there are
                              several ASs each with different scopes;
                              sounds like an edge-case to me though;
                              maybe RFC6750 should instead be updated
                              with such a parameter such that an RS
                              could return several WWW-Authenticate:
                              Bearer, each with its own "scope" and
                              "duri" value?)

                          

                        

                      

                      


                      

                      
Yeah, I guess it is an edge case. I
                        would rather like to see these authz servers to
                        develop a trust framework under which they can
                        agree on a single set of common scope parameter
                        values. 

                      


                      

                      
Cheers, 

                      


                      

                      
Nat

                      


                      

                      

                        

                          

                            


                              

                              

                                
On Fri, Feb 19,
                                  2016 at 10:59 PM Justin Richer <jricher@mit.edu>
                                  wrote:

                                

                                
The newly-trimmed
                                  OAuth Discovery document is helpful
                                  and moving in the right direction. It
                                  does, however, still have too many
                                  vestiges of its OpenID Connect
                                  origins. One issue in particular still
                                  really bothers me: the use of
                                  “/.well-known/openid-configuration†in
                                  the discovery portion. Is this an
                                  OAuth discovery document, or an OpenID
                                  Connect one? There is absolutely no
                                  compelling reason to tie the URL to
                                  the OIDC discovery mechanism.

                                  

                                  I propose that we use
                                  “/.well-known/oauth-authorization-serverâ€
                                  as the default discovery location, and
                                  state that the document MAY also be
                                  reachable from
                                  “/.well-known/openid-configuration†if
                                  the server also provides OpenID
                                  Connect on the same domain. Other
                                  applications SHOULD use the same
                                  parameter names to describe OAuth
                                  endpoints and functions inside their
                                  service-specific discovery document.

                                  

                                   — Justin

_______________________________________________

                                  OAuth mailing list

                                  OAuth@ietf.org

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

                                

                              

                            

                          

                        

                        _______________________________________________

                        OAuth mailing list

                        OAuth@ietf.org

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

                      

                    

                  

                

                _______________________________________________

                OAuth mailing
                  list

                OAuth@ietf.org

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

            

          

          

        

      

      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------090508070402050108000503--


From nobody Wed Feb 24 12:09:09 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC3E1B2BFF for ; Wed, 24 Feb 2016 12:09:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyfxyVRHkmeI for ; Wed, 24 Feb 2016 12:09:00 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1545D1AD0D7 for ; Wed, 24 Feb 2016 12:08:51 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id a4so5091347wme.1 for ; Wed, 24 Feb 2016 12:08:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cgT/zVHAc/pIzHaJ+Smcsxpgr+WBz7rIh/FWUI+PME4=; b=xEob7rTbYGXGiuasNmU4MyDFqIb6G4szBsDXAOoG+tDnUWW0HT373m1kI0yl9q0QeZ I9Y/qI4O347HpulS1vdQIgoueDzMCLJcf78ecpvEqMAWzx2YtIAg67ykH4L68zkDUjQP 7ZJCQmxBRqJGWYKiYad6W3D5Ai7pkQh8gBZra6pa0/DupLayRPMBcootVdoRu5qGyyTw /w7RdVkfdeIz8/jvNphghzN+yIkcWeN6rFxgaRMxmC9YRVDxJ3Z83kYMJihdj1i3yv6H 2UoVzBLzsJva4CLM2TEbFiX3WS77n5xyp+ehCL8KDJhxAt4XL8gq5qABOsBlTsXV2mdr Zipw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=cgT/zVHAc/pIzHaJ+Smcsxpgr+WBz7rIh/FWUI+PME4=; b=T1hM+6j1I/nrkqFrDlM7g/izsAnWt0nORalihj22ki5sRb95x9iRE4oKj2Mu/sFxFV /ulKNNCPLLtmWq1ErduSlK5VmPvkpXVaCyZomTaolIVaUBKe/uQXfmDD9e+TTclW/Sf2 lhUf1eMxMWK+0zSAn5wloGaGmQqYr9kszpeOKXrTQEVmCprSavv4t3UTgqpvNjzL6LsD cwiWv7onA109o9Oe+3plpfHr7lFl/0eHSKeqZSe8PqsarOmx3iS8hp4D3+r/GEZTVBCl WlA0FvthiBRKU1lh/zuC/CBrB6UbyNMIzsLAUf8NG4b534Mr8PxyKtyNwivslablNr3b lSDA==
X-Gm-Message-State: AG10YOQ/HvM8uCk5YVAnPvcHMsLExUzSz6JErk9mRrwviQJdxSbh6iXLJJ5VS8f/P8Np+A==
X-Received: by 10.194.87.161 with SMTP id az1mr40973794wjb.163.1456344529329;  Wed, 24 Feb 2016 12:08:49 -0800 (PST)
Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id t12sm32747544wmt.20.2016.02.24.12.08.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Feb 2016 12:08:47 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_E724E8D4-599F-49E0-8E73-36E7689272D4"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56CDE997.90704@aol.com>
Date: Wed, 24 Feb 2016 21:08:44 +0100
Message-Id: <9615C66A-7EF1-47B7-B505-89692F62100C@ve7jtb.com>
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com>  <36DCFBB1-F7CC-4EEB-AD73-C9D162AE58FF@ve7jtb.com> <56CDE997.90704@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 20:09:07 -0000

--Apple-Mail=_E724E8D4-599F-49E0-8E73-36E7689272D4
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F27DE0B6-E1D3-496F-A7BD-A69F050CD328"


--Apple-Mail=_F27DE0B6-E1D3-496F-A7BD-A69F050CD328
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think that AT reuse by MITM attacks should be dealt with as a separate =
issue.

There are several possibilities.=20
1) POP tokens (You will recall the Eran wanted them for this reason)
2) The AS telling the client where the token can be used and the client =
comparing the URI (may be multiple)
3) The client telling the AS where it intends to use the token (may be =
multiple)
4) some sort of discovery doc being static version of 2.

I would argue that 1 is the best option.  That supports your use case.   =
Yes it has downsides as far as complexity.

Based on some questions Justin asked me I am trying to work out a way to =
use token binding in a way that may be much simpler than what we =
currently are discussing. (still theoretical work)=20

Having the RS point to the authorization endpoint is problematic without =
POP or full discovery.

Restricting the use of the access tokens has been something we have not =
made any real progress on to this point.

John B.


> On Feb 24, 2016, at 6:34 PM, George Fletcher  wrote:
>=20
>> We still have a problem with AT leaking.   I think that needs to be =
dealt with separately.=20
>> Access tokens should have a audience (by value or by introspection) =
the client needs to tell the AS what resource it want s to use the token =
at and have that included as the audience or the request rejected =
because it is an invalid audience.
> I have some concerns with requiring an audience for AT issuance. Today =
a client can get a token with scopes "instantMessaging readMail sendMail =
readContacts writeContacts" and then use that token against multiple =
endpoints (im.example.com mail.example.com contacts.example.com). This =
is a common usage of OAuth2.=20
>=20
> Forcing the client to get a unique AT for each service it wants to =
talk to is a change from the model that is currently in place.
>=20
> Thanks,
> George
>=20
> On 2/23/16 6:17 PM, John Bradley wrote:
>> The idea of including the state in the PKCE calculation was one I =
think Hans brought up at the meeting in Darmstadt.
>>=20
>> I think we discounted it as not solving the problem because the =
attacker could manipulate the code_challenge.
>>=20
>> As and example the attacker receives the request and changes the =
code_challenge to one it makes up based on the state from a second =
request made to the client in it=E2=80=99s browser.=20
>>=20
>> The attacker can replay the token to the client with the state that =
will validate the code_callenge or use the token directly at the token =
endpoint to get a access token as it would know both the client secret =
and code verifier.
>>=20
>> We moved on to look at another way to validate state by passing it to =
the token endpoint for validation to stop the cut and paste attack.
>>=20
>> In thinking again about William and Nat=E2=80=99s question about why =
not PKCE, I looked at the idea of using PKCE again.
>>=20
>> The problem with using PKCE as it is now is that we made the =
assumption that the attacker could not modify the request.
>>=20
>> That got me trying to think of a way to:
>>  a) stop the attacker from modifying the request (signed request, =
probably too complicated to be generally deployed)
>>  b) allow the client to detect if code_challenge has been modified =
and abort of the request was compromise.
>>=20
>> I realized that you could simply echo back the code_challenge from =
the authorization endpoint and that would allow the client to know if =
code_challenge had been altered in the request, assuming the attacker =
can=E2=80=99t modify the response from the legitimate AS.
>>=20
>> So if we add that step we now have a client where code_challenge =
can=E2=80=99t be altered. =20
>>=20
>> That in it selfs stops the cut and pate attack.  It however still =
allows an attacker to use the code it receives along with the the =
code_verifier and client secret to get a AT and RT from the legitimate =
token endpoint.
>>=20
>> So that is not enough Including state in the hash calculation helps =
against the cut and paste attack but we fixed that by returning =
code_challenge.
>>=20
>> That leaves the other things we were talking about returning from the =
authorization endpoint.
>>=20
>> If we include token_endpoint URI in the hash then any token the =
client requests thinking it is for the attackers token endpoint won=E2=80=99=
t generate the same code_challenge as the AS would based on it=E2=80=99s =
token endpoint.   The attacker would know the code_challenge and the =
real token endpoint URI but would have to generate a collision in the =
lifetime of code to use the code.   This would not be possible based on =
the PKCE analysis.
>>=20
>> Returning the code_challenge and including the token_endpoint URI in =
the hash is the minimum needed for the code flow to stop both cut and =
paste as well  as protect the code from being used if stolen via a =
confused client attack.   It doesn=E2=80=99t stop the theft just the use =
of the token.  So it is mitigating the issue a different way from A and =
B that are trying to stop the attacker from getting the code.
>>=20
>> Given the technique I realized it would be simple enough to also =
include some other paramaters in the hash
>> 1) The authorization endpoint in the hash causing it not to validate =
if the client has been given a bad authorization endpoint so the client =
can modify the request. =20
>> 2) The client_id so that it cannot be tampered with in the request.
>> 3) The state  This is tied to the browser instance for XSRF =
protection.  Including this means it cannot be changed and is another =
protection against cut and paste.
>>=20
>> Including all 4 in the hash may be overkill as they overlap in =
protection.  I however think that not integrity protecting one of the =
values might bite us in the future.
>>=20
>> We could go farther and include scopes or the whole request but that =
gets more complicated than it is worth.  We do have a option for request =
signing already.
>>=20
>> So we almost had this at the Darmstadt meeting but it slipped away.
>>=20
>> This is not stoping the attack it is protecting code.  =20
>>=20
>> I should point out that some of the attacks like man in the middling =
registration can still compromise the client secret, making it possible =
for an attacker to impersonate a client.
>>=20
>> Nat=E2=80=99s option B doesn=E2=80=99t have a solution to that ether =
as far as I can tell.
>>=20
>> I think the only option for that is to have a logical identifier for =
the AS and some sort of discovery check at registration to be certain =
that you are using the correct registration location.
>>=20
>> Option A plus discovery works for that and mitigates confused client =
but not cut and paste.
>>=20
>> We still have a problem with AT leaking.   I think that needs to be =
dealt with separately.=20
>> Access tokens should have a audience (by value or by introspection) =
the client needs to tell the AS what resource it want s to use the token =
at and have that included as the audience or the request rejected =
because it is an invalid audience.
>>=20
>> That should happen at the token endpoint for code.
>> For implicit it would need to be at the authoriation endpoint and the =
audience would need to be echoed back to prevent tampering.
>>=20
>> The AT can also be protected by POP so I think that code and AT =
should be kept separate issues.
>>=20
>> John B.
>>=20
>>=20
>>> On Feb 23, 2016, at 9:59 PM, Roland Hedberg  =
 wrote:
>>>=20
>>> In line !
>>>=20
>>>> 22 feb 2016 kl. 05:08 skrev John Bradley  =
:
>>>>=20
>>>>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura  =
 wrote:
>>>>>=20
>>>>> The risk impact of [case2] is more OAuth specific. The token is =
stolen as the token is going to be sent to a rogue resource, and the =
resource can use that to obtain the resource that was supposed to be =
only available to the proper client.
>>>>>=20
>>>>> The risk impact of [case3] is the most grave among these three. =
Now the attacker can create his own client that impersonates the =
compromised client.
>>>>>=20
>>>>> OAuth-mix-up
>>>>> ---------------------------
>>>>> OAuth-mix-up draft gives one way of addressing [case2] by =
introducing a new concept of =E2=80=9Cissuer=E2=80=9D and =
=E2=80=9Cdiscovery=E2=80=9D to RFC6749. It also returns client_id and =
verifies it in 4.2, but if the BadAS has assigned a same client_id to =
the client, it does not help.
>>>> Client_id are not guaranteed to be unique.  They need to be name =
spaced by the AS.   In OAuth currently we have no name for the AS this =
makes that difficult, the client can use the authorization endpoint URI, =
but that logic may well break in multi tenant situations.   Having a =
clear issuer string makes it easier for the client.
>>> I stumbled over exactly this point when I made my implementation =
follow the Mix-Up draft.
>>> If not discovery is involved I think an AS has to have a name which =
is different from the endpoint URIs.
>>>=20
>>>>> One of the issue with this approach is that the central notion of =
=E2=80=9Cissuer=E2=80=9D is new to the existing servers and clients. The =
verification rule in 4.1 states =E2=80=9CCompare the issuer URL for the =
authorization server that the client received when it registered at the =
authorization server=E2=80=9D, but in most existing pure OAuth cases, =
there is no such thing, so you cannot compare. This means that you would =
have to re-register, and if you are doing that, the per-AS redirect_uri =
seems to be a much simpler solution.
>>>> The client developers I have talked to really hate per AS redirect =
URI as being too awkward for deployments.
>>> I on the other hand found it quite easy to do per AS redirect URIs, =
so it might well be implementation
>>> dependent rather then contextual.
>>>=20
>>>>> Per AS Redirect URI
>>>>> --------------------------------
>>>>> This does not involve wire protocol changes. It just adds =
requirements on the redirect uri. This by far is the simplest solution =
for [case2] (and [case1]), IMHO.
>>>>>=20
>>>>> Again, it is not a general framework for finding out tainted =
communication, so it may have other holes.
>>>> This is probably the hardest for the client developer and for the =
deployer.  Yes it is simplest from a spec point of view.
>>>> We need more developer feedback on this.
>>> As I said above I found this quite simple to implement.
>>>=20
>>>>> (Extended) PKCE
>>>>> ---------------------------------
>>>>> To begin with, it works only with code flow. There has to be =
something else to deal with implicit flow.
>>>>>=20
>>>>> PKCE binds the authorization request/response to the token =
request.
>>>>> If used with a confidential client, it seems to mitigate the =
vulnerability.
>>>>> John points out that it is not the case. I must be missing =
something here=E2=80=A6 but my logic goes like:
>>>>>=20
>>>>>=20
>>>>> 1.     The good client creates code_challenge-v and =
code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + =
code_challenge-v + state to the BadAS Authz EP.
>>>>> 2.     BadAS as a client prepares a code_verifier-b and =
code_challenge-b=3DS256(code_verifer-b).
>>>>> 3.     BadAS redirects to GoodAS with the client_id-v + =
code_challenge-b + state-v.
>>>>> 4.     GoodAS stores the code_challenge-b.
>>>>> 5.     GoodAS returns code-v + state-v to the client=E2=80=99s =
redirect uri.
>>>>> 6.     The client finds the AS from the state and sends code-v + =
code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and =
code_verifer-v is phished.
>>>>>=20
>>>>> Now the attacker tries to use the code-v and code_verifier-v.
>>>>>=20
>>>>> ### Case A:
>>>>> 7.     The BadAS as a client sends client_id-v + =E2=80=A6 but he =
does not have client secret for the good client, so it fails.
>>>>>=20
>>>>> ### Case B:
>>>>> 8.     The BadAS as a client sends client_id-b + code-v + =
code_verifier-b + secret-b etc. to GoodAS.
>>>>> 9.     GoodAS verifies the code_verifier-b is associated with =
code-v, but that code-v is not associated with client_id-b, so the token =
request fails.
>>>>>=20
>>>>> ### Case C: cut-n-paste
>>>>> 10.  The attacker launches cut-n-paste attack by replacing the =
code-b with code-v.
>>>>> 11.  The verifiers does not match, so fails.
>>>>>=20
>>>>> Please let me know what I am missing.
>>>> In a step 0 the attacker has the good client create another request =
in the attackers user agent to get state-0 and code_challange-0
>>>>=20
>>>> Step 2 is not required.
>>>> Step 3 Bad AS redirects to good AS with client_id_v + state-v + =
code_challenge-0
>>>> Step 4 GoodAS stores code_challenge-0
>>>> Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
>>>> Step 6 The client finds the AS from the state and sends code-v + =
code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and =
code_verifer-v is phished.
>>>>=20
>>>> Case C1 :  cut and paste
>>>> 10.  The attacker launches cut-n-paste attack by inserting code-v =
into a response using state-0
>>>> 11. The client sends code-v and based on state-0 it sends =
code_verifyer-0 to the good AS token endpoint.
>>>> 12. The GoodAS verifies that code-verifyer-0 is correct for =
code_challange-0 that it bound to code in step 4
>>>> 13. The GoodAS receives RT + AT.
>>>> 14. The attacker has now used the client to bind the users resource =
to it=E2=80=99s account and is transferring money or looking at your =
data.
>>>>=20
>>>> This could be 3rd party financial app like Mint as an example or =
photos or any other PII that could then be used to escalate identity =
theft.
>>>>=20
>>>> This variation of the attack combining cut and paste with confused =
client was not mentioned in the research papers.
>>>>=20
>>>> I found it looking to see if PKCE could be used to mitigate the =
confused client attack.
>>>>=20
>>>> As I mentioned in a response to William, while the current PKCE =
Challenge methods only make the attack harder by forcing the attacker to =
get the client to make a step 0 request to get a code_challenge to use =
in the request,  we could define a new challenge method that would be =
effective.
>>>>=20
>>>> That would remove the need to have a separate mechanism to prevent =
cut and paste.
>>>>=20
>>>> The problem is that the PKCE challenge is independent of state so =
becomes vulnerable to the confused client.
>>>>=20
>>>> What we would need to do is include state in the challenge so that =
if the AS receives mismatched state and code_challange in step 3 the =
verification of code verifier will fail. Effectively combining the cut =
and paste mitigation with PKCE.
>>>>=20
>>>> I haven=E2=80=99t had time to write this up, but if the =
code_challenge =3D=3D SHA256 (SHA256(state) || token_endpoint URI || =
Authorization_endpoint URI || client_id || code-veriyer) ,  then the =
attacker could not change state, client_id, or token_endpoint  =
independently of code_challenge.  (note I am using a hash of state to =
make storage size deterministic for the AS on the grounds that the =
client already needs to be able to do the hash) (Some attacks  change =
the client_id in the request so I am including it in the hash)
>>>>=20
>>>> This is slightly more complicated than than S256, but not that =
much.  I wish I had thought of this when we were doing PKCE.   Hit me =
with the stupid stick, my fault.
>>>>=20
>>>> I don=E2=80=99t know if it stops all the confused client attacks =
though.
>>>>=20
>>>> If the client is confidential then it gives up it=E2=80=99s client =
secret assuming compromised registration, so we can=E2=80=99t really =
count on that for symmetric client authentication.
>>>>=20
>>>> By including the token endpoint in the comparison if the client is =
sending the code to the attacker the client will use a different token =
endpoint_uri in to calculate the code_challenge than the GoodAS will use =
to verify it.    This would stop both cut and paste as well as stopping =
the attacker from using the code if they get it.   The attacker can=E2=80=99=
t get Secret for state-0, so it can=E2=80=99t create code_challenge that =
would be valid.
>>>>=20
>>>> This stops the registration attack where the client gets a bad AS =
discovery endpoint that has all the Good AS info including dynamic =
registration endpoint but the bad AS token endpoint.   The bad AS would =
get the token, client_secret and code_verier, but will fail pkce =
verification because the token endpoint will be wrong.
>>>>=20
>>>> The attack where the client registers with the good AS but with bad =
token endpoint and Authorization endpoint gives the attacker the ability =
to change the code_challenge that the Good AS is going to see.   It =
would need to make a new challenge using state and the GoodAS token =
endpoint and it=E2=80=99s client_id.
>>>> To do that it needs the code_verifier to use to calculate the hash =
to use as the code_challenge value.  As long as the client is not =
tricked into accepting a replay of the authentication response we should =
be safe.  The client would need to do replay protection on the =
code_verifier values before it makes a request to the token endpoint.
>>>>=20
>>>> The BadAS could however make up a new code_challenge and =
code_verifier and use that in the request. For this one the AS would =
need to do pull discovery on the client to get a key, or the AS needs to =
return something in the response.  This attack can completely proxy all =
the endpoints as far as the client is concerned and is taking advantage =
of the AS saying you are granting permission to site X based on the =
redirect URI.
>>>>=20
>>>> I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a =
client from being used as a redirector back to the attacker unless you =
also returned the code_challenge in the response from the authorization =
endpoint.
>>>>=20
>>>> Hypothetically if we returned code_challenge in the response from =
the authorization endpoint and have a new PKCE challenge method we might =
find it covers all of the attacks.
>>>>=20
>>>> We would need to put some serious analysis into this to see if it =
really covers all the attacks.
>>>>=20
>>>> It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D =
response_type or steeling the access token by impersonating the RS.
>>>>=20
>>>> I think the correct way to stop the problem with access tokens is =
by audience restricting them.
>>>> To do that the client needs to provide an audience in it=E2=80=99s =
request and the AS needs to include that in the AT.
>>>>=20
>>>> I included the Authorization_endpoint URI in the hash to detect if =
the auth request may have been tampered with to change the audience for =
the AT.
>>>>=20
>>>> For implicit we could have a version of PKCE where the AS returns a =
parameter with S256( client_id || authorization_endpoint URI || resource =
endpoint URI) to verify the request was not tampered with, and that =
would allow the AT to be properly audience restricted.
>>>>=20
>>>>=20
>>>> This would be a completely new approach not involving discovery, =
logical names for AS, or link relations.
>>>>=20
>>>> Effectively this code_challenge method becomes a signature over =
parts of the request and the implicit audience of the token_endpoint =
URI.
>>>>=20
>>>> People keep asking why PKCE doesn=E2=80=99t stop these attacks, and =
it won=E2=80=99t with the current PKCE methods,  however a new method =
along the lines I sketched out may let it work, or I could be completely =
wrong.
>>> Once you have written down something more definite I promise to =
implement it promptly such that we can do interop
>>> testing early in the process.
>>>=20
>>> Before John brought up this new PKCE mode I was on the Option A side =
of the fence now I=E2=80=99d like to see more
>>> of this PKCE idea before committing to one or the other.
>>>=20
>>> =E2=80=94 Roland
>>>=20
>>> =E2=80=9DEverybody should be quiet near a little stream and listen."
>>> =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 


--Apple-Mail=_F27DE0B6-E1D3-496F-A7BD-A69F050CD328
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I think that AT reuse by MITM attacks should be dealt with as =
a separate issue.

There are several possibilities. 
1) =
POP tokens (You will recall the Eran wanted them for this =
reason)
2) The AS telling the client where the =
token can be used and the client comparing the URI (may be =
multiple)
3) The client telling the AS where it =
intends to use the token (may be multiple)
4) some =
sort of discovery doc being static version of 2.

I would argue that 1 is the best =
option.  That supports your use case.   Yes it has downsides =
as far as complexity.

Based on some questions Justin asked me I am trying to work =
out a way to use token binding in a way that may be much simpler than =
what we currently are discussing. (still theoretical =
work) 

Having the RS point to the authorization endpoint is =
problematic without POP or full discovery.

Restricting the use of the access =
tokens has been something we have not made any real progress on to this =
point.

John =
B.


On Feb 24, 2016, at 6:34 PM, George Fletcher =
<gffletch@aol.com> wrote:


 =20
    
 =20
  

    

      
We still have a problem with AT leaking. =
  I think that needs to be dealt with separately.=20
Access tokens should have a audience (by value or by introspection) the =
client needs to tell the AS what resource it want s to use the token at =
and have that included as the audience or the request rejected because =
it is an invalid audience.

    

    I have some concerns with requiring an audience for AT issuance.
    Today a client can get a token with scopes "instantMessaging
    readMail sendMail readContacts writeContacts" and then use that
    token against multiple endpoints (im.example.com mail.example.com
    contacts.example.com). This is a common usage of OAuth2. =


    

    Forcing the client to get a unique AT for each service it wants to
    talk to is a change from the model that is currently in place.

    

    Thanks,

    George

    

    
On 2/23/16 6:17 PM, John Bradley =
wrote:

    

    

      
The idea of including the state in the =
PKCE calculation was one I think Hans brought up at the meeting in =
Darmstadt.

I think we discounted it as not solving the problem because the attacker =
could manipulate the code_challenge.

As and example the attacker receives the request and changes the =
code_challenge to one it makes up based on the state from a second =
request made to the client in it=E2=80=99s browser.=20

The attacker can replay the token to the client with the state that will =
validate the code_callenge or use the token directly at the token =
endpoint to get a access token as it would know both the client secret =
and code verifier.

We moved on to look at another way to validate state by passing it to =
the token endpoint for validation to stop the cut and paste attack.

In thinking again about William and Nat=E2=80=99s question about why not =
PKCE, I looked at the idea of using PKCE again.

The problem with using PKCE as it is now is that we made the assumption =
that the attacker could not modify the request.

That got me trying to think of a way to:
 a) stop the attacker from modifying the request (signed request, =
probably too complicated to be generally deployed)
 b) allow the client to detect if code_challenge has been modified and =
abort of the request was compromise.

I realized that you could simply echo back the code_challenge from the =
authorization endpoint and that would allow the client to know if =
code_challenge had been altered in the request, assuming the attacker =
can=E2=80=99t modify the response from the legitimate AS.

So if we add that step we now have a client where code_challenge can=E2=80=
=99t be altered. =20

That in it selfs stops the cut and pate attack.  It however still allows =
an attacker to use the code it receives along with the the code_verifier =
and client secret to get a AT and RT from the legitimate token endpoint.

So that is not enough Including state in the hash calculation helps =
against the cut and paste attack but we fixed that by returning =
code_challenge.

That leaves the other things we were talking about returning from the =
authorization endpoint.

If we include token_endpoint URI in the hash then any token the client =
requests thinking it is for the attackers token endpoint won=E2=80=99t =
generate the same code_challenge as the AS would based on it=E2=80=99s =
token endpoint.   The attacker would know the code_challenge and the =
real token endpoint URI but would have to generate a collision in the =
lifetime of code to use the code.   This would not be possible based on =
the PKCE analysis.

Returning the code_challenge and including the token_endpoint URI in the =
hash is the minimum needed for the code flow to stop both cut and paste =
as well  as protect the code from being used if stolen via a confused =
client attack.   It doesn=E2=80=99t stop the theft just the use of the =
token.  So it is mitigating the issue a different way from A and B that =
are trying to stop the attacker from getting the code.

Given the technique I realized it would be simple enough to also include =
some other paramaters in the hash
1) The authorization endpoint in the hash causing it not to validate if =
the client has been given a bad authorization endpoint so the client can =
modify the request. =20
2) The client_id so that it cannot be tampered with in the request.
3) The state  This is tied to the browser instance for XSRF protection.  =
Including this means it cannot be changed and is another protection =
against cut and paste.

Including all 4 in the hash may be overkill as they overlap in =
protection.  I however think that not integrity protecting one of the =
values might bite us in the future.

We could go farther and include scopes or the whole request but that =
gets more complicated than it is worth.  We do have a option for request =
signing already.

So we almost had this at the Darmstadt meeting but it slipped away.

This is not stoping the attack it is protecting code.  =20

I should point out that some of the attacks like man in the middling =
registration can still compromise the client secret, making it possible =
for an attacker to impersonate a client.

Nat=E2=80=99s option B doesn=E2=80=99t have a solution to that ether as =
far as I can tell.

I think the only option for that is to have a logical identifier for the =
AS and some sort of discovery check at registration to be certain that =
you are using the correct registration location.

Option A plus discovery works for that and mitigates confused client but =
not cut and paste.

We still have a problem with AT leaking.   I think that needs to be =
dealt with separately.=20
Access tokens should have a audience (by value or by introspection) the =
client needs to tell the AS what resource it want s to use the token at =
and have that included as the audience or the request rejected because =
it is an invalid audience.

That should happen at the token endpoint for code.
For implicit it would need to be at the authoriation endpoint and the =
audience would need to be echoed back to prevent tampering.

The AT can also be protected by POP so I think that code and AT should =
be kept separate issues.

John B.




      

        
On Feb 23, 2016, at 9:59 PM, Roland =
Hedberg <roland.hedberg@umu.se> =
wrote:

In line !



        

          
22 feb 2016 kl. 05:08 skrev John =
Bradley <ve7jtb@ve7jtb.com>:



          

            
On Feb 22, 2016, at 9:22 AM, Nat =
Sakimura <n-sakimura@nri.co.jp> =
wrote:

The risk impact of [case2] is more OAuth specific. The token is stolen =
as the token is going to be sent to a rogue resource, and the resource =
can use that to obtain the resource that was supposed to be only =
available to the proper client.

The risk impact of [case3] is the most grave among these three. Now the =
attacker can create his own client that impersonates the compromised =
client.

OAuth-mix-up
---------------------------
OAuth-mix-up draft gives one way of addressing [case2] by introducing a =
new concept of =E2=80=9Cissuer=E2=80=9D and =E2=80=9Cdiscovery=E2=80=9D =
to RFC6749. It also returns client_id and verifies it in 4.2, but if the =
BadAS has assigned a same client_id to the client, it does not help.


          

          
Client_id are not guaranteed to be =
unique.  They need to be name spaced by the AS.   In OAuth currently we =
have no name for the AS this makes that difficult, the client can use =
the authorization endpoint URI, but that logic may well break in multi =
tenant situations.   Having a clear issuer string makes it easier for =
the client.


        

        
I stumbled over exactly this point =
when I made my implementation follow the Mix-Up draft.
If not discovery is involved I think an AS has to have a name which is =
different from the endpoint URIs.



        

          

            
One of the issue with this =
approach is that the central notion of =E2=80=9Cissuer=E2=80=9D is new =
to the existing servers and clients. The verification rule in 4.1 states =
=E2=80=9CCompare the issuer URL for the authorization server that the =
client received when it registered at the authorization server=E2=80=9D, =
but in most existing pure OAuth cases, there is no such thing, so you =
cannot compare. This means that you would have to re-register, and if =
you are doing that, the per-AS redirect_uri seems to be a much simpler =
solution.


          

          
The client developers I have talked =
to really hate per AS redirect URI as being too awkward for deployments.


        

        
I on the other hand found it quite =
easy to do per AS redirect URIs, so it might well be implementation
dependent rather then contextual.



        

          

            
Per AS Redirect URI
--------------------------------
This does not involve wire protocol changes. It just adds requirements =
on the redirect uri. This by far is the simplest solution for [case2] =
(and [case1]), IMHO.

Again, it is not a general framework for finding out tainted =
communication, so it may have other holes.


          

          
This is probably the hardest for the =
client developer and for the deployer.  Yes it is simplest from a spec =
point of view.
We need more developer feedback on this.


        

        
As I said above I found this quite =
simple to implement.



        

          

            
(Extended) PKCE
---------------------------------
To begin with, it works only with code flow. There has to be something =
else to deal with implicit flow.

PKCE binds the authorization request/response to the token request.
If used with a confidential client, it seems to mitigate the =
vulnerability.
John points out that it is not the case. I must be missing something =
here=E2=80=A6 but my logic goes like:


1.     The good client creates code_challenge-v and =
code_verifier-v=3DS256(code_challenge-v) and sends the client_id-v + =
code_challenge-v + state to the BadAS Authz EP.
2.     BadAS as a client prepares a code_verifier-b and =
code_challenge-b=3DS256(code_verifer-b).
3.     BadAS redirects to GoodAS with the client_id-v + code_challenge-b =
+ state-v.
4.     GoodAS stores the code_challenge-b.
5.     GoodAS returns code-v + state-v to the client=E2=80=99s redirect =
uri.
6.     The client finds the AS from the state and sends code-v + =
code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and =
code_verifer-v is phished.

Now the attacker tries to use the code-v and code_verifier-v.

### Case A:
7.     The BadAS as a client sends client_id-v + =E2=80=A6 but he does =
not have client secret for the good client, so it fails.

### Case B:
8.     The BadAS as a client sends client_id-b + code-v + =
code_verifier-b + secret-b etc. to GoodAS.
9.     GoodAS verifies the code_verifier-b is associated with code-v, =
but that code-v is not associated with client_id-b, so the token request =
fails.

### Case C: cut-n-paste
10.  The attacker launches cut-n-paste attack by replacing the code-b =
with code-v.
11.  The verifiers does not match, so fails.

Please let me know what I am missing.


          

          
In a step 0 the attacker has the =
good client create another request in the attackers user agent to get =
state-0 and code_challange-0

Step 2 is not required.
Step 3 Bad AS redirects to good AS with client_id_v + state-v + =
code_challenge-0
Step 4 GoodAS stores code_challenge-0
Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
Step 6 The client finds the AS from the state and sends code-v + =
code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and =
code_verifer-v is phished.

Case C1 :  cut and paste
10.  The attacker launches cut-n-paste attack by inserting code-v into a =
response using state-0
11. The client sends code-v and based on state-0 it sends =
code_verifyer-0 to the good AS token endpoint.
12. The GoodAS verifies that code-verifyer-0 is correct for =
code_challange-0 that it bound to code in step 4
13. The GoodAS receives RT + AT.
14. The attacker has now used the client to bind the users resource to =
it=E2=80=99s account and is transferring money or looking at your data.

This could be 3rd party financial app like Mint as an example or photos =
or any other PII that could then be used to escalate identity theft.

This variation of the attack combining cut and paste with confused =
client was not mentioned in the research papers.

I found it looking to see if PKCE could be used to mitigate the confused =
client attack.

As I mentioned in a response to William, while the current PKCE =
Challenge methods only make the attack harder by forcing the attacker to =
get the client to make a step 0 request to get a code_challenge to use =
in the request,  we could define a new challenge method that would be =
effective.

That would remove the need to have a separate mechanism to prevent cut =
and paste.

The problem is that the PKCE challenge is independent of state so =
becomes vulnerable to the confused client.

What we would need to do is include state in the challenge so that if =
the AS receives mismatched state and code_challange in step 3 the =
verification of code verifier will fail. Effectively combining the cut =
and paste mitigation with PKCE.

I haven=E2=80=99t had time to write this up, but if the code_challenge =
=3D=3D SHA256 (SHA256(state) || token_endpoint URI || =
Authorization_endpoint URI || client_id || code-veriyer) ,  then the =
attacker could not change state, client_id, or token_endpoint  =
independently of code_challenge.  (note I am using a hash of state to =
make storage size deterministic for the AS on the grounds that the =
client already needs to be able to do the hash) (Some attacks  change =
the client_id in the request so I am including it in the hash)

This is slightly more complicated than than S256, but not that much.  I =
wish I had thought of this when we were doing PKCE.   Hit me with the =
stupid stick, my fault.

I don=E2=80=99t know if it stops all the confused client attacks though.

If the client is confidential then it gives up it=E2=80=99s client =
secret assuming compromised registration, so we can=E2=80=99t really =
count on that for symmetric client authentication.

By including the token endpoint in the comparison if the client is =
sending the code to the attacker the client will use a different token =
endpoint_uri in to calculate the code_challenge than the GoodAS will use =
to verify it.    This would stop both cut and paste as well as stopping =
the attacker from using the code if they get it.   The attacker can=E2=80=99=
t get Secret for state-0, so it can=E2=80=99t create code_challenge that =
would be valid.

This stops the registration attack where the client gets a bad AS =
discovery endpoint that has all the Good AS info including dynamic =
registration endpoint but the bad AS token endpoint.   The bad AS would =
get the token, client_secret and code_verier, but will fail pkce =
verification because the token endpoint will be wrong.

The attack where the client registers with the good AS but with bad =
token endpoint and Authorization endpoint gives the attacker the ability =
to change the code_challenge that the Good AS is going to see.   It =
would need to make a new challenge using state and the GoodAS token =
endpoint and it=E2=80=99s client_id.
To do that it needs the code_verifier to use to calculate the hash to =
use as the code_challenge value.  As long as the client is not tricked =
into accepting a replay of the authentication response we should be =
safe.  The client would need to do replay protection on the =
code_verifier values before it makes a request to the token endpoint.

The BadAS could however make up a new code_challenge and code_verifier =
and use that in the request. For this one the AS would need to do pull =
discovery on the client to get a key, or the AS needs to return =
something in the response.  This attack can completely proxy all the =
endpoints as far as the client is concerned and is taking advantage of =
the AS saying you are granting permission to site X based on the =
redirect URI.

I can=E2=80=99t see PKCE on it=E2=80=99s own being able to stop a client =
from being used as a redirector back to the attacker unless you also =
returned the code_challenge in the response from the authorization =
endpoint.

Hypothetically if we returned code_challenge in the response from the =
authorization endpoint and have a new PKCE challenge method we might =
find it covers all of the attacks.

We would need to put some serious analysis into this to see if it really =
covers all the attacks.

It however doesn=E2=80=99t address the =E2=80=9Ctoken=E2=80=9D =
response_type or steeling the access token by impersonating the RS.

I think the correct way to stop the problem with access tokens is by =
audience restricting them.
To do that the client needs to provide an audience in it=E2=80=99s =
request and the AS needs to include that in the AT.

I included the Authorization_endpoint URI in the hash to detect if the =
auth request may have been tampered with to change the audience for the =
AT.

For implicit we could have a version of PKCE where the AS returns a =
parameter with S256( client_id || authorization_endpoint URI || resource =
endpoint URI) to verify the request was not tampered with, and that =
would allow the AT to be properly audience restricted.


This would be a completely new approach not involving discovery, logical =
names for AS, or link relations.

Effectively this code_challenge method becomes a signature over parts of =
the request and the implicit audience of the token_endpoint URI.

People keep asking why PKCE doesn=E2=80=99t stop these attacks, and it =
won=E2=80=99t with the current PKCE methods,  however a new method along =
the lines I sketched out may let it work, or I could be completely =
wrong.


        

        
Once you have written down something =
more definite I promise to implement it promptly such that we can do =
interop
testing early in the process.

Before John brought up this new PKCE mode I was on the Option A side of =
the fence now I=E2=80=99d like to see more
of this PKCE idea before committing to one or the other.

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss



      

      

      

      

      

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


    

    

    
--=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


  




=

--Apple-Mail=_F27DE0B6-E1D3-496F-A7BD-A69F050CD328--

--Apple-Mail=_E724E8D4-599F-49E0-8E73-36E7689272D4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAyMjQyMDA4NDVaMCMGCSqGSIb3DQEJBDEWBBQy3CCcqgRinOAz+kBWUMyx
Zp0vNzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQA9D7fb7LEZsSzxN06M/DENUBIU9ygoV57zsvyX82YL7ev/mqStxLXW
kUpwfbl2Qcq2SpP28uOtBS8NXBfk76pL6MKvHt7GWfxcNu5Z0ZW715v2Tx7kSuaulfoIctzcWlPT
G8VIbuT7yDO8gWN6tCmTboMz8o+MCClUZOvLhXLSs2pGChyAAZ2iTyYEfebW6QmJrRjPZ7/Nqe+e
2R4zbS2UVyJxYzhKSj6xbYokujkGTT9XCtckYPo77OZavall8lwAlHZXr6yt6KY8QfnPx8TWf2qV
Ht2W0ljyGIGtRdJDiH4LxJHdMSjh90OgPiIHEkJTIkihIOhjp78PqyiWRCHfAAAAAAAA
--Apple-Mail=_E724E8D4-599F-49E0-8E73-36E7689272D4--


From nobody Wed Feb 24 12:46:09 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1CF1B4034 for ; Wed, 24 Feb 2016 12:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEJFyWAIE4qu for ; Wed, 24 Feb 2016 12:46:03 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C325B1B4046 for ; Wed, 24 Feb 2016 12:45:21 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1OKjKMp009768 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 20:45:20 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1OKjJ54007183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 20:45:20 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1OKjJZt023018; Wed, 24 Feb 2016 20:45:19 GMT
Received: from [25.173.73.160] (/24.114.27.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 12:45:18 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-1C627253-13CB-49DF-A69C-504F3CEB6868
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Wed, 24 Feb 2016 12:45:13 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>
References:          
To: Anthony Nadalin 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 20:46:08 -0000

--Apple-Mail-1C627253-13CB-49DF-A69C-504F3CEB6868
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mike

Publishing on dev pages does not work for software (esp open source) that is=
 deployed both in enterprises and on PaaS cloud providers.=20

The current draft is may codify current OIDC practice and be appropriate for=
 oidc but it is not ready for generic oauth. There is no generic oauth exper=
ience at this time.=20

Phil

> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
>=20
> Sure there is, it is as you have now made it far easier and the security c=
onsiderations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective security=
 difference between discovery information being published in an ad-hoc fashi=
on on developer pages and it being published in a standard format.  =E2=80=9C=
Security by obscurity=E2=80=9D adds no real security at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> > The point of the WGLC is to finish standardizing the core discovery func=
tionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for OAuth. Th=
ere are some authentication mechanism discovery for endpoint that really sho=
uld not be in an OAuth standard since it=E2=80=99s really not dealt with. No=
w that all this information is available it makes poking around the endpoint=
 more focused for people that want to disrupt your endpoints, that is really=
 not addressed in the security considerations section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery functi=
onality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related functional=
ity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applicatio=
ns will use WebFinger to locate the discovery metadata.  Some will possibly u=
se link headers.  Some will possibly use application-specific .well-known va=
lues.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even t=
hought about.  All of these depend upon having a discovery metadata document=
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.
> =20
> So by all means, the working group should continue discussing inventing po=
ssible new related mechanisms that make sense in some contexts.  At the same=
 time, we can finish standardizing the already widely deployed core function=
ality that all of these mechanisms will need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the client i=
ndicating what resource endpoint it wants the oauth configuration data for.=20=

> =20
> So if res.example.evil.com is not a valid resource endpoint for as.example=
.com the authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change the o=
rder of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of authorizati=
on (the resource) is never specified. It is often bound up in the client reg=
istration and an often implied 1:1 relationship between resource and as. Giv=
en that in discovery phase registration has not yet occurred it seems import=
ant that the client know it has a valid combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a starting p=
oint for group adoption but we haven't really defined the full requirements I=
MO.=20
> =20
> I am on vacation or I would put some thought into some draft changes or a n=
ew draft. I apologize I can't do it now.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>=20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? Curren=
tly, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good RS, t=
he client will not send the token there as the authz server will say that is=
 not the place the client may want to send the token to.=20
>=20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client where=
 its authorization server is secure by itself. The relationship between the A=
uthorization Server and the Resource server need to be bound together in one=
 of the discovery endpoints (the resource and/or the oauth service discovery=
).
> =20
> If a client discovers a fake resource server that is proxying for a real r=
esource server the current discovery spec will not lead the client to unders=
tand it has the wrong resource server. Rather the fake resource service will=
 just have a fake discovery service. The hacker can now intercept resource p=
ayload as well as tokens because they were able to convince the client to us=
e the legit authorization service but use the token against the hackers prox=
y.
> =20
> The OAuth Discovery service needs to confirm to the client that the server=
 is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to UMA si=
tuations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> =20
> =20
> =20
>=20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
> =20
>=20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to d=
o discovery, and leave it open to implementers / to other specs to define a .=
well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, r=
eturned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for o=
ther metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-A=
uthenticate response header, you have everything you need to proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually tig=
htly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of the a=
uthz endpoint. In some trusted environment, the resource may as well return t=
he location of the authz server configuration data. In these cases, you do n=
ot have to decide on what .well-known uri as you say. This frees up develope=
rs from configuration file location collisions etc. We should strive not to p=
ollute the uri space as much as possible.=20
> =20
> (well, except if there are several ASs each with different scopes; sounds l=
ike an edge-case to me though; maybe RFC6750 should instead be updated with s=
uch a parameter such that an RS could return several WWW-Authenticate: Beare=
r, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these authz s=
ervers to develop a trust framework under which they can agree on a single s=
et of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
>=20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the ri=
ght direction. It does, however, still have too many vestiges of its OpenID C=
onnect origins. One issue in particular still really bothers me: the use of =E2=
=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery portion. I=
s this an OAuth discovery document, or an OpenID Connect one? There is absol=
utely no compelling reason to tie the URL to the OIDC discovery mechanism.
>=20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other applications SH=
OULD use the same parameter names to describe OAuth endpoints and functions i=
nside their service-specific discovery document.
>=20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-1C627253-13CB-49DF-A69C-504F3CEB6868
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Mike

Publishing on dev pages does not=
 work for software (esp open source) that is deployed both in enterprises an=
d on PaaS cloud providers. 

The current draft is may codify current OI=
DC practice and be appropriate for oidc but it is not ready for generic oaut=
h. There is no generic oauth experience at this time. 

Phil

On Feb 24, 2016, at 10:25, Anthon=
y Nadalin <tonynad@microsoft.com=
> wrote:











Sure there is, it is as you have now ma=
de it far easier and the security considerations does not even address this<=
o:p>


 =








From: Mike Jones


Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


As we=E2=80=99d discussed in person, th=
ere=E2=80=99s no effective security difference between discovery information=
 being published in an ad-hoc fashion on developer pages and
 it being published in a standard format.  =E2=80=9CSecurity by obscuri=
ty=E2=80=9D adds no real security at all.


 


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


 






From: Anthony Nadalin


Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <Mic=
hael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


> The point of t=
he WGLC is to finish standardizing the core discovery functionality
 that=E2=80=99s already widely deployed.


 


That may be widely deployed for OIDC bu=
t not widely deployed for OAuth. There are some authentication mechanism dis=
covery for endpoint that really should not
 be in an OAuth standard since it=E2=80=99s really not dealt with. Now that a=
ll this information is available it makes poking around the endpoint more fo=
cused for people that want to disrupt your endpoints, that is really not add=
ressed in the security considerations
 section at all 


 






From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <phil.=
hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 


The point of the WGLC is to finish stan=
dardizing the core discovery functionality that=E2=80=99s already widely dep=
loyed.


 


None of Nat or John or I are suggesting=
 that additional related functionality won=E2=80=99t be created.  I=E2=80=
=99m sure it will be.  Some applications will use WebFinger to
 locate the discovery metadata.  Some will possibly use link headers.&n=
bsp; Some will possibly use application-specific .well-known values.  I=
=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even thought a=
bout.  All of these depend upon having a discovery metadata document
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.


 


So by all means, the working group shou=
ld continue discussing inventing possible new related mechanisms that make s=
ense in some contexts.  At the same time, we
 can finish standardizing the already widely deployed core functionality tha=
t all of these mechanisms will need.


 


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


 






From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <sakimura@g=
mail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




I am suggesting that part of the discovery solution h=
as to be the client indicating what resource endpoint it wants the oauth con=
figuration data for. 






 






So if 
res.example.evil.com is not a valid resource endpoint for 
as.example.com the authz discovery should fail in some way (eg return no=
thing). 






 






There may be better ways to do this. Eg combine disco=
very. Or change the order of discovery. 






 






One of OAuth's strength's and weaknesses is that the t=
arget of authorization (the resource) is never specified. It is often bound u=
p in the client registration and an often implied 1:1 relationship between r=
esource and as. Given that in
 discovery phase registration has not yet occurred it seems important that t=
he client know it has a valid combination of endpoints etc. =







 






This is why I was disappointed about wglc on discover=
y. We had a starting point for group adoption but we haven't really defined t=
he full requirements IMO. 






 






I am on vacation or I would put some thought into som=
e draft changes or a new draft. I apologize I can't do it now. 



Phil








On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:










Hi Phil, 




 






Are you suggesting that the AS metadata should includ=
e the RS URIs? Currently, it does not, but it can be done, I guess. 






 






The way oauth-meta works is that 
=






 






1. RS tells the client where the AS is. 






2. AS tells the client which RS endpoints the token c=
an be used. 






 






Even if there is a bad AS with a valid certs that pro=
xies to the good RS, the client will not send the token there as the authz s=
erver will say that is not the place the client may want to send the token t=
o. 










Nat






 






2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4=
) 23:59 Phil Hunt <phil.hu=
nt@oracle.com>:










Nat,






 




I=E2=80=99m not sure that having the resource server t=
ell the client where its authorization server is secure by itself. The relat=
ionship between the Authorization Server and the Resource server need to be b=
ound together in one of the discovery
 endpoints (the resource and/or the oauth service discovery).
=




 








If a client discovers a fake resource server that is p=
roxying for a real resource server the current discovery spec will not lead t=
he client to understand it has the wrong resource server. Rather the fake re=
source service will just have
 a fake discovery service. The hacker can now intercept resource payload as w=
ell as tokens because they were able to convince the client to use the legit=
 authorization service but use the token against the hackers proxy.






 






The OAuth Discovery service needs to confirm to the c=
lient that the server is able to issue tokens for a stated resource endpoint=
.






 






This not only works in normal OAuth but should add se=
curity even to UMA situations.






 


















Phil





 <=
/p>





@independentid=












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





 <=
/p>





 <=
/p>



 
















 








On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> w=
rote:




 








Hi Thomas, 




 






inline: 






 






2016=E5=B9=B42=E6=9C=
=8822=E6=97=A5(=E6=9C=88)
 18:44 Thomas Broyer <t.broyer@gmail.com>:








Couldn't the document only describe the metadata?




I quite like the idea of draft-sakimura-oauth-m=
eta if you really want to do discovery, and leave it open to implementers / t=
o other specs to define a .well-known URL for "auto-configuration".






The metadata described here would then either be use=
d as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at t=
he RS; or as a basis for other metadata specs (like
 OpenID Connect). 
















With draft-sakimura-oauth-meta's "duri" and the=
 "scope" attribute of WWW-Authenticate response header, you have everything y=
ou need to proceed 












 






Yup. That's one of the requirements to be RESTful, i=
s it not?  






 






In OAuth's case, the resource and the authorization s=
erver are usually tightly coupled. (Otherwise, you need another specs like U=
MA.) 






So, the resource server should be able to tell eithe=
r the location of the authz endpoint. In some trusted environment, the resou=
rce may as well return the location of the
 authz server configuration data. In these cases, you do not have to decide o=
n what .well-known uri as you say. This frees up developers from configurati=
on file location collisions etc. We should strive not to pollute the uri spa=
ce as much as possible. 






 












(well, except if there are several ASs each with dif=
ferent scopes; sounds like an edge-case to me though; maybe RFC6750 should i=
nstead be updated with such a parameter such
 that an RS could return several WWW-Authenticate: Bearer, each with its own=
 "scope" and "duri" value?)












 






Yeah, I guess it is an edge case. I would rather lik=
e to see these authz servers to develop a trust framework under which they c=
an agree on a single set of common scope parameter
 values. 






 






Cheers, 






 






Nat






 












 






On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu> w=
rote:






The newly-trimmed OAuth Discovery document is helpfu=
l and moving in the right direction. It does, however, still have too many v=
estiges of its OpenID Connect origins. One
 issue in particular still really bothers me: the use of =E2=80=9C/.well-kno=
wn/openid-configuration=E2=80=9D in the discovery portion. Is this an OAuth d=
iscovery document, or an OpenID Connect one? There is absolutely no compelli=
ng reason to tie the URL to the OIDC discovery
 mechanism.



I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other
 applications SHOULD use the same parameter names to describe OAuth endpoint=
s and functions inside their service-specific discovery document.



 =E2=80=94 Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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










_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 


























=

--Apple-Mail-1C627253-13CB-49DF-A69C-504F3CEB6868--


From nobody Wed Feb 24 13:07:22 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE151AD0CB for ; Wed, 24 Feb 2016 13:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.11
X-Spam-Level: *
X-Spam-Status: No, score=1.11 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, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=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 qpVJmsm2lVjW for ; Wed, 24 Feb 2016 13:07:19 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC651B2E3F for ; Wed, 24 Feb 2016 13:07:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E3w2SXER3kpk2TGOXeNip2TxB/+vDBuzQaSrgqdHtxs=; b=NYxMrCzSIS9E8EvDijAe0V2VI2WSxxTF/8yKM34skhykVvSmT0U1dCsVDFtY/3ZMrCP+Bd4ROrZk1fwb7+0vOSmqpAtnB076GZWVnIjfDDaDAIp2ouekmSsodwCXH3P3GJQW4nVxaUeVyAlJ8FukOkh9ohtf8ANRzsutKwA5oAM=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 21:06:47 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 21:06:47 +0000
From: Anthony Nadalin 
To: Nat Sakimura , oauth 
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt
Thread-Index: AQHRaR3f/VIinordjU6jdyp1yk7I6J87u85A
Date: Wed, 24 Feb 2016 21:06:47 +0000
Message-ID: 
References: <20160212094043.13011.44662.idtracker@ietfa.amsl.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8::48a]
x-ms-office365-filtering-correlation-id: ef13e949-fff8-418d-e2f6-08d33d5e6860
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:V2/ArRsiLT0Og+/przcdJJv6//20QCmwOCeA6nfoMNGuTwmmuhINtqHKBBAg5e0pWxG1xZisjFYRI6rmMwGRhEgMLIV8xRkUOeB5RmJPzEklPndea5GLlyj3P6qbI4ObolfjwZyLJ/vUG81uNud4dQ==; 24:qdBmndrKz+7ccI932gPNelwzt46NYHTs0mujk91rFqf9u7XX5IJcmCXJlskZkZG7m1tRveqOSI1nUtMuxnzM5e7P3ELkzfYO3huoBQcjDT4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(2473001)(377454003)(102836003)(87936001)(107886002)(11100500001)(19300405004)(54356999)(76176999)(106116001)(189998001)(5001960100002)(93886004)(76576001)(5004730100002)(50986999)(15650500001)(5003600100002)(5008740100001)(230783001)(5002640100001)(40100003)(2420400007)(10710500007)(586003)(1220700001)(1096002)(2906002)(3660700001)(790700001)(6116002)(74316001)(86612001)(99286002)(2900100001)(3280700002)(19625215002)(15975445007)(7110500001)(92566002)(19617315012)(19609705001)(2950100001)(10400500002)(16236675004)(5001770100001)(561944003)(8990500004)(10290500002)(33656002)(122556002)(86362001)(77096005)(19580395003)(10090500001)(19580405001)(5005710100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12342587C29BBCB3E708DB4EA6A50BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 21:06:47.4428 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 21:07:21 -0000

--_000_BN3PR0301MB12342587C29BBCB3E708DB4EA6A50BN3PR0301MB1234_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U28gYXMgSSB1bmRlcnN0YW5kIGl0IGluIHRoZSBMaW5rIFJlbGF0aW9ucyByZXBvc2l0b3J5IGFy
ZSBYTUwgZG9jdW1lbnRzIHRoYXQgb25lIGhhcyB0byBjcmVhdGUsIGFyZSB5b3Ugc3VnZ2VzdGlu
ZyBhcyBwYXJ0IG9mIHRoaXMgZWZmb3J0IGlzIHRvIHJld3JpdGUgYWxsIHRoYXQgaW4gSlNPTiBh
bmQgbWFrZSBhIHByb3Bvc2FsIGZvciB0aGF0IGFsc28gPw0KDQpGcm9tOiBOYXQgU2FraW11cmEg
W21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNiwg
MjAxNiA0OjU1IFBNDQpUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+
OyBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBGd2Q6IE5l
dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNy50
eHQNCg0KTGluayByZWxhdGlvbiBpcyBub3QgYXQgYWxsIFhNTC4gSXQgaXMgYSBzdGVwIGZvcndh
cmQgdG8gUkVTVGZ1bG5lc3MuDQpJbiB0aGUgb2xkZXIgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIEkg
d2FzIHVzaW5nIEpTT05pemVkIHZlcnNpb24gb2YgaXQgYXMgd2VsbCwgYnV0IEkgc3BsaXR0ZWQg
aXQgb3V0IGZvciB0aGUgc2FrZSBvZiBicmV2aXR5Lg0KSXQgaXMgYWxsIGFib3V0IGR5bmFtaWMg
bWV0YWRhdGEgYWJvdXQgdGhlIHJlc3BvbnNlLg0KT25jZSB3ZSBkbyBpdCB3aXRoIFJGQzU5ODgs
IHdlIGNvdWxkIGVhc2lseSBjcmVhdGUgYSBwYXJhbGxlbCB0byBpdCB3aXRoIEpTT04gbWV0YSBv
YmplY3Qgb2YgeW91ciBmbGF2b3VyLg0KKEN1cnJlbnRseSwgSlNPTiBzY2hlbWEgc2VlbXMgdG8g
YmUgaW4gZmFzaGlvbiwgdGhvdWdoIEkgcGVyc29uYWxseSBwcmVmZXIgSEFMLikNCkdvb2QgdGhp
bmdzIGFib3V0IHVzaW5nIEpTT05pemVkIHZlcnNpb24gaXMgdGhhdCBpdCB3aWxsIGJlIHVzYWJs
ZSBvdXRzaWRlIHRoZSBIVFRQIGFuZCB0aGUgZmFjdCB0aGF0IGl0IGNhbiBiZSBzdG9yZWQgaW4g
YSBzaW5nbGUgSlNPTiBvYmplY3QgdG9nZXRoZXIgd2l0aCB0aGUgZGF0YS4NCkJhZCB0aGluZyBh
Ym91dCBpdCBpcyB0aGF0IHdlIGhhdmUgdG8gc3RhcnQgZnJvbSB0aGUgc3ludGF4IGZvciBpdCwg
d2hpY2ggd2UgY2FuIGF2b2lkIGJ5IHVzaW5nIFJGQzU5ODguDQpJZiBwZW9wbGUgd2FudCB0aGUg
SlNPTiB2ZXJzaW9uIG9mIHRoaXMsIEkgY291bGQgZG8gaXQgYXMgd2VsbC4NCkhvd2V2ZXIsIHNp
bmNlIHdlIGFyZSBwcm9jZXNzaW5nIEhUVFAgcmVzcG9uc2UgaGVhZGVycyBhbnl3YXlzLCB0aGVy
ZSBpcyBub3QgbXVjaCBjb21wZWxsaW5nIHJlYXNvbiBmb3IgdGhhdCBhcyBsb25nIGFzIHdlIHN0
aWNrIHdpdGggSFRUUC4NClRoYXQncyB3aHkgSSBhbSBqdXN0IHN0aWNraW5nIHdpdGggUkZDNTk4
OC4NCg0KTmF0Lg0KDQoNCjIwMTblubQy5pyIMTfml6Uo5rC0KSA4OjUwIEFudGhvbnkgTmFkYWxp
biA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PjoN
CkkgcmVhbGx5IHRoaW5rIHRoYXQgdGhpcyBpcyBhIHN0ZXAgYmFja3dhcmRzIHJlbGF0aXZlIHRv
IHRlY2hub2xvZ3kgYW5kIHdoYXQgdGhlIGRldmVsb3BlcnMgd291bGQgYWNjZXB0LiBUaGUgTGlu
ayBSZWxhdGlvbnMgdGFrZXMgdXMgYmFjayB0byB0aGUgWE1MIGRheXMsIEkgdGhvdWdodCB3ZSBo
YXZlIGFsbCBtb3ZlZCBvbiBmcm9tIHRoYXQgYW5kIGF0IGxlYXN0IHRyeWluZyB0byBtb3ZlIE9h
dXRoIHRvIEpTT04uIEkgdGhpbmsgaWYgdGhpcyB3ZXJlIGFkb3B0ZWQgd2UgbWlnaHQgYmUgc3Bs
aXR0aW5nIHRoZSBkZXZlbG9wZXJzIGludG8gZm9sa3MgdGhhdCBhcmUgYWxyZWFkeSBnb2luZyBk
b3duIHRoZSBjdXJyZW50IEpTT04gcGF0aCB3aXRoIE9hdXRoIGFuZCB0aG9zZSB0aGF0IHdhbnQg
dG8gZ28gYmFjayB0byBYTUwuDQoNClRoaXMganVzdCBzZWVtcyBhIHZlcnkgb2RkIGRyYWZ0IHRv
IGFkb3B0IHRoaXMgdGVjaG5vbG9neS4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m
IE5hdCBTYWtpbXVyYQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxNSwgMjAxNiAzOjU5IFBNDQpU
bzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0
OiBbT0FVVEgtV0ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zYWtp
bXVyYS1vYXV0aC1tZXRhLTA3LnR4dA0KDQpJdCBub3cgc2hvd3MgaG93IHRvIHJldHVybiBtdWx0
aXBsZSBlbmRwb2ludHMgaW4gd2ViIGxpbmtpbmcuDQpBbHNvLCBhZGRlZCBSZXNvdXJjZSBFbmRw
b2ludCByZXNwb25zZSBoZWFkZXIuDQoNCkJlc3QsDQoNCm5hdA0KDQotLS0tLS0tLS0tIEZvcndh
cmRlZCBtZXNzYWdlIC0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxt
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IDIwMTblubQy5pyIMTLml6Uo
6YeRKSAxODo0MA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1z
YWtpbXVyYS1vYXV0aC1tZXRhLTA3LnR4dA0KVG86IE5vdiBNYXRha2UgPG5vdkBtYXRha2UuanA8
bWFpbHRvOm5vdkBtYXRha2UuanA+PiwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208
bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+LCBTYXNjaGEgUHJlaWJpc2NoIDxTYXNjaGEuUHJl
aWJpc2NoQGdtYWlsLmNvbTxtYWlsdG86U2FzY2hhLlByZWliaXNjaEBnbWFpbC5jb20+PiwgU2Fz
Y2hhIFByZWliaXNjaCA8c2FzY2hhLnByZWliaXNjaEBnbWFpbC5jb208bWFpbHRvOnNhc2NoYS5w
cmVpYmlzY2hAZ21haWwuY29tPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1z
YWtpbXVyYS1vYXV0aC1tZXRhLTA3LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl
ZCBieSBOYXQgU2FraW11cmEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K
TmFtZTogICAgICAgICAgIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGENClJldmlzaW9uOiAgICAg
ICAwNw0KVGl0bGU6ICAgICAgICAgIE9BdXRoIFJlc3BvbnNlIE1ldGFkYXRhDQpEb2N1bWVudCBk
YXRlOiAgMjAxNi0wMi0xMg0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K
UGFnZXM6ICAgICAgICAgIDEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0PGh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm
d3d3LmlldGYub3JnJTJmaW50ZXJuZXQtZHJhZnRzJTJmZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0
YS0wNy50eHQmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzYTk5MmQ1
ZmY0YTI0Mjg4MDRmMjA4ZDMzNjY0MTI5MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZzZGF0YT02TTEwUTlYNGNxJTJiJTJmUnJvUiUyZkhZUTlJTjNQMUhPMDZKbmJ1elk2
UDNvV3RjJTNkPg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGF0YXRyYWNrZXIuaWV0Zi5v
cmclMmZkb2MlMmZkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJTJmJmRhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjM2E5OTJkNWZmNGEyNDI4ODA0ZjIwOGQzMzY2NDEyOTIl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9N3R3RU0wRnp0U2Fz
d3RGaVlzbHZKdWFkVHlXYldSU0RXUTZ1VCUyYmV2S3dNJTNkPg0KSHRtbGl6ZWQ6ICAgICAgIGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3PGh0
dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh
JTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0w
NyZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzNhOTkyZDVmZjRhMjQy
ODgwNGYyMDhkMzM2NjQxMjkyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx
JnNkYXRhPWtoMm5INEl5Tm0zT0FBNW5rclNGelpOMTZYaWMlMmIyRURVT2ZyJTJmRzZDalZZJTNk
Pg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm
dC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmcmZjZGlmZiUz
ZnVybDIlM2RkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3JmRhdGE9MDElN2MwMSU3Y3Rvbnlu
YWQlNDBtaWNyb3NvZnQuY29tJTdjM2E5OTJkNWZmNGEyNDI4ODA0ZjIwOGQzMzY2NDEyOTIlN2M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9SUN0azVVMWU2a0JQRkk4
b3YwbjA2VEFjcURYM0h1cmdGVHlkWEtENzNZbyUzZD4NCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNw
ZWNpZmljYXRpb24gZGVmaW5lcyBhbiBleHRlbnNpYmxlIG1ldGFkYXRhIHRoYXQgbWF5IGJlDQog
ICBpbnNlcnRlZCBpbnRvIHRoZSBPQXV0aCAyLjAgcmVzcG9uc2VzIHRvIGFzc2lzdCB0aGUgY2xp
ZW50cyB0bw0KICAgcHJvY2VzcyB0aG9zZSByZXNwb25zZXMuICBJdCBpcyBleHByZXNzZWQgZWl0
aGVyIGFzIGEgbGluayBoZWFkZXIsIG9yDQogICBxdWVyeSBwYXJhbWV0ZXJzLiAgSXQgd2lsbCBh
bGxvdyB0aGUgY2xpZW50IHRvIGxlYXJuIHdoZXJlIHRoZQ0KICAgbWVtYmVycyBpbiB0aGUgcmVz
cG9uc2UgY291bGQgYmUgdXNlZCwgd2hhdCBpcyB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mDQogICB0
aGUgcGF5bG9hZCBpcywgaG93IGl0IHNob3VsZCBiZSBwcm9jZXNzZWQsIGFuZCBzbyBvbi4gIFNp
bmNlIHRoZXkNCiAgIGFyZSBqdXN0IGFkZGl0aW9uYWwgcmVzcG9uc2UgaGVhZGVyL3F1ZXJ5IHBh
cmFtZXRlcnMsIGFueSBjbGllbnQgdGhhdA0KICAgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGlzIGV4
dGVuc2lvbiBzaG91bGQgbm90IGJyZWFrIGFuZCB3b3JrIG5vcm1hbGx5DQogICB3aGlsZSBzdXBw
b3J0aW5nIGNsaWVudHMgY2FuIHV0aWxpemUgdGhlIG1ldGFkYXRhIHRvIHRha2UgdGhlDQogICBh
ZHZhbnRhZ2Ugb2YgdGhlIGV4dGVuc2lvbi4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt
YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K
dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s
cy5pZXRmLm9yZzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmcmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2MzYTk5MmQ1ZmY0YTI0Mjg4MDRmMjA4ZDMzNjY0MTI5MiU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1haWpDNnJBbjAxbjA0bUR5QjVs
cFY3dFFpdHhJeWYwZHJkaGVsZVI5NTVBJTNkPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg==

--_000_BN3PR0301MB12342587C29BBCB3E708DB4EA6A50BN3PR0301MB1234_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3Nl
LTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN
YWxndW4gR290aGljIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y
bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv
bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBhcyBJIHVuZGVy
c3RhbmQgaXQgaW4gdGhlIExpbmsgUmVsYXRpb25zIHJlcG9zaXRvcnkgYXJlIFhNTCBkb2N1bWVu
dHMgdGhhdCBvbmUgaGFzIHRvIGNyZWF0ZSwgYXJlIHlvdSBzdWdnZXN0aW5nIGFzIHBhcnQgb2Yg
dGhpcyBlZmZvcnQgaXMgdG8gcmV3cml0ZSBhbGwgdGhhdA0KIGluIEpTT04gYW5kIG1ha2UgYSBw
cm9wb3NhbCBmb3IgdGhhdCBhbHNvID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
IE5hdCBTYWtpbXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAxNiwgMjAxNiA0OjU1IFBNPGJyPg0KPGI+VG86PC9iPiBB
bnRob255IE5hZGFsaW4gJmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDs7IG9hdXRoICZsdDtv
YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRndk
OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEt
MDcudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGluayByZWxhdGlv
biBpcyBub3QgYXQgYWxsIFhNTC4gSXQgaXMgYSBzdGVwIGZvcndhcmQgdG8gUkVTVGZ1bG5lc3Mu
Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhl
IG9sZGVyIHZlcnNpb24gb2YgdGhlIGRyYWZ0LCBJIHdhcyB1c2luZyBKU09OaXplZCB2ZXJzaW9u
IG9mIGl0IGFzIHdlbGwsIGJ1dCBJIHNwbGl0dGVkIGl0IG91dCBmb3IgdGhlIHNha2Ugb2YgYnJl
dml0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkl0IGlzIGFsbCBhYm91dCBkeW5hbWljIG1ldGFkYXRhIGFib3V0IHRoZSByZXNwb25z
ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uY2Ugd2UgZG8gaXQgd2l0aCBSRkM1OTg4LCB3ZSBjb3VsZCBlYXNpbHkgY3JlYXRlIGEg
cGFyYWxsZWwgdG8gaXQgd2l0aCBKU09OIG1ldGEgb2JqZWN0IG9mIHlvdXIgZmxhdm91ci4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihD
dXJyZW50bHksIEpTT04gc2NoZW1hIHNlZW1zIHRvIGJlIGluIGZhc2hpb24sIHRob3VnaCBJIHBl
cnNvbmFsbHkgcHJlZmVyIEhBTC4pJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIHRoaW5ncyBhYm91dCB1c2luZyBKU09OaXplZCB2
ZXJzaW9uIGlzIHRoYXQgaXQgd2lsbCBiZSB1c2FibGUgb3V0c2lkZSB0aGUgSFRUUCBhbmQgdGhl
IGZhY3QgdGhhdCBpdCBjYW4gYmUgc3RvcmVkIGluIGEgc2luZ2xlIEpTT04gb2JqZWN0IHRvZ2V0
aGVyIHdpdGggdGhlIGRhdGEuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWQgdGhpbmcgYWJvdXQgaXQgaXMgdGhhdCB3ZSBoYXZlIHRv
IHN0YXJ0IGZyb20gdGhlIHN5bnRheCBmb3IgaXQsIHdoaWNoIHdlIGNhbiBhdm9pZCBieSB1c2lu
ZyBSRkM1OTg4LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SWYgcGVvcGxlIHdhbnQgdGhlIEpTT04gdmVyc2lvbiBvZiB0aGlzLCBJIGNv
dWxkIGRvIGl0IGFzIHdlbGwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBzaW5jZSB3ZSBhcmUgcHJvY2Vzc2luZyBIVFRQ
IHJlc3BvbnNlIGhlYWRlcnMgYW55d2F5cywgdGhlcmUgaXMgbm90IG11Y2ggY29tcGVsbGluZyBy
ZWFzb24gZm9yIHRoYXQgYXMgbG9uZyBhcyB3ZSBzdGljayB3aXRoIEhUVFAuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0J3Mgd2h5
IEkgYW0ganVzdCBzdGlja2luZyB3aXRoIFJGQzU5ODguJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdC4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+
5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx
dW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MTc8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuawtDwv
c3Bhbj4pDQogODo1MCBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFk
QG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHJlYWxseSB0aGluayB0aGF0
IHRoaXMgaXMgYSBzdGVwIGJhY2t3YXJkcyByZWxhdGl2ZSB0byB0ZWNobm9sb2d5IGFuZCB3aGF0
IHRoZSBkZXZlbG9wZXJzIHdvdWxkIGFjY2VwdC4NCiBUaGUgTGluayBSZWxhdGlvbnMgdGFrZXMg
dXMgYmFjayB0byB0aGUgWE1MIGRheXMsIEkgdGhvdWdodCB3ZSBoYXZlIGFsbCBtb3ZlZCBvbiBm
cm9tIHRoYXQgYW5kIGF0IGxlYXN0IHRyeWluZyB0byBtb3ZlIE9hdXRoIHRvIEpTT04uIEkgdGhp
bmsgaWYgdGhpcyB3ZXJlIGFkb3B0ZWQgd2UgbWlnaHQgYmUgc3BsaXR0aW5nIHRoZSBkZXZlbG9w
ZXJzIGludG8gZm9sa3MgdGhhdCBhcmUgYWxyZWFkeSBnb2luZyBkb3duIHRoZSBjdXJyZW50IEpT
T04NCiBwYXRoIHdpdGggT2F1dGggYW5kIHRob3NlIHRoYXQgd2FudCB0byBnbyBiYWNrIHRvIFhN
TC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGp1
c3Qgc2VlbXMgYSB2ZXJ5IG9kZCBkcmFmdCB0byBhZG9wdCB0aGlzIHRlY2hub2xvZ3kuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtc2ctZjox
NTI2Mzc3MDcxNjgwNzg2MzI3X19NYWlsRW5kQ29tcG9zIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5OYXQgU2FraW11cmE8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFy
eSAxNSwgMjAxNiAzOjU5IFBNPGJyPg0KPGI+VG86PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp
Y2F0aW9uIGZvciBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3LnR4dDwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5JdCBub3cgc2hvd3MgaG93IHRvIHJldHVybiBtdWx0aXBsZSBlbmRwb2ludHMgaW4gd2ViIGxp
bmtpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5BbHNvLCBhZGRlZCBSZXNvdXJjZSBFbmRwb2ludCByZXNwb25zZSBoZWFkZXIuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C
ZXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+bmF0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLTxicj4NCkZyb206
ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiAyMDE2PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJp
ZiI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhp
YyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MTI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPumH
kTwvc3Bhbj4pDQogMTg6NDA8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g
Zm9yIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcudHh0PGJyPg0KVG86IE5vdiBNYXRha2Ug
Jmx0OzxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1h
dGFrZS5qcDwvYT4mZ3Q7LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Oywg
U2FzY2hhIFByZWliaXNjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOlNhc2NoYS5QcmVpYmlzY2hAZ21h
aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+U2FzY2hhLlByZWliaXNjaEBnbWFpbC5jb208L2E+Jmd0
OywNCiBTYXNjaGEgUHJlaWJpc2NoICZsdDs8YSBocmVmPSJtYWlsdG86c2FzY2hhLnByZWliaXNj
aEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYXNjaGEucHJlaWJpc2NoQGdtYWlsLmNvbTwv
YT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJy
Pg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEt
MDcudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBOYXQgU2FraW11
cmEgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFt
ZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXNha2ltdXJh
LW9hdXRoLW1ldGE8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswNzxi
cj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT0F1dGggUmVzcG9u
c2UgTWV0YWRhdGE8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE2LTAyLTEyPGJyPg0KR3Jv
dXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Np
b248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDEwPGJyPg0K
VVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0
dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh
JTJmJTJmd3d3LmlldGYub3JnJTJmaW50ZXJuZXQtZHJhZnRzJTJmZHJhZnQtc2FraW11cmEtb2F1
dGgtbWV0YS0wNy50eHQmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29t
JTdjM2E5OTJkNWZmNGEyNDI4ODA0ZjIwOGQzMzY2NDEyOTIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTZNMTBROVg0Y3ElMmIlMmZScm9SJTJmSFlROUlO
M1AxSE8wNkpuYnV6WTZQM29XdGMlM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3LnR4dDwv
YT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9
Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz
JTNhJTJmJTJmZGF0YXRyYWNrZXIuaWV0Zi5vcmclMmZkb2MlMmZkcmFmdC1zYWtpbXVyYS1vYXV0
aC1tZXRhJTJmJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzNh
OTkyZDVmZjRhMjQyODgwNGYyMDhkMzM2NjQxMjkyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJmFtcDtzZGF0YT03dHdFTTBGenRTYXN3dEZpWXNsdkp1YWRUeVdiV1JTRFdR
NnVUJTJiZXZLd00lM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLzwvYT48YnI+DQpIdG1saXplZDombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy
b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJm
aHRtbCUyZmRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcmYW1wO2RhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjM2E5OTJkNWZmNGEyNDI4ODA0ZjIwOGQzMzY2NDEyOTIl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWtoMm5INEl5
Tm0zT0FBNW5rclNGelpOMTZYaWMlMmIyRURVT2ZyJTJmRzZDalZZJTNkIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEt
MDc8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmcmZjZGlmZiUzZnVybDIlM2RkcmFmdC1z
YWtpbXVyYS1vYXV0aC1tZXRhLTA3JmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9z
b2Z0LmNvbSU3YzNhOTkyZDVmZjRhMjQyODgwNGYyMDhkMzM2NjQxMjkyJTdjNzJmOTg4YmY4NmYx
NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1JQ3RrNVUxZTZrQlBGSThvdjBuMDZU
QWNxRFgzSHVyZ0ZUeWRYS0Q3M1lvJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDc8L2E+PGJyPg0K
PGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZp
bmVzIGFuIGV4dGVuc2libGUgbWV0YWRhdGEgdGhhdCBtYXkgYmU8YnI+DQombmJzcDsgJm5ic3A7
aW5zZXJ0ZWQgaW50byB0aGUgT0F1dGggMi4wIHJlc3BvbnNlcyB0byBhc3Npc3QgdGhlIGNsaWVu
dHMgdG88YnI+DQombmJzcDsgJm5ic3A7cHJvY2VzcyB0aG9zZSByZXNwb25zZXMuJm5ic3A7IEl0
IGlzIGV4cHJlc3NlZCBlaXRoZXIgYXMgYSBsaW5rIGhlYWRlciwgb3I8YnI+DQombmJzcDsgJm5i
c3A7cXVlcnkgcGFyYW1ldGVycy4mbmJzcDsgSXQgd2lsbCBhbGxvdyB0aGUgY2xpZW50IHRvIGxl
YXJuIHdoZXJlIHRoZTxicj4NCiZuYnNwOyAmbmJzcDttZW1iZXJzIGluIHRoZSByZXNwb25zZSBj
b3VsZCBiZSB1c2VkLCB3aGF0IGlzIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2Y8YnI+DQombmJzcDsg
Jm5ic3A7dGhlIHBheWxvYWQgaXMsIGhvdyBpdCBzaG91bGQgYmUgcHJvY2Vzc2VkLCBhbmQgc28g
b24uJm5ic3A7IFNpbmNlIHRoZXk8YnI+DQombmJzcDsgJm5ic3A7YXJlIGp1c3QgYWRkaXRpb25h
bCByZXNwb25zZSBoZWFkZXIvcXVlcnkgcGFyYW1ldGVycywgYW55IGNsaWVudCB0aGF0PGJyPg0K
Jm5ic3A7ICZuYnNwO2RvZXMgbm90IHVuZGVyc3RhbmQgdGhpcyBleHRlbnNpb24gc2hvdWxkIG5v
dCBicmVhayBhbmQgd29yayBub3JtYWxseTxicj4NCiZuYnNwOyAmbmJzcDt3aGlsZSBzdXBwb3J0
aW5nIGNsaWVudHMgY2FuIHV0aWxpemUgdGhlIG1ldGFkYXRhIHRvIHRha2UgdGhlPGJyPg0KJm5i
c3A7ICZuYnNwO2FkdmFudGFnZSBvZiB0aGUgZXh0ZW5zaW9uLjxicj4NCjxicj4NCjxicj4NCjxi
cj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl
cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy
c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ0b29scy5pZXRm
Lm9yZyZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MzYTk5MmQ1
ZmY0YTI0Mjg4MDRmMjA4ZDMzNjY0MTI5MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZhbXA7c2RhdGE9YWlqQzZyQW4wMW4wNG1EeUI1bHBWN3RRaXR4SXlmMGRyZGhlbGVS
OTU1QSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4N
ClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BN3PR0301MB12342587C29BBCB3E708DB4EA6A50BN3PR0301MB1234_--


From nobody Wed Feb 24 13:09:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963DA1B3978 for ; Wed, 24 Feb 2016 13:09:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 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_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 ob121DPMk9kl for ; Wed, 24 Feb 2016 13:09:28 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694501B3822 for ; Wed, 24 Feb 2016 13:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n5vnHzgb/6sXo0zL0PXcSyJ72TqBnHTaHgmywoIAWf4=; b=m2VuIIPTVbKzvqV3nZ3vncDswPDGNkwQolDKUG+fDCTr/l7szcXk6KNM0PfdrDvtp6u0tKJF4dgxmHSSlNl1v25UsCE/ni1qktstw5NJ4H7KbaoP9R5vDNamYfXJOG3YI/h65yhUcq+iji3zaVUR24J2ohHM7OCdpau6v9TuESA=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 21:09:05 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 21:09:05 +0000
From: Mike Jones 
To: "Phil Hunt (IDM)" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YA=
Date: Wed, 24 Feb 2016 21:09:04 +0000
Message-ID: 
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>
In-Reply-To: <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::650]
x-ms-office365-filtering-correlation-id: c3c096d6-029e-43b0-abba-08d33d5eba42
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:+MEeVSKJttW4ccuLSsFz6VGzVb7F5lzcY0oEXUi6yHzNdVMKamu5vghHdULcGQf8FVIOvQEMxA8hJ/wEXF1XQc+vewDuBuwi2GezxFIJPTM0UZsrbWmzgsyPZFeDdhnrlDZ93Q93jTpTnEX4i0V97Q==; 24:K9FlpIBAaCKQTVuIbVnPwUVRutD2BE+FICJjbGPBORifBiqYbAOYAGPIAGkOE1kYAgkPplMsjNrje/9bs9mR3WBCb4Gtz1FbFiaRCorGZjI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(106116001)(99286002)(5002640100001)(87936001)(19300405004)(76576001)(92566002)(76176999)(16236675004)(86362001)(10090500001)(50986999)(54356999)(86612001)(19617315012)(5001960100002)(189998001)(110136002)(5003600100002)(19625215002)(1220700001)(19609705001)(3660700001)(33656002)(19580395003)(586003)(19580405001)(74316001)(3280700002)(93886004)(790700001)(102836003)(5004730100002)(6116002)(10290500002)(3900700001)(5005710100001)(5008740100001)(1096002)(11100500001)(40100003)(122556002)(10400500002)(8990500004)(15975445007)(77096005)(2950100001)(4326007)(2900100001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E135F59374B40084665EF5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 21:09:04.8336 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 21:09:32 -0000

--_000_BY2PR03MB442E135F59374B40084665EF5A50BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VG8gdGhlIGV4dGVudCB0aGF0IGdlbmVyaWMgT0F1dGggMi4wIG5lZWRzIHRvIHB1Ymxpc2ggc29t
ZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBPcGVuSUQgQ29ubmVjdCDigJMgd2hpY2ggaXMg
YnVpbHQgb24gZ2VuZXJpYyBPQXV0aCAyLjAg4oCTIGl0IG1ha2VzIHNlbnNlIHRvIHB1Ymxpc2gg
dGhhdCBpbmZvcm1hdGlvbiB1c2luZyBleGFjdGx5IHRoZSBzYW1lIHN5bnRheCwgc2luY2UgdGhh
dCBzeW50YXggaXMgYWxyZWFkeSBpbiB3aWRlc3ByZWFkIHVzZS4gIFRoYXQgd2hhdCB0aGlzIGRy
YWZ0IGFjY29tcGxpc2hlcy4NCg0KVGhlcmXigJlzIG5vdGhpbmcgQ29ubmVjdC1zcGVjaWZpYyBh
Ym91dCB1c2luZyBtZXRhZGF0YSByZXNwb25zZSB2YWx1ZXMgbGlrZToNCg0KICAgImF1dGhvcml6
YXRpb25fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplIiwN
CiAgICJ0b2tlbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiIs
DQogICAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCI6IFsiY2xpZW50X3Nl
Y3JldF9iYXNpYyIsICJwcml2YXRlX2tleV9qd3QiXSwNCiAgICJyZWdpc3RyYXRpb25fZW5kcG9p
bnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0ZXIiLA0KICAgInJlc3BvbnNl
X3R5cGVzX3N1cHBvcnRlZCI6ICBbImNvZGUiLCAidG9rZW4iXSwNCiAgICJzZXJ2aWNlX2RvY3Vt
ZW50YXRpb24iOiAiaHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2aWNlX2RvY3VtZW50YXRp
b24uaHRtbCIsDQoNCklzIHRoZXJlIGEgcmVhc29uIHRoYXQgeW91IHdvdWxkIGxpa2UgdGhlIHN5
bnRheCBmb3IgYW55IG9mIHRoZXNlIG9yIHRoZSBvdGhlciBnZW5lcmFsbHkgYXBwbGljYWJsZSBP
QXV0aCAyLjAgbWV0YWRhdGEgdmFsdWVzIHRvIGJlIGRpZmZlcmVudD8gIEkgZG9u4oCZdCBzZWUg
YW55IGdvb2QgcmVhc29uIGZvciB1bm5lY2Vzc2FyeSBkaWZmZXJlbmNlcyB0byBiZSBpbnRyb2R1
Y2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkgW21haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYg
MTI6NDUgUE0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCkNj
OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyA8b2F1dGhAaWV0Zi5v
cmc+IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBE
aXNjb3ZlcnkgTG9jYXRpb24NCg0KTWlrZQ0KDQpQdWJsaXNoaW5nIG9uIGRldiBwYWdlcyBkb2Vz
IG5vdCB3b3JrIGZvciBzb2Z0d2FyZSAoZXNwIG9wZW4gc291cmNlKSB0aGF0IGlzIGRlcGxveWVk
IGJvdGggaW4gZW50ZXJwcmlzZXMgYW5kIG9uIFBhYVMgY2xvdWQgcHJvdmlkZXJzLg0KDQpUaGUg
Y3VycmVudCBkcmFmdCBpcyBtYXkgY29kaWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBhbmQgYmUg
YXBwcm9wcmlhdGUgZm9yIG9pZGMgYnV0IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJpYyBvYXV0
aC4gVGhlcmUgaXMgbm8gZ2VuZXJpYyBvYXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGltZS4NCg0K
UGhpbA0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDEwOjI1LCBBbnRob255IE5hZGFsaW4gPHRvbnlu
YWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpT
dXJlIHRoZXJlIGlzLCBpdCBpcyBhcyB5b3UgaGF2ZSBub3cgbWFkZSBpdCBmYXIgZWFzaWVyIGFu
ZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9lcyBub3QgZXZlbiBhZGRyZXNzIHRoaXMN
Cg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAx
MDoyMiBBTQ0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0
bzp0b255bmFkQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1
dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1
YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KQXMg
d2XigJlkIGRpc2N1c3NlZCBpbiBwZXJzb24sIHRoZXJl4oCZcyBubyBlZmZlY3RpdmUgc2VjdXJp
dHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBiZWluZyBwdWJsaXNo
ZWQgaW4gYW4gYWQtaG9jIGZhc2hpb24gb24gZGV2ZWxvcGVyIHBhZ2VzIGFuZCBpdCBiZWluZyBw
dWJsaXNoZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQuICDigJxTZWN1cml0eSBieSBvYnNjdXJpdHni
gJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC4NCg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQW50
aG9ueSBOYWRhbGluDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFN
DQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3Jh
Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjsgTmF0IFNha2ltdXJhIDxzYWtp
bXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+DQpDYzogPG9hdXRoQGll
dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1
dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVy
eSBMb2NhdGlvbg0KDQo+IFRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRh
cmRpemluZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5
IHdpZGVseSBkZXBsb3llZC4NCg0KVGhhdCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBPSURD
IGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVkIGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVu
dGljYXRpb24gbWVjaGFuaXNtIGRpc2NvdmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hv
dWxkIG5vdCBiZSBpbiBhbiBPQXV0aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5vdCBk
ZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgaXQg
bWFrZXMgcG9raW5nIGFyb3VuZCB0aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9wbGUg
dGhhdCB3YW50IHRvIGRpc3J1cHQgeW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5vdCBh
ZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYXQgYWxsDQoN
CkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTQ0K
VG86IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu
dEBvcmFjbGUuY29tPj47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpz
YWtpbXVyYUBnbWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KVGhlIHBvaW50
IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVy
eSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLg0KDQpOb25l
IG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0
ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0ZWQuICBJ4oCZbSBzdXJlIGl0IHdpbGwg
YmUuICBTb21lIGFwcGxpY2F0aW9ucyB3aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRoZSBk
aXNjb3ZlcnkgbWV0YWRhdGEuICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4g
IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgYXBwbGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24g
dmFsdWVzLiAgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0IGV2
ZW4gdGhvdWdodCBhYm91dC4gIEFsbCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNj
b3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgZm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0
IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5
IG1ldGFkYXRhIHZhbHVlcy4NCg0KU28gYnkgYWxsIG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBz
aG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQg
bWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250ZXh0cy4gIEF0IHRoZSBzYW1l
IHRpbWUsIHdlIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVw
bG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2ls
bCBuZWVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElETSkNClNlbnQ6IFdlZG5lc2RheSwg
RmVicnVhcnkgMjQsIDIwMTYgODozOSBBTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21h
aWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxt
YWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu
b3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRp
b24NCg0KSSBhbSBzdWdnZXN0aW5nIHRoYXQgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9u
IGhhcyB0byBiZSB0aGUgY2xpZW50IGluZGljYXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBp
dCB3YW50cyB0aGUgb2F1dGggY29uZmlndXJhdGlvbiBkYXRhIGZvci4NCg0KU28gaWYgcmVzLmV4
YW1wbGUuZXZpbC5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su
Y29tLz91cmw9aHR0cCUzYSUyZiUyZnJlcy5leGFtcGxlLmV2aWwuY29tJmRhdGE9MDElN2MwMSU3
Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0Mzdj
ZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9UGMlMmI3aWxu
RFlnZmpZb1RzUVdvWm5wb2JHJTJiVkpwNVd1OWNHcEZVZ3ozUzAlM2Q+IGlzIG5vdCBhIHZhbGlk
IHJlc291cmNlIGVuZHBvaW50IGZvciBhcy5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXMuZXhhbXBsZS5j
b20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0
ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj
MSZzZGF0YT02JTJicXhoJTJmN1ZDWmtzd1hoSk12NnIlMmIxOGRUUmJnMklzMTJXQiUyZmRabTNj
SjQlM2Q+IHRoZSBhdXRoeiBkaXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJl
dHVybiBub3RoaW5nKS4NCg0KVGhlcmUgbWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVn
IGNvbWJpbmUgZGlzY292ZXJ5LiBPciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4NCg0K
T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJn
ZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0
IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRl
biBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVu
IHRoYXQgaW4gZGlzY292ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJl
ZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQg
Y29tYmluYXRpb24gb2YgZW5kcG9pbnRzIGV0Yy4NCg0KVGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBw
b2ludGVkIGFib3V0IHdnbGMgb24gZGlzY292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBm
b3IgZ3JvdXAgYWRvcHRpb24gYnV0IHdlIGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwg
cmVxdWlyZW1lbnRzIElNTy4NCg0KSSBhbSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21l
IHRob3VnaHQgaW50byBzb21lIGRyYWZ0IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9n
aXplIEkgY2FuJ3QgZG8gaXQgbm93Lg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6
MTIsIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFp
bC5jb20+PiB3cm90ZToNCkhpIFBoaWwsDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBB
UyBtZXRhZGF0YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2Vz
IG5vdCwgYnV0IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLg0KDQpUaGUgd2F5IG9hdXRoLW1ldGEg
d29ya3MgaXMgdGhhdA0KDQoxLiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4N
CjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4g
YmUgdXNlZC4NCg0KRXZlbiBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMg
dGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhl
IHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhl
IHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uDQoNCk5hdA0K
DQoyMDE25bm0MuaciDI05pelKOawtCkgMjM6NTkgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xl
LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCk5hdCwNCg0KSeKAmW0gbm90IHN1
cmUgdGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUg
aXRzIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlv
bnNoaXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBz
ZXJ2ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBl
bmRwb2ludHMgKHRoZSByZXNvdXJjZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5
KS4NCg0KSWYgYSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBp
cyBwcm94eWluZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zl
cnkgc3BlYyB3aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhl
IHdyb25nIHJlc291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ug
d2lsbCBqdXN0IGhhdmUgYSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBu
b3cgaW50ZXJjZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0
aGV5IHdlcmUgYWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0
aG9yaXphdGlvbiBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMg
cHJveHkuDQoNClRoZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRv
IHRoZSBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBh
IHN0YXRlZCByZXNvdXJjZSBlbmRwb2ludC4NCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3Jt
YWwgT0F1dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4N
Cg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3
d3cuaW5kZXBlbmRlbnRpZC5jb20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5j
b20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5
MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1NSldwRkIxMnZUTEI0ZWNLeVl3bFpMblJKSW5hTkV3
MU13bHZ0VTI2QlBBJTNkPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv
cmFjbGUuY29tPg0KDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtp
bXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90
ZToNCg0KDQpIaSBUaG9tYXMsDQoNCmlubGluZToNCg0KMjAxNuW5tDLmnIgyMuaXpSjmnIgpIDE4
OjQ0IFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21h
aWwuY29tPj46DQpDb3VsZG4ndCB0aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0aGUgbWV0YWRh
dGE/DQpJIHF1aXRlIGxpa2UgdGhlIGlkZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBp
ZiB5b3UgcmVhbGx5IHdhbnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBp
bXBsZW1lbnRlcnMgLyB0byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwg
Zm9yICJhdXRvLWNvbmZpZ3VyYXRpb24iLg0KVGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdv
dWxkIHRoZW4gZWl0aGVyIGJlIHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRy
YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgbWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lz
IGZvciBvdGhlciBtZXRhZGF0YSBzcGVjcyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuDQpXaXRoIGRy
YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAiZHVyaSIgYW5kIHRoZSAic2NvcGUiIGF0dHJpYnV0
ZSBvZiBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGlu
ZyB5b3UgbmVlZCB0byBwcm9jZWVkDQoNCll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1l
bnRzIHRvIGJlIFJFU1RmdWwsIGlzIGl0IG5vdD8NCg0KSW4gT0F1dGgncyBjYXNlLCB0aGUgcmVz
b3VyY2UgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNv
dXBsZWQuIChPdGhlcndpc2UsIHlvdSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKQ0KU28s
IHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxv
Y2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50
LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0
aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3Qg
aGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBm
cmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxp
c2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2Ug
YXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KKHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJh
bCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2Fz
ZSB0byBtZSB0aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3
aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3VjaCB0aGF0IGFuIFJTIGNvdWxkIHJldHVybiBzZXZlcmFs
IFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciwgZWFjaCB3aXRoIGl0cyBvd24gInNjb3BlIiBhbmQg
ImR1cmkiIHZhbHVlPykNCg0KWWVhaCwgSSBndWVzcyBpdCBpcyBhbiBlZGdlIGNhc2UuIEkgd291
bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMgdG8gZGV2ZWxvcCBhIHRy
dXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBvbiBhIHNpbmdsZSBzZXQg
b2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0K
T24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMTA6NTkgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBt
aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNClRoZSBuZXdseS10cmltbWVk
IE9BdXRoIERpc2NvdmVyeSBkb2N1bWVudCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJp
Z2h0IGRpcmVjdGlvbi4gSXQgZG9lcywgaG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0
aWdlcyBvZiBpdHMgT3BlbklEIENvbm5lY3Qgb3JpZ2lucy4gT25lIGlzc3VlIGluIHBhcnRpY3Vs
YXIgc3RpbGwgcmVhbGx5IGJvdGhlcnMgbWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29w
ZW5pZC1jb25maWd1cmF0aW9u4oCdIGluIHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBh
biBPQXV0aCBkaXNjb3ZlcnkgZG9jdW1lbnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhl
cmUgaXMgYWJzb2x1dGVseSBubyBjb21wZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0
aGUgT0lEQyBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KDQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCc
Ly53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0
IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5kIHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNv
IGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKA
nSBpZiB0aGUgc2VydmVyIGFsc28gcHJvdmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUg
ZG9tYWluLiBPdGhlciBhcHBsaWNhdGlvbnMgU0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJhbWV0ZXIg
bmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5kcG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5zaWRlIHRo
ZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292ZXJ5IGRvY3VtZW50Lg0KDQog4oCUIEp1c3Rpbg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9y
ZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3
cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h
dXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZj
NGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3
YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNk
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo
IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2Fm
ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRm
Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21j
czN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQo=

--_000_BY2PR03MB442E135F59374B40084665EF5A50BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiOw0K
CXBhbm9zZS0xOjIgMTEgNSAzIDIgMCAwIDIgMCA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt
c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy
Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm
dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCnNw
YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMw
MDIwNjA7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQt
ZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg
bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y
ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MDAyMDYwIj5UbyB0aGUgZXh0ZW50IHRoYXQgZ2VuZXJpYyBPQXV0aCAyLjAgbmVlZHMgdG8gcHVi
bGlzaCBzb21lIG9mIHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIE9wZW5JRCBDb25uZWN0IOKAkyB3
aGljaCBpcyBidWlsdCBvbiBnZW5lcmljIE9BdXRoIDIuMCDigJMgaXQgbWFrZXMgc2Vuc2UgdG8N
CiBwdWJsaXNoIHRoYXQgaW5mb3JtYXRpb24gdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBzeW50YXgs
IHNpbmNlIHRoYXQgc3ludGF4IGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UuJm5ic3A7IFRo
YXQgd2hhdCB0aGlzIGRyYWZ0IGFjY29tcGxpc2hlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPlRoZXJl4oCZcyBub3RoaW5nIENvbm5lY3Qtc3BlY2lmaWMgYWJv
dXQgdXNpbmcgbWV0YWRhdGEgcmVzcG9uc2UgdmFsdWVzIGxpa2U6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7YXV0aG9yaXphdGlv
bl9lbmRwb2ludCZxdW90OzogJnF1b3Q7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9y
aXplJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7dG9rZW5fZW5k
cG9pbnQmcXVvdDs6ICZxdW90O2h0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuJnF1b3Q7
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnRfYXV0
aF9tZXRob2RzX3N1cHBvcnRlZCZxdW90OzogWyZxdW90O2NsaWVudF9zZWNyZXRfYmFzaWMmcXVv
dDssICZxdW90O3ByaXZhdGVfa2V5X2p3dCZxdW90O10sPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw
OyZuYnNwOyAmcXVvdDtyZWdpc3RyYXRpb25fZW5kcG9pbnQmcXVvdDs6ICZxdW90O2h0dHBzOi8v
c2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz
cDsmbmJzcDsgJnF1b3Q7cmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkJnF1b3Q7OiZuYnNwOyBbJnF1
b3Q7Y29kZSZxdW90OywgJnF1b3Q7dG9rZW4mcXVvdDtdLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz
cDsmbmJzcDsgJnF1b3Q7c2VydmljZV9kb2N1bWVudGF0aW9uJnF1b3Q7OiAmcXVvdDtodHRwOi8v
c2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sJnF1b3Q7LDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SXMgdGhlcmUgYSByZWFzb24g
dGhhdCB5b3Ugd291bGQgbGlrZSB0aGUgc3ludGF4IGZvciBhbnkgb2YgdGhlc2Ugb3IgdGhlIG90
aGVyIGdlbmVyYWxseSBhcHBsaWNhYmxlIE9BdXRoIDIuMCBtZXRhZGF0YSB2YWx1ZXMgdG8gYmUg
ZGlmZmVyZW50PyZuYnNwOyBJIGRvbuKAmXQgc2VlIGFueQ0KIGdvb2QgcmVhc29uIGZvciB1bm5l
Y2Vzc2FyeSBkaWZmZXJlbmNlcyB0byBiZSBpbnRyb2R1Y2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBo
aWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2Vu
dDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTI6NDUgUE08YnI+DQo8Yj5Ubzo8
L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxi
PkNjOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsg
Jmx0O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZTxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9
IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QdWJsaXNoaW5nIG9u
IGRldiBwYWdlcyBkb2VzIG5vdCB3b3JrIGZvciBzb2Z0d2FyZSAoZXNwIG9wZW4gc291cmNlKSB0
aGF0IGlzIGRlcGxveWVkIGJvdGggaW4gZW50ZXJwcmlzZXMgYW5kIG9uIFBhYVMgY2xvdWQgcHJv
dmlkZXJzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxT
aWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgY3VycmVudCBkcmFmdCBpcyBtYXkgY29kaWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBh
bmQgYmUgYXBwcm9wcmlhdGUgZm9yIG9pZGMgYnV0IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJp
YyBvYXV0aC4gVGhlcmUgaXMgbm8gZ2VuZXJpYyBvYXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGlt
ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0
dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KT24gRmViIDI0LCAyMDE2LCBhdCAxMDoyNSwgQW50aG9ueSBOYWRhbGluICZs
dDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29m
dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN1cmUgdGhl
cmUgaXMsIGl0IGlzIGFzIHlvdSBoYXZlIG5vdyBtYWRlIGl0IGZhciBlYXNpZXIgYW5kIHRoZSBz
ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBldmVuIGFkZHJlc3MgdGhpczwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t
cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+
PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+IE1pa2UgSm9uZXMNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0
LCAyMDE2IDEwOjIyIEFNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhy
ZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwv
YT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
Ij5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v
cmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVU
SC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5B
cyB3ZeKAmWQgZGlzY3Vzc2VkIGluIHBlcnNvbiwgdGhlcmXigJlzIG5vIGVmZmVjdGl2ZSBzZWN1
cml0eSBkaWZmZXJlbmNlIGJldHdlZW4gZGlzY292ZXJ5IGluZm9ybWF0aW9uIGJlaW5nIHB1Ymxp
c2hlZCBpbiBhbiBhZC1ob2MgZmFzaGlvbiBvbiBkZXZlbG9wZXIgcGFnZXMgYW5kDQogaXQgYmVp
bmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiZuYnNwOyDigJxTZWN1cml0eSBieSBv
YnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbnRob255IE5hZGFsaW4NCjxicj4NCjxiPlNlbnQ6PC9i
PiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFNPGJyPg0KPGI+VG86PC9iPiBN
aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgUGhpbCBIdW50IChJRE0pICZs
dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu
Y29tPC9hPiZndDs7IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdt
YWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8
YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDsgJmx0
OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExv
Y2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDIwNjAiPiBUaGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJk
aXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkNCiB0aGF04oCZcyBhbHJlYWR5
IHdpZGVseSBkZXBsb3llZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw
NjAiPlRoYXQgbWF5IGJlIHdpZGVseSBkZXBsb3llZCBmb3IgT0lEQyBidXQgbm90IHdpZGVseSBk
ZXBsb3llZCBmb3IgT0F1dGguIFRoZXJlIGFyZSBzb21lIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz
bSBkaXNjb3ZlcnkgZm9yIGVuZHBvaW50IHRoYXQgcmVhbGx5IHNob3VsZCBub3QNCiBiZSBpbiBh
biBPQXV0aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cg
dGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFy
b3VuZCB0aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRp
c3J1cHQgeW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhl
IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQogc2VjdGlvbiBhdCBhbGwgPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi
Pk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks
IEZlYnJ1YXJ5IDI0LCAyMDE2IDk6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAoSURN
KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3Jh
Y2xlLmNvbTwvYT4mZ3Q7OyBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZn
dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVy
eSBMb2NhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMg
dG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkg
dGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj5Ob25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3Rp
bmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0
ZWQuJm5ic3A7IEnigJltIHN1cmUgaXQgd2lsbCBiZS4mbmJzcDsgU29tZSBhcHBsaWNhdGlvbnMg
d2lsbCB1c2UgV2ViRmluZ2VyIHRvDQogbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuJm5i
c3A7IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJzLiZuYnNwOyBTb21lIHdpbGwg
cG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNwZWNpZmljIC53ZWxsLWtub3duIHZhbHVlcy4mbmJz
cDsgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0IGV2ZW4gdGhv
dWdodCBhYm91dC4mbmJzcDsgQWxsIG9mIHRoZXNlIGRlcGVuZCB1cG9uIGhhdmluZyBhIGRpc2Nv
dmVyeSBtZXRhZGF0YSBkb2N1bWVudA0KIGZvcm1hdCBhbmQgbm9uZSBvZiB0aGVtIGNoYW5nZSBp
dCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdpc3RlciBhZGRpdGlvbmFsIGRpc2NvdmVy
eSBtZXRhZGF0YSB2YWx1ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy
MDYwIj5TbyBieSBhbGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBjb250aW51ZSBk
aXNjdXNzaW5nIGludmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRlZCBtZWNoYW5pc21zIHRoYXQg
bWFrZSBzZW5zZSBpbiBzb21lIGNvbnRleHRzLiZuYnNwOyBBdCB0aGUgc2FtZSB0aW1lLCB3ZQ0K
IGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgY29y
ZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2lsbCBuZWVkLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFs8YSBocmVmPSJtYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQgKElETSk8YnI+DQo8Yj5TZW50Ojwv
Yj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFNPGJyPg0KPGI+VG86PC9iPiBO
YXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2lt
dXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRv
Om9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHN1Z2dl
c3RpbmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRpb24gaGFzIHRvIGJlIHRoZSBj
bGllbnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50IGl0IHdhbnRzIHRoZSBvYXV0
aCBjb25maWd1cmF0aW9uIGRhdGEgZm9yLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz
LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmcmVzLmV4YW1wbGUuZXZp
bC5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJh
NzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmYW1wO3NkYXRhPVBjJTJiN2lsbkRZZ2ZqWW9Uc1FXb1pucG9iRyUyYlZKcDVXdTlj
R3BGVWd6M1MwJTNkIj4NCnJlcy5leGFtcGxlLmV2aWwuY29tPC9hPiBpcyBub3QgYSB2YWxpZCBy
ZXNvdXJjZSBlbmRwb2ludCBmb3IgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90
ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFzLmV4YW1wbGUuY29tJmFtcDtk
YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFh
YWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFt
cDtzZGF0YT02JTJicXhoJTJmN1ZDWmtzd1hoSk12NnIlMmIxOGRUUmJnMklzMTJXQiUyZmRabTNj
SjQlM2QiPg0KYXMuZXhhbXBsZS5jb208L2E+IHRoZSBhdXRoeiBkaXNjb3Zlcnkgc2hvdWxkIGZh
aWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu
YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgbWF5IGJlIGJldHRlciB3YXlzIHRv
IGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBPciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRp
c2NvdmVyeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWls
U2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0
YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQu
IEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBv
ZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdp
dmVuIHRoYXQgaW4NCiBkaXNjb3ZlcnkgcGhhc2UgcmVnaXN0cmF0aW9uIGhhcyBub3QgeWV0IG9j
Y3VycmVkIGl0IHNlZW1zIGltcG9ydGFudCB0aGF0IHRoZSBjbGllbnQga25vdyBpdCBoYXMgYSB2
YWxpZCBjb21iaW5hdGlvbiBvZiBlbmRwb2ludHMgZXRjLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h
dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdoeSBJIHdhcyBkaXNhcHBvaW50
ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0YXJ0aW5nIHBvaW50IGZvciBn
cm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVmaW5lZCB0aGUgZnVsbCByZXF1
aXJlbWVudHMgSU1PLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBs
ZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0IHNvbWUgdGhvdWdodCBpbnRv
IHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBhcG9sb2dpemUgSSBjYW4ndCBk
byBpdCBub3cuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9
Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SGkgUGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0YSBzaG91
bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0IGl0IGNh
biBiZSBkb25lLCBJIGd1ZXNzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdCZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4xLiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIEFTIHRlbGxzIHRo
ZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZl
biBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRv
IHRoZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFz
IHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGll
bnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KTmF0PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuW5tDwvc3Bhbj4yPHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OlNpbVN1biI+5pyIPC9zcGFuPjI0PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1
biI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7msLQ8L3NwYW4+
KSAyMzo1OSBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB0aGF0IGhhdmluZyB0aGUgcmVz
b3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVyZSBpdHMgYXV0aG9yaXphdGlvbiBzZXJ2
ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBBdXRo
b3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIHNlcnZlciBuZWVkIHRvIGJlIGJvdW5k
IHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5DQogZW5kcG9pbnRzICh0aGUgcmVzb3Vy
Y2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2aWNlIGRpc2NvdmVyeSkuPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYSBjbGllbnQgZGlzY292ZXJz
IGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWluZyBmb3IgYSByZWFsIHJlc291
cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3aWxsIG5vdCBsZWFkIHRoZSBj
bGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJlc291cmNlIHNlcnZlci4gUmF0
aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0IGhhdmUNCiBhIGZha2UgZGlz
Y292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRlcmNlcHQgcmVzb3VyY2UgcGF5
bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2VyZSBhYmxlIHRvIGNvbnZpbmNl
IHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0aW9uIHNlcnZpY2UgYnV0IHVz
ZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9BdXRoIERpc2NvdmVyeSBz
ZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0aGF0IHRoZSBzZXJ2ZXIgaXMg
YWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291cmNlIGVuZHBvaW50LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG5v
dCBvbmx5IHdvcmtzIGluIG5vcm1hbCBPQXV0aCBidXQgc2hvdWxkIGFkZCBzZWN1cml0eSBldmVu
IHRvIFVNQSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w
cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnd3dy5pbmRlcGVuZGVudGlk
LmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3
NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZhbXA7c2RhdGE9TUpXcEZCMTJ2VExCNGVjS3lZd2xaTG5SSkluYU5FdzFNd2x2dFUy
NkJQQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208
L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAyNCwgMjAxNiwgYXQgMzo1NCBBTSwg
TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+
DQpIaSBUaG9tYXMsJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PmlubGluZTombmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+MjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj4oPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+KQ0KIDE4OjQ0IFRob21hcyBCcm95ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0
LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJyb3llckBnbWFpbC5jb208L2E+
Jmd0Ozo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln
aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPkNvdWxkbid0IHRoZSBkb2N1bWVudCBvbmx5IGRlc2NyaWJlIHRo
ZSBtZXRhZGF0YT88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBxdWl0ZSBsaWtlIHRoZSBpZGVhIG9mJm5ic3A7ZHJh
ZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZG8gZGlzY292ZXJ5
LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0byBvdGhlciBzcGVjcyB0byBk
ZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICZxdW90O2F1dG8tY29uZmlndXJhdGlvbiZxdW90
Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291bGQg
dGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMmbmJzcDtk
cmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRoZSBSUzsgb3IgYXMgYSBiYXNp
cyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UNCiBPcGVuSUQgQ29ubmVjdCkuJm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2l0aCZu
YnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAmcXVvdDtkdXJpJnF1b3Q7IGFuZCB0aGUg
JnF1b3Q7c2NvcGUmcXVvdDsgYXR0cmlidXRlIG9mIFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2Ug
aGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBuZWVkIHRvIHByb2NlZWQmbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+WXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1aXJlbWVudHMgdG8g
YmUgUkVTVGZ1bCwgaXMgaXQgbm90PyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5JbiBPQXV0aCdzIGNhc2UsIHRoZSByZXNvdXJjZSBhbmQgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0bHkgY291cGxlZC4gKE90aGVy
d2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4pJm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+U28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBl
aXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVk
IGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlv
biBvZiB0aGUNCiBhdXRoeiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNl
cywgeW91IGRvIG5vdCBoYXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5
b3Ugc2F5LiBUaGlzIGZyZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUg
bG9jYXRpb24gY29sbGlzaW9ucyBldGMuIFdlIHNob3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUg
dGhlIHVyaSBzcGFjZSBhcyBtdWNoIGFzIHBvc3NpYmxlLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4od2VsbCwgZXhjZXB0IGlmIHRo
ZXJlIGFyZSBzZXZlcmFsIEFTcyBlYWNoIHdpdGggZGlmZmVyZW50IHNjb3Blczsgc291bmRzIGxp
a2UgYW4gZWRnZS1jYXNlIHRvIG1lIHRob3VnaDsgbWF5YmUgUkZDNjc1MCBzaG91bGQgaW5zdGVh
ZCBiZSB1cGRhdGVkIHdpdGggc3VjaCBhIHBhcmFtZXRlciBzdWNoDQogdGhhdCBhbiBSUyBjb3Vs
ZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBpdHMg
b3duICZxdW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtkdXJpJnF1b3Q7IHZhbHVlPyk8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBlZGdlIGNhc2UuIEkgd291bGQg
cmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMgdG8gZGV2ZWxvcCBhIHRydXN0
IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBvbiBhIHNpbmdsZSBzZXQgb2Yg
Y29tbW9uIHNjb3BlIHBhcmFtZXRlcg0KIHZhbHVlcy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsJm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TmF0PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAx
MDo1OSBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1
IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo
ZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVudCBpcyBoZWxwZnVsIGFuZCBt
b3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywgaG93ZXZlciwgc3RpbGwgaGF2
ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5lY3Qgb3JpZ2lucy4gT25lDQog
aXNzdWUgaW4gcGFydGljdWxhciBzdGlsbCByZWFsbHkgYm90aGVycyBtZTogdGhlIHVzZSBvZiDi
gJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0gaW4gdGhlIGRpc2NvdmVyeSBw
b3J0aW9uLiBJcyB0aGlzIGFuIE9BdXRoIGRpc2NvdmVyeSBkb2N1bWVudCwgb3IgYW4gT3BlbklE
IENvbm5lY3Qgb25lPyBUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIGNvbXBlbGxpbmcgcmVhc29uIHRv
IHRpZSB0aGUgVVJMIHRvIHRoZSBPSURDIGRpc2NvdmVyeQ0KIG1lY2hhbmlzbS48YnI+DQo8YnI+
DQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRp
b24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5kIHN0YXRl
IHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8ud2VsbC1r
bm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28gcHJvdmlkZXMg
T3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlcg0KIGFwcGxpY2F0aW9ucyBT
SE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBPQXV0aCBlbmRw
b2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZpYyBkaXNjb3Zl
cnkgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A74oCUIEp1c3Rpbjxicj4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w
cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZt
YWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2eUJTS21j
czN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v
cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlz
dGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l
N2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3
TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PQXV0aEBp
ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9
Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz
JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2Rh
dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFh
ZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1w
O3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZCIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BY2PR03MB442E135F59374B40084665EF5A50BY2PR03MB442namprd_--


From nobody Wed Feb 24 13:25:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED511B408B for ; Wed, 24 Feb 2016 13:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvjjMFCda5Iu for ; Wed, 24 Feb 2016 13:24:57 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50A31B408F for ; Wed, 24 Feb 2016 13:24:56 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1OLOtP8010891 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 21:24:56 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1OLOtHv010279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 21:24:55 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1OLOs4M026301; Wed, 24 Feb 2016 21:24:54 GMT
Received: from [10.50.2.232] (/184.70.237.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 13:24:52 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-9E138965-0ACB-456D-8243-576997C9A3D6
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Wed, 24 Feb 2016 13:24:48 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <17E6C845-D633-45F6-A123-515437583F02@oracle.com>
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com> 
To: Mike Jones 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 21:25:01 -0000

--Apple-Mail-9E138965-0ACB-456D-8243-576997C9A3D6
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Where is the profile endpoint (oidc's resource server) published? (For the n=
on OIDC people on the list).=20

Phil

> On Feb 24, 2016, at 13:09, Mike Jones  wrote:=

>=20
> To the extent that generic OAuth 2.0 needs to publish some of the same inf=
ormation as OpenID Connect =E2=80=93 which is built on generic OAuth 2.0 =E2=
=80=93 it makes sense to publish that information using exactly the same syn=
tax, since that syntax is already in widespread use.  That what this draft a=
ccomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response val=
ues like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize",
>    "token_endpoint": "https://server.example.com/token",
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", "priva=
te_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register",
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": "http://server.example.com/service_documentati=
on.html",
> =20
> Is there a reason that you would like the syntax for any of these or the o=
ther generally applicable OAuth 2.0 metadata values to be different?  I don=E2=
=80=99t see any good reason for unnecessary differences to be introduced.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) that i=
s deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be appropriate f=
or oidc but it is not ready for generic oauth. There is no generic oauth exp=
erience at this time.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
>=20
> Sure there is, it is as you have now made it far easier and the security c=
onsiderations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective security=
 difference between discovery information being published in an ad-hoc fashi=
on on developer pages and it being published in a standard format.  =E2=80=9C=
Security by obscurity=E2=80=9D adds no real security at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> > The point of the WGLC is to finish standardizing the core discovery func=
tionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for OAuth. Th=
ere are some authentication mechanism discovery for endpoint that really sho=
uld not be in an OAuth standard since it=E2=80=99s really not dealt with. No=
w that all this information is available it makes poking around the endpoint=
 more focused for people that want to disrupt your endpoints, that is really=
 not addressed in the security considerations section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery functi=
onality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related functional=
ity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applicatio=
ns will use WebFinger to locate the discovery metadata.  Some will possibly u=
se link headers.  Some will possibly use application-specific .well-known va=
lues.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even t=
hought about.  All of these depend upon having a discovery metadata document=
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.
> =20
> So by all means, the working group should continue discussing inventing po=
ssible new related mechanisms that make sense in some contexts.  At the same=
 time, we can finish standardizing the already widely deployed core function=
ality that all of these mechanisms will need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the client i=
ndicating what resource endpoint it wants the oauth configuration data for.=20=

> =20
> So if res.example.evil.com is not a valid resource endpoint for as.example=
.com the authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change the o=
rder of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of authorizati=
on (the resource) is never specified. It is often bound up in the client reg=
istration and an often implied 1:1 relationship between resource and as. Giv=
en that in discovery phase registration has not yet occurred it seems import=
ant that the client know it has a valid combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a starting p=
oint for group adoption but we haven't really defined the full requirements I=
MO.=20
> =20
> I am on vacation or I would put some thought into some draft changes or a n=
ew draft. I apologize I can't do it now.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>=20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? Curren=
tly, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good RS, t=
he client will not send the token there as the authz server will say that is=
 not the place the client may want to send the token to.=20
>=20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client where=
 its authorization server is secure by itself. The relationship between the A=
uthorization Server and the Resource server need to be bound together in one=
 of the discovery endpoints (the resource and/or the oauth service discovery=
).
> =20
> If a client discovers a fake resource server that is proxying for a real r=
esource server the current discovery spec will not lead the client to unders=
tand it has the wrong resource server. Rather the fake resource service will=
 just have a fake discovery service. The hacker can now intercept resource p=
ayload as well as tokens because they were able to convince the client to us=
e the legit authorization service but use the token against the hackers prox=
y.
> =20
> The OAuth Discovery service needs to confirm to the client that the server=
 is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to UMA si=
tuations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> =20
> =20
> =20
>=20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
> =20
>=20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to d=
o discovery, and leave it open to implementers / to other specs to define a .=
well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, r=
eturned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for o=
ther metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-A=
uthenticate response header, you have everything you need to proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually tig=
htly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of the a=
uthz endpoint. In some trusted environment, the resource may as well return t=
he location of the authz server configuration data. In these cases, you do n=
ot have to decide on what .well-known uri as you say. This frees up develope=
rs from configuration file location collisions etc. We should strive not to p=
ollute the uri space as much as possible.=20
> =20
> (well, except if there are several ASs each with different scopes; sounds l=
ike an edge-case to me though; maybe RFC6750 should instead be updated with s=
uch a parameter such that an RS could return several WWW-Authenticate: Beare=
r, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these authz s=
ervers to develop a trust framework under which they can agree on a single s=
et of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
>=20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the ri=
ght direction. It does, however, still have too many vestiges of its OpenID C=
onnect origins. One issue in particular still really bothers me: the use of =E2=
=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery portion. I=
s this an OAuth discovery document, or an OpenID Connect one? There is absol=
utely no compelling reason to tie the URL to the OIDC discovery mechanism.
>=20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other applications SH=
OULD use the same parameter names to describe OAuth endpoints and functions i=
nside their service-specific discovery document.
>=20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-9E138965-0ACB-456D-8243-576997C9A3D6
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Where is the profile endpoint (oidc's r=
esource server) published? (For the non OIDC people on the list). 
<=
br>Phil

On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote=
:











To the extent that generic OAuth 2.0 ne=
eds to publish some of the same information as OpenID Connect =E2=80=93 whic=
h is built on generic OAuth 2.0 =E2=80=93 it makes sense to
 publish that information using exactly the same syntax, since that syntax i=
s already in widespread use.  That what this draft accomplishes.


 


There=E2=80=99s nothing Connect-specifi=
c about using metadata response values like:


 


   "authorization_endpoint": "=
https://server.example.com/=
authorize",


   "token_endpoint": "https://server.example.com/token",=



   "token_endpoint_auth_metho=
ds_supported": ["client_secret_basic", "private_key_jwt"],=



   "registration_endpoint": "=
https://server.example.com/r=
egister",


   "response_types_supported"=
:  ["code", "token"],


   "service_documentation": "=
http://serv=
er.example.com/service_documentation.html",


 


Is there a reason that you would like t=
he syntax for any of these or the other generally applicable OAuth 2.0 metad=
ata values to be different?  I don=E2=80=99t see any
 good reason for unnecessary differences to be introduced.=



 


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


 






From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]


Sent: Wednesday, February 24, 2016 12:45 PM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: Mike Jones <Mic=
hael.Jones@microsoft.com>; <oaut=
h@ietf.org> <oauth@ietf.org&=
gt;

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




Mike






 






Publishing on dev pages does not work for software (e=
sp open source) that is deployed both in enterprises and on PaaS cloud provi=
ders. 






 






The current draft is may codify current OIDC practice=
 and be appropriate for oidc but it is not ready for generic oauth. There is=
 no generic oauth experience at this time. 








Phil








On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> wrote:








Sure there is, it is as you have now ma=
de it far easier and the security considerations does not even address this<=
/span>


 







From: Mike Jones


Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


As we=E2=80=99d discussed in person, th=
ere=E2=80=99s no effective security difference between discovery information=
 being published in an ad-hoc fashion on developer pages and
 it being published in a standard format.  =E2=80=9CSecurity by obscuri=
ty=E2=80=9D adds no real security at all.


 


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


 






From: Anthony Nadalin


Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <Mic=
hael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


> The point of t=
he WGLC is to finish standardizing the core discovery functionality
 that=E2=80=99s already widely deployed.


 


That may be widely deployed for OIDC bu=
t not widely deployed for OAuth. There are some authentication mechanism dis=
covery for endpoint that really should not
 be in an OAuth standard since it=E2=80=99s really not dealt with. Now that a=
ll this information is available it makes poking around the endpoint more fo=
cused for people that want to disrupt your endpoints, that is really not add=
ressed in the security considerations
 section at all 


 






From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <phil.=
hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 


The point of the WGLC is to finish stan=
dardizing the core discovery functionality that=E2=80=99s already widely dep=
loyed.


 


None of Nat or John or I are suggesting=
 that additional related functionality won=E2=80=99t be created.  I=E2=80=
=99m sure it will be.  Some applications will use WebFinger to
 locate the discovery metadata.  Some will possibly use link headers.&n=
bsp; Some will possibly use application-specific .well-known values.  I=
=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even thought a=
bout.  All of these depend upon having a discovery metadata document
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.


 


So by all means, the working group shou=
ld continue discussing inventing possible new related mechanisms that make s=
ense in some contexts.  At the same time, we
 can finish standardizing the already widely deployed core functionality tha=
t all of these mechanisms will need.


 


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


 






From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <sakimura@g=
mail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




I am suggesting that part of the discovery solution h=
as to be the client indicating what resource endpoint it wants the oauth con=
figuration data for. 






 






So if 
res.example.evil.com is not a valid resource endpoint for 
as.example.com the authz discovery should fail in some way (eg return no=
thing). 






 






There may be better ways to do this. Eg combine disco=
very. Or change the order of discovery. 






 






One of OAuth's strength's and weaknesses is that the t=
arget of authorization (the resource) is never specified. It is often bound u=
p in the client registration and an often implied 1:1 relationship between r=
esource and as. Given that in
 discovery phase registration has not yet occurred it seems important that t=
he client know it has a valid combination of endpoints etc. =







 






This is why I was disappointed about wglc on discover=
y. We had a starting point for group adoption but we haven't really defined t=
he full requirements IMO. 






 






I am on vacation or I would put some thought into som=
e draft changes or a new draft. I apologize I can't do it now. 



Phil








On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:










Hi Phil, 




 






Are you suggesting that the AS metadata should includ=
e the RS URIs? Currently, it does not, but it can be done, I guess. 






 






The way oauth-meta works is that 
=






 






1. RS tells the client where the AS is. 






2. AS tells the client which RS endpoints the token c=
an be used. 






 






Even if there is a bad AS with a valid certs that pro=
xies to the good RS, the client will not send the token there as the authz s=
erver will say that is not the place the client may want to send the token t=
o. 










Nat






 






2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4=
) 23:59 Phil Hunt <phil.hu=
nt@oracle.com>:










Nat,






 




I=E2=80=99m not sure that having the resource server t=
ell the client where its authorization server is secure by itself. The relat=
ionship between the Authorization Server and the Resource server need to be b=
ound together in one of the discovery
 endpoints (the resource and/or the oauth service discovery).
=




 








If a client discovers a fake resource server that is p=
roxying for a real resource server the current discovery spec will not lead t=
he client to understand it has the wrong resource server. Rather the fake re=
source service will just have
 a fake discovery service. The hacker can now intercept resource payload as w=
ell as tokens because they were able to convince the client to use the legit=
 authorization service but use the token against the hackers proxy.






 






The OAuth Discovery service needs to confirm to the c=
lient that the server is able to issue tokens for a stated resource endpoint=
.






 






This not only works in normal OAuth but should add se=
curity even to UMA situations.






 


















Phil





 <=
/p>





@independentid











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





 <=
/p>





 <=
/p>



 
















 








On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> w=
rote:




 








Hi Thomas, 




 






inline: 






 






2016=E5=B9=B42=E6=9C=
=8822=E6=97=A5(=E6=9C=88)
 18:44 Thomas Broyer <t.broyer@gmail.com>:








Couldn't the document only describe the metadata?




I quite like the idea of draft-sakimura-oauth-m=
eta if you really want to do discovery, and leave it open to implementers / t=
o other specs to define a .well-known URL for "auto-configuration".






The metadata described here would then either be use=
d as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at t=
he RS; or as a basis for other metadata specs (like
 OpenID Connect). 
















With draft-sakimura-oauth-meta's "duri" and the=
 "scope" attribute of WWW-Authenticate response header, you have everything y=
ou need to proceed 












 






Yup. That's one of the requirements to be RESTful, i=
s it not?  






 






In OAuth's case, the resource and the authorization s=
erver are usually tightly coupled. (Otherwise, you need another specs like U=
MA.) 






So, the resource server should be able to tell eithe=
r the location of the authz endpoint. In some trusted environment, the resou=
rce may as well return the location of the
 authz server configuration data. In these cases, you do not have to decide o=
n what .well-known uri as you say. This frees up developers from configurati=
on file location collisions etc. We should strive not to pollute the uri spa=
ce as much as possible. 






 












(well, except if there are several ASs each with dif=
ferent scopes; sounds like an edge-case to me though; maybe RFC6750 should i=
nstead be updated with such a parameter such
 that an RS could return several WWW-Authenticate: Bearer, each with its own=
 "scope" and "duri" value?)












 






Yeah, I guess it is an edge case. I would rather lik=
e to see these authz servers to develop a trust framework under which they c=
an agree on a single set of common scope parameter
 values. 






 






Cheers, 






 






Nat






 












 






On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu> w=
rote:






The newly-trimmed OAuth Discovery document is helpfu=
l and moving in the right direction. It does, however, still have too many v=
estiges of its OpenID Connect origins. One
 issue in particular still really bothers me: the use of =E2=80=9C/.well-kno=
wn/openid-configuration=E2=80=9D in the discovery portion. Is this an OAuth d=
iscovery document, or an OpenID Connect one? There is absolutely no compelli=
ng reason to tie the URL to the OIDC discovery
 mechanism.



I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other
 applications SHOULD use the same parameter names to describe OAuth endpoint=
s and functions inside their service-specific discovery document.



 =E2=80=94 Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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










_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 



































=

--Apple-Mail-9E138965-0ACB-456D-8243-576997C9A3D6--


From nobody Wed Feb 24 14:05:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522F81B3DD4 for ; Wed, 24 Feb 2016 14:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 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_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 PHZr5DYy0YsC for ; Wed, 24 Feb 2016 14:05:27 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48841B3D8D for ; Wed, 24 Feb 2016 14:05:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gNTctZYmICGcvqb/YS/waQS5zVJHvK5BP1joB0B2oQg=; b=f6iQdjgsHCOZA0wkons8yI6PIIwFaaS+YsHN1bp6xH5GH2PU+Ski3U/fZpEuROySuMD5nmZOmcgA+w96q2HRv+HKiAUo3tHACnbtIS2oYnhsGR2izi83dCiFh9PHE2dL6E4i9bsj7aaRLPodrZ/9Iss6mdluAWN2yvAGyop0Jck=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 22:05:05 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 22:05:05 +0000
From: Mike Jones 
To: "Phil Hunt (IDM)" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKw
Date: Wed, 24 Feb 2016 22:05:04 +0000
Message-ID: 
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>
In-Reply-To: <17E6C845-D633-45F6-A123-515437583F02@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:2::7c0]
x-ms-office365-filtering-correlation-id: e2fad0eb-0cd0-47bf-bbab-08d33d668d34
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:9BJbRGa/gvAy9HjOitIPNUKxp6RNgidZo9g9eE7+jYQxK78+m/gG9Odo1aXzrn7x3GUrYQwUhfBejome6XnlofxKcjFzlcVLN53E0jSwwCMlQT2vHAISXrRbcV/wameM3kqdgtTRoWZfen430H1kxA==; 24:/1UzNDQQU04eKb9vszJqUC/jtrWik3rpnDQRNvNsDEDNej2A3bdt50JrX0mmsdithl4Udn6TzRRkpHmA2kGcvB7LhPXnlCwfMJZUllHPU5I=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(51914003)(10400500002)(11100500001)(5005710100001)(8990500004)(10290500002)(40100003)(2906002)(122556002)(10090500001)(5003600100002)(99286002)(54356999)(5002640100001)(19609705001)(5004730100002)(3280700002)(5008740100001)(1220700001)(1096002)(3660700001)(6116002)(790700001)(3900700001)(586003)(102836003)(4326007)(19580405001)(19580395003)(77096005)(74316001)(2900100001)(2950100001)(15975445007)(93886004)(19617315012)(76576001)(50986999)(92566002)(87936001)(106116001)(76176999)(86362001)(189998001)(5001960100002)(16236675004)(15395725005)(86612001)(19625215002)(110136002)(19300405004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442BA8094FF4718BCA93112F5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 22:05:04.6092 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 22:05:32 -0000

--_000_BY2PR03MB442BA8094FF4718BCA93112F5A50BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW4gT3BlbklEIENvbm5lY3QsIHRoZXJl4oCZcyBhIHJlc291cmNlIHNlcnZlciBjYWxsZWQgdGhl
IFVzZXJJbmZvIEVuZHBvaW50IHRoYXQgcmV0dXJucyBjbGFpbXMgYWJvdXQgdGhlIGF1dGhlbnRp
Y2F0ZWQgdXNlciBhcyBhIEpTT04gZGF0YSBzdHJ1Y3R1cmUuICBJdHMgbG9jYXRpb24gaXMgcHVi
bGlzaGVkIGluIE9wZW5JRCBDb25uZWN0IGRpc2NvdmVyeSBtZXRhZGF0YSBhcyB0aGUg4oCcdXNl
cmluZm9fZW5kcG9pbnTigJ0gbWV0YWRhdGEgdmFsdWUsIHdoaWNoIGlzIGRlZmluZWQgYXQgaHR0
cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1By
b3ZpZGVyTWV0YWRhdGEuDQoNCldlIGRpZG7igJl0IGluY2x1ZGUgdGhlIFVzZXJJbmZvIEVuZHBv
aW50IGluIHRoZSBnZW5lcmljIE9BdXRoIGRpc2NvdmVyeSBzcGVjIHNpbmNlIGluIE9BdXRoLCB0
aGVyZSBhcmUgbG90cyBvZiBwb3NzaWJsZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gYXV0aG9yaXph
dGlvbiBzZXJ2ZXJzIGFuZCByZXNvdXJjZSBzZXJ2ZXJzIGFuZCB0aGV5IG5lZWRu4oCZdCBiZSBv
bmUtdG8tb25lLCBhcyBpcyBiZWluZyBhY3RpdmVseSBkaXNjdXNzZWQgYnkgdGhlIHdvcmtpbmcg
Z3JvdXAuICBGb3IgaW5zdGFuY2UsIHNlZSBHZW9yZ2UgRmxldGNoZXLigJlzIHJlY2VudCBjb250
cmlidXRpb24uDQoNClRoYW5rcyBmb3IgdGhlIGdvb2QgZGlzY3Vzc2lvbiwgUGhpbC4NCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDE6MjUgUE0NClRv
OiBNaWtlIEpvbmVzDQpDYzogPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1X
R10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQpXaGVyZSBpcyB0aGUgcHJvZmlsZSBl
bmRwb2ludCAob2lkYydzIHJlc291cmNlIHNlcnZlcikgcHVibGlzaGVkPyAoRm9yIHRoZSBub24g
T0lEQyBwZW9wbGUgb24gdGhlIGxpc3QpLg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQg
MTM6MDksIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUbyB0aGUgZXh0ZW50IHRoYXQgZ2Vu
ZXJpYyBPQXV0aCAyLjAgbmVlZHMgdG8gcHVibGlzaCBzb21lIG9mIHRoZSBzYW1lIGluZm9ybWF0
aW9uIGFzIE9wZW5JRCBDb25uZWN0IOKAkyB3aGljaCBpcyBidWlsdCBvbiBnZW5lcmljIE9BdXRo
IDIuMCDigJMgaXQgbWFrZXMgc2Vuc2UgdG8gcHVibGlzaCB0aGF0IGluZm9ybWF0aW9uIHVzaW5n
IGV4YWN0bHkgdGhlIHNhbWUgc3ludGF4LCBzaW5jZSB0aGF0IHN5bnRheCBpcyBhbHJlYWR5IGlu
IHdpZGVzcHJlYWQgdXNlLiAgVGhhdCB3aGF0IHRoaXMgZHJhZnQgYWNjb21wbGlzaGVzLg0KDQpU
aGVyZeKAmXMgbm90aGluZyBDb25uZWN0LXNwZWNpZmljIGFib3V0IHVzaW5nIG1ldGFkYXRhIHJl
c3BvbnNlIHZhbHVlcyBsaWtlOg0KDQogICAiYXV0aG9yaXphdGlvbl9lbmRwb2ludCI6ICJodHRw
czovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRob3JpemUiLA0KICAgInRva2VuX2VuZHBvaW50Ijog
Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICJ0b2tlbl9lbmRwb2ludF9h
dXRoX21ldGhvZHNfc3VwcG9ydGVkIjogWyJjbGllbnRfc2VjcmV0X2Jhc2ljIiwgInByaXZhdGVf
a2V5X2p3dCJdLA0KICAgInJlZ2lzdHJhdGlvbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5l
eGFtcGxlLmNvbS9yZWdpc3RlciIsDQogICAicmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkIjogIFsi
Y29kZSIsICJ0b2tlbiJdLA0KICAgInNlcnZpY2VfZG9jdW1lbnRhdGlvbiI6ICJodHRwOi8vc2Vy
dmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sIiwNCg0KSXMgdGhlcmUg
YSByZWFzb24gdGhhdCB5b3Ugd291bGQgbGlrZSB0aGUgc3ludGF4IGZvciBhbnkgb2YgdGhlc2Ug
b3IgdGhlIG90aGVyIGdlbmVyYWxseSBhcHBsaWNhYmxlIE9BdXRoIDIuMCBtZXRhZGF0YSB2YWx1
ZXMgdG8gYmUgZGlmZmVyZW50PyAgSSBkb27igJl0IHNlZSBhbnkgZ29vZCByZWFzb24gZm9yIHVu
bmVjZXNzYXJ5IGRpZmZlcmVuY2VzIHRvIGJlIGludHJvZHVjZWQuDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl
DQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0K
U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMjo0NSBQTQ0KVG86IEFudGhvbnkg
TmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j
b20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1
dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KTWlr
ZQ0KDQpQdWJsaXNoaW5nIG9uIGRldiBwYWdlcyBkb2VzIG5vdCB3b3JrIGZvciBzb2Z0d2FyZSAo
ZXNwIG9wZW4gc291cmNlKSB0aGF0IGlzIGRlcGxveWVkIGJvdGggaW4gZW50ZXJwcmlzZXMgYW5k
IG9uIFBhYVMgY2xvdWQgcHJvdmlkZXJzLg0KDQpUaGUgY3VycmVudCBkcmFmdCBpcyBtYXkgY29k
aWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBhbmQgYmUgYXBwcm9wcmlhdGUgZm9yIG9pZGMgYnV0
IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJpYyBvYXV0aC4gVGhlcmUgaXMgbm8gZ2VuZXJpYyBv
YXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGltZS4NCg0KUGhpbA0KDQpPbiBGZWIgMjQsIDIwMTYs
IGF0IDEwOjI1LCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86
dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpTdXJlIHRoZXJlIGlzLCBpdCBpcyBhcyB5
b3UgaGF2ZSBub3cgbWFkZSBpdCBmYXIgZWFzaWVyIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJh
dGlvbnMgZG9lcyBub3QgZXZlbiBhZGRyZXNzIHRoaXMNCg0KRnJvbTogTWlrZSBKb25lcw0KU2Vu
dDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMDoyMiBBTQ0KVG86IEFudGhvbnkgTmFk
YWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+
Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0
Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9B
dXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KQXMgd2XigJlkIGRpc2N1c3NlZCBpbiBwZXJz
b24sIHRoZXJl4oCZcyBubyBlZmZlY3RpdmUgc2VjdXJpdHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGRp
c2NvdmVyeSBpbmZvcm1hdGlvbiBiZWluZyBwdWJsaXNoZWQgaW4gYW4gYWQtaG9jIGZhc2hpb24g
b24gZGV2ZWxvcGVyIHBhZ2VzIGFuZCBpdCBiZWluZyBwdWJsaXNoZWQgaW4gYSBzdGFuZGFyZCBm
b3JtYXQuICDigJxTZWN1cml0eSBieSBvYnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5
IGF0IGFsbC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluDQpTZW50OiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFl
bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+
PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50
QG9yYWNsZS5jb20+PjsgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNh
a2ltdXJhQGdtYWlsLmNvbT4+DQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz4+IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDog
UkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQo+IFRoZSBwb2lu
dCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBkaXNjb3Zl
cnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC4NCg0KVGhh
dCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVk
IGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2Nv
dmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBPQXV0aCBz
dGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwg
dGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0aGUg
ZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1cHQgeW91
ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5
IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYXQgYWxsDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5l
c2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTQ0KVG86IFBoaWwgSHVudCAoSURNKSA8cGhp
bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IE5hdCBTYWtp
bXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0KQ2M6
IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8
bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIu
MCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KVGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlz
aCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlz
IGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLg0KDQpOb25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJl
IHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0
IGJlIGNyZWF0ZWQuICBJ4oCZbSBzdXJlIGl0IHdpbGwgYmUuICBTb21lIGFwcGxpY2F0aW9ucyB3
aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuICBTb21l
IHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2Ug
YXBwbGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24gdmFsdWVzLiAgSeKAmW0gc3VyZSB0aGVy
ZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4gIEFsbCBv
ZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQg
Zm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5
IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy4NCg0KU28g
YnkgYWxsIG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2lu
ZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vu
c2UgaW4gc29tZSBjb250ZXh0cy4gIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGNhbiBmaW5pc2ggc3Rh
bmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5
IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2lsbCBuZWVkLg0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG
cm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ
aGlsIEh1bnQgKElETSkNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgODozOSBB
TQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8
b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FV
VEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KSSBhbSBzdWdnZXN0aW5nIHRo
YXQgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGlu
ZGljYXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmln
dXJhdGlvbiBkYXRhIGZvci4NCg0KU28gaWYgcmVzLmV4YW1wbGUuZXZpbC5jb208aHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnJl
cy5leGFtcGxlLmV2aWwuY29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29t
JTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9UGMlMmI3aWxuRFlnZmpZb1RzUVdvWm5wb2JHJTJiVkpw
NVd1OWNHcEZVZ3ozUzAlM2Q+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50IGZvciBh
cy5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwJTNhJTJmJTJmYXMuZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT02JTJicXhoJTJmN1ZDWmtz
d1hoSk12NnIlMmIxOGRUUmJnMklzMTJXQiUyZmRabTNjSjQlM2Q+IHRoZSBhdXRoeiBkaXNjb3Zl
cnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4NCg0KVGhlcmUg
bWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBPciBj
aGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4NCg0KT25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgn
cyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhl
IHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRo
ZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNo
aXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5IHBoYXNl
IHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhh
dCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5kcG9pbnRz
IGV0Yy4NCg0KVGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdnbGMgb24gZGlz
Y292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRpb24gYnV0IHdl
IGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElNTy4NCg0KSSBh
bSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21lIGRyYWZ0
IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQgbm93Lg0K
DQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6MTIsIE5hdCBTYWtpbXVyYSA8c2FraW11
cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFBoaWws
DQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5jbHVk
ZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBkb25l
LCBJIGd1ZXNzLg0KDQpUaGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdA0KDQoxLiBSUyB0
ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4NCjIuIEFTIHRlbGxzIHRoZSBjbGllbnQg
d2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4NCg0KRXZlbiBpZiB0aGVy
ZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29k
IFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRo
eiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdh
bnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uDQoNCk5hdA0KDQoyMDE25bm0MuaciDI05pelKOawtCkg
MjM6NTkgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+PjoNCk5hdCwNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJlc291
cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2VydmVy
IGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0aG9y
aXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3VuZCB0
b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNvdXJjZSBh
bmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KSWYgYSBjbGllbnQgZGlzY292
ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWluZyBmb3IgYSByZWFsIHJl
c291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3aWxsIG5vdCBsZWFkIHRo
ZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJlc291cmNlIHNlcnZlci4g
UmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0IGhhdmUgYSBmYWtlIGRp
c2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291cmNlIHBh
eWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBjb252aW5j
ZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIGJ1dCB1
c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuDQoNClRoZSBPQXV0aCBEaXNj
b3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgc2Vy
dmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBlbmRwb2lu
dC4NCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3VsZCBhZGQg
c2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRp
ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5jb20mZGF0
YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFk
NzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0
YT1NSldwRkIxMnZUTEI0ZWNLeVl3bFpMblJKSW5hTkV3MU13bHZ0VTI2QlBBJTNkPg0KcGhpbC5o
dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpPbiBG
ZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29t
PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpIaSBUaG9tYXMsDQoNCmlu
bGluZToNCg0KMjAxNuW5tDLmnIgyMuaXpSjmnIgpIDE4OjQ0IFRob21hcyBCcm95ZXIgPHQuYnJv
eWVyQGdtYWlsLmNvbTxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQpDb3VsZG4ndCB0aGUg
ZG9jdW1lbnQgb25seSBkZXNjcmliZSB0aGUgbWV0YWRhdGE/DQpJIHF1aXRlIGxpa2UgdGhlIGlk
ZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZG8g
ZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0byBvdGhlciBz
cGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICJhdXRvLWNvbmZpZ3VyYXRpb24i
Lg0KVGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJlIHVzZWQg
YXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEg
bWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBtZXRhZGF0YSBzcGVj
cyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuDQpXaXRoIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEn
cyAiZHVyaSIgYW5kIHRoZSAic2NvcGUiIGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGljYXRlIHJl
c3BvbnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9jZWVkDQoN
Cll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWwsIGlzIGl0
IG5vdD8NCg0KSW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlvdSBu
ZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKQ0KU28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hv
dWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRw
b2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdl
bGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRpb24g
ZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hhdCAu
d2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZyb20g
Y29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQgc3Ry
aXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0K
KHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVu
dCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJG
QzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3Vj
aCB0aGF0IGFuIFJTIGNvdWxkIHJldHVybiBzZXZlcmFsIFdXVy1BdXRoZW50aWNhdGU6IEJlYXJl
ciwgZWFjaCB3aXRoIGl0cyBvd24gInNjb3BlIiBhbmQgImR1cmkiIHZhbHVlPykNCg0KWWVhaCwg
SSBndWVzcyBpdCBpcyBhbiBlZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRo
ZXNlIGF1dGh6IHNlcnZlcnMgdG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGlj
aCB0aGV5IGNhbiBhZ3JlZSBvbiBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRl
ciB2YWx1ZXMuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0KT24gRnJpLCBGZWIgMTksIDIwMTYgYXQg
MTA6NTkgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1p
dC5lZHU+PiB3cm90ZToNClRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVu
dCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywg
aG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5l
Y3Qgb3JpZ2lucy4gT25lIGlzc3VlIGluIHBhcnRpY3VsYXIgc3RpbGwgcmVhbGx5IGJvdGhlcnMg
bWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlu
IHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0aCBkaXNjb3ZlcnkgZG9jdW1l
bnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhlcmUgaXMgYWJzb2x1dGVseSBubyBjb21w
ZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0aGUgT0lEQyBkaXNjb3ZlcnkgbWVjaGFu
aXNtLg0KDQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1dGhv
cml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5k
IHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8u
d2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28gcHJv
dmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlciBhcHBsaWNhdGlv
bnMgU0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGgg
ZW5kcG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlz
Y292ZXJ5IGRvY3VtZW50Lg0KDQog4oCUIEp1c3Rpbg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUy
Zm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcw
ZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0
NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0
JTNkPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B
dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEu
c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5p
ZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3Rvbnlu
YWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJT
S21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5m
byUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJh
NzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4
dGw0JTNkPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

--_000_BY2PR03MB442BA8094FF4718BCA93112F5A50BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg
MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6
MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7
DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA1IDMg
MiAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNYWxndW4gR290aGlj
IjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u
cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46
MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4
dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAubXNvbm9y
bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv
bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu
LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwOw0KCWZv
bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246
bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG
NDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU
ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs
bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw
dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu
MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj
dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm
YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv
OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh
W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r
PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBPcGVuSUQg
Q29ubmVjdCwgdGhlcmXigJlzIGEgcmVzb3VyY2Ugc2VydmVyIGNhbGxlZCB0aGUgVXNlckluZm8g
RW5kcG9pbnQgdGhhdCByZXR1cm5zIGNsYWltcyBhYm91dCB0aGUgYXV0aGVudGljYXRlZCB1c2Vy
IGFzIGEgSlNPTiBkYXRhIHN0cnVjdHVyZS4mbmJzcDsgSXRzIGxvY2F0aW9uDQogaXMgcHVibGlz
aGVkIGluIE9wZW5JRCBDb25uZWN0IGRpc2NvdmVyeSBtZXRhZGF0YSBhcyB0aGUg4oCcPC9zcGFu
PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+dXNlcmluZm9fZW5kcG9pbnQ8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnSBtZXRhZGF0YQ0K
IHZhbHVlLCB3aGljaCBpcyBkZWZpbmVkIGF0IDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3Nw
ZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCNQcm92aWRlck1ldGFkYXRhIj4N
Cmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRt
bCNQcm92aWRlck1ldGFkYXRhPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGRpZG7igJl0IGluY2x1ZGUgdGhl
IFVzZXJJbmZvIEVuZHBvaW50IGluIHRoZSBnZW5lcmljIE9BdXRoIGRpc2NvdmVyeSBzcGVjIHNp
bmNlIGluIE9BdXRoLCB0aGVyZSBhcmUgbG90cyBvZiBwb3NzaWJsZSByZWxhdGlvbnNoaXBzIGJl
dHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzDQogYW5kIHJlc291cmNlIHNlcnZlcnMgYW5kIHRo
ZXkgbmVlZG7igJl0IGJlIG9uZS10by1vbmUsIGFzIGlzIGJlaW5nIGFjdGl2ZWx5IGRpc2N1c3Nl
ZCBieSB0aGUgd29ya2luZyBncm91cC4mbmJzcDsgRm9yIGluc3RhbmNlLCBzZWUgR2VvcmdlIEZs
ZXRjaGVy4oCZcyByZWNlbnQgY29udHJpYnV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUg
Z29vZCBkaXNjdXNzaW9uLCBQaGlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGhpbCBIdW50IChJRE0pIFttYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBG
ZWJydWFyeSAyNCwgMjAxNiAxOjI1IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0K
PGI+Q2M6PC9iPiAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlcmUgaXMgdGhlIHByb2Zp
bGUgZW5kcG9pbnQgKG9pZGMncyByZXNvdXJjZSBzZXJ2ZXIpIHB1Ymxpc2hlZD8gKEZvciB0aGUg
bm9uIE9JREMgcGVvcGxlIG9uIHRoZSBsaXN0KS4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTM6MDksIE1pa2Ug
Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VG8gdGhlIGV4dGVudCB0aGF0IGdlbmVyaWMgT0F1dGgg
Mi4wIG5lZWRzIHRvIHB1Ymxpc2ggc29tZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBPcGVu
SUQgQ29ubmVjdCDigJMgd2hpY2ggaXMgYnVpbHQgb24gZ2VuZXJpYyBPQXV0aCAyLjAg4oCTIGl0
IG1ha2VzIHNlbnNlDQogdG8gcHVibGlzaCB0aGF0IGluZm9ybWF0aW9uIHVzaW5nIGV4YWN0bHkg
dGhlIHNhbWUgc3ludGF4LCBzaW5jZSB0aGF0IHN5bnRheCBpcyBhbHJlYWR5IGluIHdpZGVzcHJl
YWQgdXNlLiZuYnNwOyBUaGF0IHdoYXQgdGhpcyBkcmFmdCBhY2NvbXBsaXNoZXMuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYw
Ij5UaGVyZeKAmXMgbm90aGluZyBDb25uZWN0LXNwZWNpZmljIGFib3V0IHVzaW5nIG1ldGFkYXRh
IHJlc3BvbnNlIHZhbHVlcyBsaWtlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7ICZxdW90O2F1dGhv
cml6YXRpb25fZW5kcG9pbnQmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4
YW1wbGUuY29tL2F1dGhvcml6ZSI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXpl
PC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7ICZx
dW90O3Rva2VuX2VuZHBvaW50JnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5l
eGFtcGxlLmNvbS90b2tlbiI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW48L2E+JnF1
b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7dG9r
ZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCZxdW90OzogWyZxdW90O2NsaWVudF9z
ZWNyZXRfYmFzaWMmcXVvdDssICZxdW90O3ByaXZhdGVfa2V5X2p3dCZxdW90O10sPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyAmcXVvdDtyZWdpc3RyYXRpb25fZW5k
cG9pbnQmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Jl
Z2lzdGVyIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdpc3RlcjwvYT4mcXVvdDssPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyAmcXVvdDtyZXNwb25zZV90
eXBlc19zdXBwb3J0ZWQmcXVvdDs6Jm5ic3A7IFsmcXVvdDtjb2RlJnF1b3Q7LCAmcXVvdDt0b2tl
biZxdW90O10sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyAmcXVv
dDtzZXJ2aWNlX2RvY3VtZW50YXRpb24mcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHA6Ly9zZXJ2
ZXIuZXhhbXBsZS5jb20vc2VydmljZV9kb2N1bWVudGF0aW9uLmh0bWwiPmh0dHA6Ly9zZXJ2ZXIu
ZXhhbXBsZS5jb20vc2VydmljZV9kb2N1bWVudGF0aW9uLmh0bWw8L2E+JnF1b3Q7LDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2
MCI+SXMgdGhlcmUgYSByZWFzb24gdGhhdCB5b3Ugd291bGQgbGlrZSB0aGUgc3ludGF4IGZvciBh
bnkgb2YgdGhlc2Ugb3IgdGhlIG90aGVyIGdlbmVyYWxseSBhcHBsaWNhYmxlIE9BdXRoIDIuMCBt
ZXRhZGF0YSB2YWx1ZXMgdG8gYmUgZGlmZmVyZW50PyZuYnNwOyBJIGRvbuKAmXQgc2VlDQogYW55
IGdvb2QgcmVhc29uIGZvciB1bm5lY2Vzc2FyeSBkaWZmZXJlbmNlcyB0byBiZSBpbnRyb2R1Y2Vk
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+XQ0KPGJy
Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTI6NDUgUE08YnI+
DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRA
bWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8
L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVm
PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtl
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlB1Ymxpc2hpbmcg
b24gZGV2IHBhZ2VzIGRvZXMgbm90IHdvcmsgZm9yIHNvZnR3YXJlIChlc3Agb3BlbiBzb3VyY2Up
IHRoYXQgaXMgZGVwbG95ZWQgYm90aCBpbiBlbnRlcnByaXNlcyBhbmQgb24gUGFhUyBjbG91ZCBw
cm92aWRlcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFp
bFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRoZSBjdXJyZW50IGRyYWZ0IGlzIG1heSBjb2RpZnkgY3VycmVudCBPSURDIHByYWN0aWNl
IGFuZCBiZSBhcHByb3ByaWF0ZSBmb3Igb2lkYyBidXQgaXQgaXMgbm90IHJlYWR5IGZvciBnZW5l
cmljIG9hdXRoLiBUaGVyZSBpcyBubyBnZW5lcmljIG9hdXRoIGV4cGVyaWVuY2UgYXQgdGhpcyB0
aW1lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu
YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDEwOjI1LCBBbnRob255IE5hZGFsaW4g
Jmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9z
b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+U3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91IGhhdmUgbm93IG1hZGUgaXQgZmFyIGVh
c2llciBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvZXMgbm90IGV2ZW4gYWRkcmVz
cyB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt
ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiBNaWtlIEpvbmVzDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwg
MjAxNiAxMDoyMiBBTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVm
PSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+
Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+
b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
Ij5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgt
V0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzAwMjA2MCI+QXMgd2XigJlkIGRpc2N1c3NlZCBpbiBwZXJzb24sIHRoZXJl4oCZcyBubyBlZmZl
Y3RpdmUgc2VjdXJpdHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBi
ZWluZyBwdWJsaXNoZWQgaW4gYW4gYWQtaG9jIGZhc2hpb24gb24gZGV2ZWxvcGVyIHBhZ2VzDQog
YW5kIGl0IGJlaW5nIHB1Ymxpc2hlZCBpbiBhIHN0YW5kYXJkIGZvcm1hdC4mbmJzcDsg4oCcU2Vj
dXJpdHkgYnkgb2JzY3VyaXR54oCdIGFkZHMgbm8gcmVhbCBzZWN1cml0eSBhdCBhbGwuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAy
MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW50aG9ueSBOYWRhbGluDQo8YnI+
DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMDowMSBBTTxicj4N
CjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNA
bWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7IFBoaWwg
SHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGls
Lmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OyBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0
bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+
Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9y
ZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu
b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gT0F1dGggMi4w
IERpc2NvdmVyeSBMb2NhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4gVGhlIHBv
aW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2Nv
dmVyeQ0KIGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MDAyMDYwIj5UaGF0IG1heSBiZSB3aWRlbHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRl
bHkgZGVwbG95ZWQgZm9yIE9BdXRoLiBUaGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNo
YW5pc20gZGlzY292ZXJ5IGZvciBlbmRwb2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90DQogYmUg
aW4gYW4gT0F1dGggc3RhbmRhcmQgc2luY2UgaXTigJlzIHJlYWxseSBub3QgZGVhbHQgd2l0aC4g
Tm93IHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGl0IG1ha2VzIHBva2lu
ZyBhcm91bmQgdGhlIGVuZHBvaW50IG1vcmUgZm9jdXNlZCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0
byBkaXNydXB0IHlvdXIgZW5kcG9pbnRzLCB0aGF0IGlzIHJlYWxseSBub3QgYWRkcmVzc2VkIGlu
IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KIHNlY3Rpb24gYXQgYWxsIDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
Ij5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
Pk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAx
NiA5OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1h
aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozsg
TmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtp
bXVyYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0
bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZp
bmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTi
gJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYw
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Tm9uZSBvZiBOYXQgb3IgSm9o
biBvciBJIGFyZSBzdWdnZXN0aW5nIHRoYXQgYWRkaXRpb25hbCByZWxhdGVkIGZ1bmN0aW9uYWxp
dHkgd29u4oCZdCBiZSBjcmVhdGVkLiZuYnNwOyBJ4oCZbSBzdXJlIGl0IHdpbGwgYmUuJm5ic3A7
IFNvbWUgYXBwbGljYXRpb25zIHdpbGwgdXNlIFdlYkZpbmdlcg0KIHRvIGxvY2F0ZSB0aGUgZGlz
Y292ZXJ5IG1ldGFkYXRhLiZuYnNwOyBTb21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVy
cy4mbmJzcDsgU29tZSB3aWxsIHBvc3NpYmx5IHVzZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyAud2Vs
bC1rbm93biB2YWx1ZXMuJm5ic3A7IEnigJltIHN1cmUgdGhlcmXigJlzIG90aGVyIHRoaW5ncyBJ
IGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuJm5ic3A7IEFsbCBvZiB0aGVzZSBkZXBlbmQg
dXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQNCiBmb3JtYXQgYW5kIG5v
bmUgb2YgdGhlbSBjaGFuZ2UgaXQg4oCTIG90aGVyIHRoYW4gcG9zc2libHkgdG8gcmVnaXN0ZXIg
YWRkaXRpb25hbCBkaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+U28gYnkgYWxs
IG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZl
bnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4g
c29tZSBjb250ZXh0cy4mbmJzcDsgQXQgdGhlIHNhbWUgdGltZSwNCiB3ZSBjYW4gZmluaXNoIHN0
YW5kYXJkaXppbmcgdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0
eSB0aGF0IGFsbCBvZiB0aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN
aWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u
IEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50IChJRE0pPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh
eSwgRmVicnVhcnkgMjQsIDIwMTYgODozOSBBTTxicj4NCjxiPlRvOjwvYj4gTmF0IFNha2ltdXJh
ICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5j
b208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
T0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBzdWdnZXN0aW5nIHRoYXQg
cGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGluZGlj
YXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmlndXJh
dGlvbiBkYXRhIGZvci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBw
bGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U28gaWYgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnJlcy5leGFtcGxlLmV2aWwuY29tJmFtcDtk
YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFh
YWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFt
cDtzZGF0YT1QYyUyYjdpbG5EWWdmallvVHNRV29abnBvYkclMmJWSnA1V3U5Y0dwRlVnejNTMCUz
ZCI+DQpyZXMuZXhhbXBsZS5ldmlsLmNvbTwvYT4gaXMgbm90IGEgdmFsaWQgcmVzb3VyY2UgZW5k
cG9pbnQgZm9yIDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcy5leGFtcGxlLmNvbSZhbXA7ZGF0YT0wMSU3YzAx
JTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQz
N2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9NiUy
YnF4aCUyZjdWQ1prc3dYaEpNdjZyJTJiMThkVFJiZzJJczEyV0IlMmZkWm0zY0o0JTNkIj4NCmFz
LmV4YW1wbGUuY29tPC9hPiB0aGUgYXV0aHogZGlzY292ZXJ5IHNob3VsZCBmYWlsIGluIHNvbWUg
d2F5IChlZyByZXR1cm4gbm90aGluZykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIG1heSBiZSBiZXR0ZXIgd2F5cyB0byBkbyB0aGlzLiBF
ZyBjb21iaW5lIGRpc2NvdmVyeS4gT3IgY2hhbmdlIHRoZSBvcmRlciBvZiBkaXNjb3ZlcnkuJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiBP
QXV0aCdzIHN0cmVuZ3RoJ3MgYW5kIHdlYWtuZXNzZXMgaXMgdGhhdCB0aGUgdGFyZ2V0IG9mIGF1
dGhvcml6YXRpb24gKHRoZSByZXNvdXJjZSkgaXMgbmV2ZXIgc3BlY2lmaWVkLiBJdCBpcyBvZnRl
biBib3VuZCB1cCBpbiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgYW4gb2Z0ZW4gaW1wbGll
ZCAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gcmVzb3VyY2UgYW5kIGFzLiBHaXZlbiB0aGF0IGlu
DQogZGlzY292ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBz
ZWVtcyBpbXBvcnRhbnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmlu
YXRpb24gb2YgZW5kcG9pbnRzIGV0Yy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdn
bGMgb24gZGlzY292ZXJ5LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRp
b24gYnV0IHdlIGhhdmVuJ3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElN
Ty4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0
dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh
bSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21lIGRyYWZ0
IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQgbm93LiZu
YnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRmVi
IDI0LCAyMDE2LCBhdCAwODoxMiwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2Fr
aW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp
IFBoaWwsJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5BcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUg
dGhlIFJTIFVSSXM/IEN1cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwg
SSBndWVzcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIHdheSBvYXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQmbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gUlMgdGVs
bHMgdGhlIGNsaWVudCB3aGVyZSB0aGUgQVMgaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBBUyB0ZWxscyB0aGUgY2xpZW50IHdo
aWNoIFJTIGVuZHBvaW50cyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4gaWYgdGhlcmUg
aXMgYSBiYWQgQVMgd2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBS
UywgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHog
c2VydmVyIHdpbGwgc2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50
IHRvIHNlbmQgdGhlIHRva2VuIHRvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk5hdDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTY8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj7lubQ8L3NwYW4+MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1T
dW4iPuaciDwvc3Bhbj4yNDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuaXpTwvc3Bh
bj4oPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5rC0PC9zcGFuPikgMjM6NTkgUGhp
bCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVu
dEBvcmFjbGUuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5OYXQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNlcnZl
ciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNlY3Vy
ZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBT
ZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhlciBp
biBvbmUgb2YgdGhlIGRpc2NvdmVyeQ0KIGVuZHBvaW50cyAodGhlIHJlc291cmNlIGFuZC9vciB0
aGUgb2F1dGggc2VydmljZSBkaXNjb3ZlcnkpLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGEgY2xpZW50IGRpc2NvdmVycyBhIGZha2UgcmVz
b3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9yIGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIg
dGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBub3QgbGVhZCB0aGUgY2xpZW50IHRvIHVu
ZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJjZSBzZXJ2ZXIuIFJhdGhlciB0aGUgZmFr
ZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZlDQogYSBmYWtlIGRpc2NvdmVyeSBzZXJ2
aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2Vs
bCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50
IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2Vu
IGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVk
cyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8gaXNz
dWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBub3Qgb25seSB3b3Jr
cyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0
dWF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPlBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v
dXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Rh
dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFh
ZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1w
O3NkYXRhPU1KV3BGQjEydlRMQjRlY0t5WXdsWkxuUkpJbmFORXcxTXdsdnRVMjZCUEElM2QiIHRh
cmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh
Y2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVy
YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy
Pg0KSGkgVGhvbWFzLCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pbmxpbmU6Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDE2
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFs
Z3VuIEdvdGhpYyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lubQ8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIyPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdv
dGhpYyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+KDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPikNCiAxODo0NCBUaG9t
YXMgQnJveWVyICZsdDs8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIiB0YXJnZXQ9
Il9ibGFuayI+dC5icm95ZXJAZ21haWwuY29tPC9hPiZndDs6PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5Db3VsZG4ndCB0aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0aGUgbWV0YWRhdGE/PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgcXVpdGUgbGlrZSB0aGUgaWRlYSBvZiZuYnNwO2RyYWZ0
LXNha2ltdXJhLW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRpc2NvdmVyeSwg
YW5kIGxlYXZlIGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3BlY3MgdG8gZGVm
aW5lIGEgLndlbGwta25vd24gVVJMIGZvcg0KICZxdW90O2F1dG8tY29uZmlndXJhdGlvbiZxdW90
Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgbWV0YWRhdGEgZGVzY3JpYmVk
IGhlcmUgd291bGQgdGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJu
ZWQgYXMmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRoZSBSUzsg
b3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MNCiAobGlrZSBPcGVuSUQgQ29u
bmVjdCkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+V2l0aCZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAm
cXVvdDtkdXJpJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsgYXR0cmlidXRlIG9mIFdX
Vy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBu
ZWVkIHRvIHByb2NlZWQmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+WXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1aXJlbWVudHMgdG8gYmUgUkVTVGZ1
bCwgaXMgaXQgbm90PyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiBPQXV0aCdzIGNhc2UsIHRoZSBy
ZXNvdXJjZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0bHkg
Y291cGxlZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4pJm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28sIHRoZSByZXNvdXJjZSBzZXJ2
ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRo
eiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5
IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUNCiBhdXRoeiBzZXJ2ZXIgY29uZmln
dXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBoYXZlIHRvIGRlY2lkZSBv
biB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZyZWVzIHVwIGRldmVsb3Bl
cnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlzaW9ucyBldGMuIFdlIHNo
b3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBhcyBtdWNoIGFzIHBvc3Np
YmxlLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4od2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFy
ZSBzZXZlcmFsIEFTcyBlYWNoIHdpdGggZGlmZmVyZW50IHNjb3Blczsgc291bmRzIGxpa2UgYW4g
ZWRnZS1jYXNlIHRvIG1lIHRob3VnaDsgbWF5YmUgUkZDNjc1MCBzaG91bGQgaW5zdGVhZCBiZSB1
cGRhdGVkIHdpdGggc3VjaCBhIHBhcmFtZXRlciBzdWNoDQogdGhhdCBhbiBSUyBjb3VsZCByZXR1
cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBpdHMgb3duICZx
dW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtkdXJpJnF1b3Q7IHZhbHVlPyk8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBl
ZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMg
dG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBv
biBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlDQogcGFyYW1ldGVyIHZhbHVlcy4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5DaGVlcnMsJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TmF0PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0
aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9i
bGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRo
ZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVudCBpcyBoZWxwZnVsIGFuZCBt
b3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywgaG93ZXZlciwgc3RpbGwgaGF2
ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5lY3Qgb3JpZ2lucy4gT25lDQog
aXNzdWUgaW4gcGFydGljdWxhciBzdGlsbCByZWFsbHkgYm90aGVycyBtZTogdGhlIHVzZSBvZiDi
gJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0gaW4gdGhlIGRpc2NvdmVyeSBw
b3J0aW9uLiBJcyB0aGlzIGFuIE9BdXRoIGRpc2NvdmVyeSBkb2N1bWVudCwgb3IgYW4gT3BlbklE
IENvbm5lY3Qgb25lPyBUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIGNvbXBlbGxpbmcgcmVhc29uIHRv
IHRpZSB0aGUgVVJMIHRvIHRoZSBPSURDIGRpc2NvdmVyeQ0KIG1lY2hhbmlzbS48YnI+DQo8YnI+
DQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRp
b24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5kIHN0YXRl
IHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8ud2VsbC1r
bm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28gcHJvdmlkZXMg
T3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlcg0KIGFwcGxpY2F0aW9ucyBT
SE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBPQXV0aCBlbmRw
b2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZpYyBkaXNjb3Zl
cnkgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A74oCUIEp1c3Rpbjxicj4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w
cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZt
YWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2eUJTS21j
czN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w
cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZt
YWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2eUJTS21j
czN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4N
Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm
d3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2Mw
MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0
MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWdv
MUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZCIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BY2PR03MB442BA8094FF4718BCA93112F5A50BY2PR03MB442namprd_--


From nobody Wed Feb 24 14:13:12 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C531B2D0D for ; Wed, 24 Feb 2016 14:13:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSnUtT8cTzw2 for ; Wed, 24 Feb 2016 14:13:04 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8ED1B137B for ; Wed, 24 Feb 2016 14:13:04 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1OMD2Tg006832 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Feb 2016 22:13:03 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1OMD2iY025094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 22:13:02 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1OMCuYC020236; Wed, 24 Feb 2016 22:13:01 GMT
Received: from [25.173.73.160] (/24.114.27.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 14:12:55 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-C186A044-0F4A-498C-A471-34E58FBABBA7
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Wed, 24 Feb 2016 14:12:47 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0@oracle.com>
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com> 
To: Mike Jones 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 22:13:10 -0000

--Apple-Mail-C186A044-0F4A-498C-A471-34E58FBABBA7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yup. And because there many relations the client mist be able to discover it=
. The client does not know if the res server is legit.=20

The userinfo is always fix and so u dont need discovery.=20

Phil

> On Feb 24, 2016, at 14:05, Mike Jones  wrote:=

>=20
> In OpenID Connect, there=E2=80=99s a resource server called the UserInfo E=
ndpoint that returns claims about the authenticated user as a JSON data stru=
cture.  Its location is published in OpenID Connect discovery metadata as th=
e =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is defined at ht=
tp://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
> =20
> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth disco=
very spec since in OAuth, there are lots of possible relationships between a=
uthorization servers  and resource servers and they needn=E2=80=99t be one-t=
o-one, as is being actively discussed by the working group.  For instance, s=
ee George Fletcher=E2=80=99s recent contribution.
> =20
> Thanks for the good discussion, Phil.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Where is the profile endpoint (oidc's resource server) published? (For the=
 non OIDC people on the list).=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:=

>=20
> To the extent that generic OAuth 2.0 needs to publish some of the same inf=
ormation as OpenID Connect =E2=80=93 which is built on generic OAuth 2.0 =E2=
=80=93 it makes sense to publish that information using exactly the same syn=
tax, since that syntax is already in widespread use.  That what this draft a=
ccomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response val=
ues like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize",
>    "token_endpoint": "https://server.example.com/token",
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", "priva=
te_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register",
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": "http://server.example.com/service_documentati=
on.html",
> =20
> Is there a reason that you would like the syntax for any of these or the o=
ther generally applicable OAuth 2.0 metadata values to be different?  I don=E2=
=80=99t see any good reason for unnecessary differences to be introduced.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) that i=
s deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be appropriate f=
or oidc but it is not ready for generic oauth. There is no generic oauth exp=
erience at this time.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
>=20
> Sure there is, it is as you have now made it far easier and the security c=
onsiderations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective security=
 difference between discovery information being published in an ad-hoc fashi=
on on developer pages and it being published in a standard format.  =E2=80=9C=
Security by obscurity=E2=80=9D adds no real security at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> > The point of the WGLC is to finish standardizing the core discovery func=
tionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for OAuth. Th=
ere are some authentication mechanism discovery for endpoint that really sho=
uld not be in an OAuth standard since it=E2=80=99s really not dealt with. No=
w that all this information is available it makes poking around the endpoint=
 more focused for people that want to disrupt your endpoints, that is really=
 not addressed in the security considerations section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery functi=
onality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related functional=
ity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applicatio=
ns will use WebFinger to locate the discovery metadata.  Some will possibly u=
se link headers.  Some will possibly use application-specific .well-known va=
lues.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even t=
hought about.  All of these depend upon having a discovery metadata document=
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.
> =20
> So by all means, the working group should continue discussing inventing po=
ssible new related mechanisms that make sense in some contexts.  At the same=
 time, we can finish standardizing the already widely deployed core function=
ality that all of these mechanisms will need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the client i=
ndicating what resource endpoint it wants the oauth configuration data for.=20=

> =20
> So if res.example.evil.com is not a valid resource endpoint for as.example=
.com the authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change the o=
rder of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of authorizati=
on (the resource) is never specified. It is often bound up in the client reg=
istration and an often implied 1:1 relationship between resource and as. Giv=
en that in discovery phase registration has not yet occurred it seems import=
ant that the client know it has a valid combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a starting p=
oint for group adoption but we haven't really defined the full requirements I=
MO.=20
> =20
> I am on vacation or I would put some thought into some draft changes or a n=
ew draft. I apologize I can't do it now.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>=20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? Curren=
tly, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good RS, t=
he client will not send the token there as the authz server will say that is=
 not the place the client may want to send the token to.=20
>=20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client where=
 its authorization server is secure by itself. The relationship between the A=
uthorization Server and the Resource server need to be bound together in one=
 of the discovery endpoints (the resource and/or the oauth service discovery=
).
> =20
> If a client discovers a fake resource server that is proxying for a real r=
esource server the current discovery spec will not lead the client to unders=
tand it has the wrong resource server. Rather the fake resource service will=
 just have a fake discovery service. The hacker can now intercept resource p=
ayload as well as tokens because they were able to convince the client to us=
e the legit authorization service but use the token against the hackers prox=
y.
> =20
> The OAuth Discovery service needs to confirm to the client that the server=
 is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to UMA si=
tuations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> =20
> =20
> =20
>=20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
> =20
>=20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to d=
o discovery, and leave it open to implementers / to other specs to define a .=
well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, r=
eturned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for o=
ther metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-A=
uthenticate response header, you have everything you need to proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually tig=
htly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of the a=
uthz endpoint. In some trusted environment, the resource may as well return t=
he location of the authz server configuration data. In these cases, you do n=
ot have to decide on what .well-known uri as you say. This frees up develope=
rs from configuration file location collisions etc. We should strive not to p=
ollute the uri space as much as possible.=20
> =20
> (well, except if there are several ASs each with different scopes; sounds l=
ike an edge-case to me though; maybe RFC6750 should instead be updated with s=
uch a parameter such that an RS could return several WWW-Authenticate: Beare=
r, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these authz s=
ervers to develop a trust framework under which they can agree on a single s=
et of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
>=20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the ri=
ght direction. It does, however, still have too many vestiges of its OpenID C=
onnect origins. One issue in particular still really bothers me: the use of =E2=
=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery portion. I=
s this an OAuth discovery document, or an OpenID Connect one? There is absol=
utely no compelling reason to tie the URL to the OIDC discovery mechanism.
>=20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other applications SH=
OULD use the same parameter names to describe OAuth endpoints and functions i=
nside their service-specific discovery document.
>=20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-C186A044-0F4A-498C-A471-34E58FBABBA7
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Yup. And because there many relations t=
he client mist be able to discover it. The client does not know if the res s=
erver is legit. 

The userinfo is always fix and so u dont need discovery=
. 

Phil

On Feb 24, 2016, at 14:05, Mike Jones <=
Michael.Jones@microsoft.com> wrote:











In OpenID Connect, there=E2=
=80=99s a resource server called the UserInfo Endpoint that returns claims a=
bout the authenticated user as a JSON data structure.  Its location
 is published in OpenID Connect discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D m=
etadata
 value, which is defined at 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.


 

We didn=E2=80=99t include t=
he UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, the=
re are lots of possible relationships between authorization servers
 and resource servers and they needn=E2=80=99t be one-to-one, as is being ac=
tively discussed by the working group.  For instance, see George Fletch=
er=E2=80=99s recent contribution.


 

Thanks for the good discuss=
ion, Phil.


 

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


 



 




Where is the profile endpoint (oidc's resource server=
) published? (For the non OIDC people on the list). 



Phil








On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:








To the extent that generic O=
Auth 2.0 needs to publish some of the same information as OpenID Connect =E2=
=80=93 which is built on generic OAuth 2.0 =E2=80=93 it makes sense
 to publish that information using exactly the same syntax, since that synta=
x is already in widespread use.  That what this draft accomplishes.


 

There=E2=80=99s nothing Con=
nect-specific about using metadata response values like:

 

   "authorization=
_endpoint": "https://server=
.example.com/authorize",


   "token_endpoin=
t": "https://server.example.com=
/token",


   "token_endpoin=
t_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],


   "registration_=
endpoint": "https://server.e=
xample.com/register",


   "response_type=
s_supported":  ["code", "token"],


   "service_docum=
entation": "http://server.example.com/service_documentation.html",


 

Is there a reason that you w=
ould like the syntax for any of these or the other generally applicable OAut=
h 2.0 metadata values to be different?  I don=E2=80=99t see
 any good reason for unnecessary differences to be introduced.


 

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

 



 




Mike






 






Publishing on dev pages does not work for software (e=
sp open source) that is deployed both in enterprises and on PaaS cloud provi=
ders. 






 






The current draft is may codify current OIDC practice=
 and be appropriate for oidc but it is not ready for generic oauth. There is=
 no generic oauth experience at this time. 








Phil








On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> wrote:








Sure there is, it is as you=
 have now made it far easier and the security considerations does not even a=
ddress this


 






From: Mike Jone=
s


Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


As we=E2=80=99d discussed i=
n person, there=E2=80=99s no effective security difference between discovery=
 information being published in an ad-hoc fashion on developer pages
 and it being published in a standard format.  =E2=80=9CSecurity by obs=
curity=E2=80=9D adds no real security at all.


 

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


 





From: Anthony N=
adalin


Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <Mic=
hael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


> The point of the WGLC is to finish standardizing the core discove=
ry
 functionality that=E2=80=99s already widely deployed.
=


 

That may be widely deployed=
 for OIDC but not widely deployed for OAuth. There are some authentication m=
echanism discovery for endpoint that really should not
 be in an OAuth standard since it=E2=80=99s really not dealt with. Now that a=
ll this information is available it makes poking around the endpoint more fo=
cused for people that want to disrupt your endpoints, that is really not add=
ressed in the security considerations
 section at all 


 





From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <phil.=
hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 


The point of the WGLC is to=
 finish standardizing the core discovery functionality that=E2=80=99s alread=
y widely deployed.


 

None of Nat or John or I ar=
e suggesting that additional related functionality won=E2=80=99t be created.=
  I=E2=80=99m sure it will be.  Some applications will use WebFing=
er
 to locate the discovery metadata.  Some will possibly use link headers=
.  Some will possibly use application-specific .well-known values. =
; I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even thoug=
ht about.  All of these depend upon having a discovery metadata documen=
t
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.


 

So by all means, the workin=
g group should continue discussing inventing possible new related mechanisms=
 that make sense in some contexts.  At the same time,
 we can finish standardizing the already widely deployed core functionality t=
hat all of these mechanisms will need.


 

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


 





From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <sakimura@g=
mail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




I am suggesting that part of the discovery solution h=
as to be the client indicating what resource endpoint it wants the oauth con=
figuration data for. 






 






So if 
res.example.evil.com is not a valid resource endpoint for 
as.example.com the authz discovery should fail in some way (eg return no=
thing). 






 






There may be better ways to do this. Eg combine disco=
very. Or change the order of discovery. 






 






One of OAuth's strength's and weaknesses is that the t=
arget of authorization (the resource) is never specified. It is often bound u=
p in the client registration and an often implied 1:1 relationship between r=
esource and as. Given that in
 discovery phase registration has not yet occurred it seems important that t=
he client know it has a valid combination of endpoints etc. =







 






This is why I was disappointed about wglc on discover=
y. We had a starting point for group adoption but we haven't really defined t=
he full requirements IMO. 






 






I am on vacation or I would put some thought into som=
e draft changes or a new draft. I apologize I can't do it now. 



Phil








On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:










Hi Phil, 




 






Are you suggesting that the AS metadata should includ=
e the RS URIs? Currently, it does not, but it can be done, I guess. 






 






The way oauth-meta works is that 
=






 






1. RS tells the client where the AS is. 






2. AS tells the client which RS endpoints the token c=
an be used. 






 






Even if there is a bad AS with a valid certs that pro=
xies to the good RS, the client will not send the token there as the authz s=
erver will say that is not the place the client may want to send the token t=
o. 










Nat






 






2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4=
) 23:59 Phil Hunt <phil.hu=
nt@oracle.com>:










Nat,






 




I=E2=80=99m not sure that having the resource server t=
ell the client where its authorization server is secure by itself. The relat=
ionship between the Authorization Server and the Resource server need to be b=
ound together in one of the discovery
 endpoints (the resource and/or the oauth service discovery).
=




 








If a client discovers a fake resource server that is p=
roxying for a real resource server the current discovery spec will not lead t=
he client to understand it has the wrong resource server. Rather the fake re=
source service will just have
 a fake discovery service. The hacker can now intercept resource payload as w=
ell as tokens because they were able to convince the client to use the legit=
 authorization service but use the token against the hackers proxy.






 






The OAuth Discovery service needs to confirm to the c=
lient that the server is able to issue tokens for a stated resource endpoint=
.






 






This not only works in normal OAuth but should add se=
curity even to UMA situations.






 


















Phil





 <=
/p>





@independentid











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





 <=
/p>





 <=
/p>



 
















 








On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> w=
rote:




 








Hi Thomas, 




 






inline: 






 






2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=
=9C=88)
 18:44 Thomas Broyer <t.broyer@gmail.com>:








Couldn't the document only describe the m=
etadata?




I quite like the idea of draft-saki=
mura-oauth-meta if you really want to do discovery, and leave it open to imp=
lementers / to other specs to define a .well-known URL for
 "auto-configuration".






The metadata described here would then e=
ither be used as-is, at any URL, returned as draft-sakimura-oauth-meta m=
etadata at the RS; or as a basis for other metadata specs
 (like OpenID Connect). 
















With draft-sakimura-oauth-meta's "d=
uri" and the "scope" attribute of WWW-Authenticate response header, you have=
 everything you need to proceed 












 






Yup. That's one of the requirements to b=
e RESTful, is it not?  






 






In OAuth's case, the resource and the au=
thorization server are usually tightly coupled. (Otherwise, you need another=
 specs like UMA.) 






So, the resource server should be able t=
o tell either the location of the authz endpoint. In some trusted environmen=
t, the resource may as well return the location of the
 authz server configuration data. In these cases, you do not have to decide o=
n what .well-known uri as you say. This frees up developers from configurati=
on file location collisions etc. We should strive not to pollute the uri spa=
ce as much as possible. 






 












(well, except if there are several ASs e=
ach with different scopes; sounds like an edge-case to me though; maybe RFC6=
750 should instead be updated with such a parameter such
 that an RS could return several WWW-Authenticate: Bearer, each with its own=
 "scope" and "duri" value?)












 






Yeah, I guess it is an edge case. I woul=
d rather like to see these authz servers to develop a trust framework under w=
hich they can agree on a single set of common scope
 parameter values. 






 






Cheers, 






 






Nat






 












 






On Fri, Feb 19, 2016 at 10:59 PM Justin R=
icher <jricher@mit.e=
du> wrote:






The newly-trimmed OAuth Discovery docume=
nt is helpful and moving in the right direction. It does, however, still hav=
e too many vestiges of its OpenID Connect origins. One
 issue in particular still really bothers me: the use of =E2=80=9C/.well-kno=
wn/openid-configuration=E2=80=9D in the discovery portion. Is this an OAuth d=
iscovery document, or an OpenID Connect one? There is absolutely no compelli=
ng reason to tie the URL to the OIDC discovery
 mechanism.



I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other
 applications SHOULD use the same parameter names to describe OAuth endpoint=
s and functions inside their service-specific discovery document.



 =E2=80=94 Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












________________________________________=
_______

OAuth mailing list

OAuth@ietf.org

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










________________________________________=
_______

OAuth mailing list

OAut=
h@ietf.org

https://www.ietf.org/mailman/listinfo/oau=
th








 






























_______________________________________________

OAuth mailing list

OAuth@ietf.org

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














=

--Apple-Mail-C186A044-0F4A-498C-A471-34E58FBABBA7--


From nobody Wed Feb 24 14:57:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0071A1BDF for ; Wed, 24 Feb 2016 14:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QARwf58d-UKl for ; Wed, 24 Feb 2016 14:57:47 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAB31A1BDB for ; Wed, 24 Feb 2016 14:57:47 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id e127so20890038pfe.3 for ; Wed, 24 Feb 2016 14:57:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=F3k9MIqS73Cde7Yk+2ihSrrLkioyJjIYB+Iulr5JFoE=; b=ehxzXzb89f2G+qbjc58tm0DpUY8hhaFvqPXWbuRZ9GH6T0MM+lsnCMZG8P450h53dT PisJ4fGrA9QQARvDGUhHgR+HA3AslxkQkhlb1EwNJ7l4e60enIL7PGtM5EFItQzMuci7 GLmpIyYYqGxk8Yu9GQk8kql2/WtSuF/XowtVwNrLNfmQGJ+m9GXJuKtyn2NRvKXTUDag evYWek0IUVMR+aXDXKHQBea+iJOiAYPTKIBJX9S4NUBatp0lX039SyEe1XPaFfgnFXd0 nKgJj/o/AO7BxQ34bMHXlyoGm0V63kajIcRqLe4/6H55BVfQzgZTEhyWfDeRwsqyaZIN jORw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=F3k9MIqS73Cde7Yk+2ihSrrLkioyJjIYB+Iulr5JFoE=; b=VjQVj5aUIVWQ2kx84zQygobfFvAENOtwpS+fKgMgnx+oZ65KOAeyMcVhg5nCW197I5 tCYaoBvMM10MwfNStJJiZcDNgrKI30b0qbwjvC4CceBOP3lhy8UFE7wjCrtbKZ5WvgcJ kLbGaldJSvCIBq0SzWx/hEXGekv1E3wswIpbq9Jrr4LkwZZYfjJ8JpW3IM1Z1kaNQQOl FIbrzaceJCV8J8lzef/4eyxvmQMB0Wj/i+ufu+TET/8/sn9ykWB7P13CAVWbsUKxuNeh DzR1txZQdN8PaLPjC5ful2f09F12PxlC0qPT3TIImJW9cQ67/RbL2p6TCs/l+ap4jN1Y VPYw==
X-Gm-Message-State: AG10YOTS7gEMdHwYs6rvExGzaUbMewoJe7jClB+iC/V06x6c3Ea7kYUUSFp+/4tELBKnsw==
X-Received: by 10.98.89.215 with SMTP id k84mr58692971pfj.66.1456354667129; Wed, 24 Feb 2016 14:57:47 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id y15sm7329280pfi.16.2016.02.24.14.57.45 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 14:57:45 -0800 (PST)
From: "Brock Allen" 
To: 
Date: Wed, 24 Feb 2016 17:57:31 -0500
Message-ID: <00ac01d16f56$beb8aea0$3c2a0be0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01D16F2C.D5E369F0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFvUfX0nBCEzmjTTWqNfCRXc7exbw==
Content-Language: en-us
Archived-At: 
Subject: [OAUTH-WG] HTTP signing spec typo
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 22:57:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00AD_01D16F2C.D5E369F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In section 3.2 under calculating header list hash, there's an example of
hashed headers. For the values:

 

content-type: application/json

etag: 742-3u8f34-3r2nvv3

 

this is shown as the example:

 

"h": [["content-type", "etag"],
"bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI"]

 

I believe the hashed value is incorrect. The hash above is correct if the
headers use "\r\n" as the separator, but the spec says to only use "\n". If
only "\n" is used as the separator then (from my calculations) the hash
value should be "P6z5XN4tTzHkfwe3XO1YvVUIurSuhvh_UG10N_j-aGs". 

 

I'd love to get confirmation if I'm right/wrong. If I get a +1, then I'll
submit a PR to the spec in Justin's repo (unless he beats me to it).

 

One additional comment: It was not explicit in the spec that text encodings
should be ASCII. It might be helpful to make that explicit, as I incorrectly
assumed UTF8 (and spun my wheels for an hour or so).

 

Also, FWIW, I'm working on (well really, almost done with) a .NET
implementation of this spec. I'd love to know how much churn we expect on
the RFC. Also working with me on this is Dominick who adding the PoP support
to our IdentityServer3 implementation.

 

Thanks!

 

-Brock

 


------=_NextPart_000_00AD_01D16F2C.D5E369F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


In section 3.2 =
under calculating header list hash, there’s an example of hashed =
headers. For the values:
 
content-type: =
application/json
etag: =
742-3u8f34-3r2nvv3
 
this is shown as =
the example:
 
"h": =
[["content-type", "etag"], =
"bZA981YJBrPlIzOvplbu3e7ueREXXr38vSkxIBYOaxI"]
 
I believe the =
hashed value is incorrect. The hash above is correct if the headers use =
“\r\n” as the separator, but the spec says to only use =
“\n”. If only “\n” is used as the separator then =
(from my calculations) the hash value should be =
“P6z5XN4tTzHkfwe3XO1YvVUIurSuhvh_UG10N_j-aGs”. =

 
I’d love to =
get confirmation if I’m right/wrong. If I get a +1, then =
I’ll submit a PR to the spec in Justin’s repo (unless he =
beats me to it).
 
One additional =
comment: It was not explicit in the spec that text encodings should be =
ASCII. It might be helpful to make that explicit, as I incorrectly =
assumed UTF8 (and spun my wheels for an hour or =
so).
 
Also, FWIW, =
I’m working on (well really, almost done with) a .NET =
implementation of this spec. I’d love to know how much churn we =
expect on the RFC. Also working with me on this is Dominick who adding =
the PoP support to our IdentityServer3 =
implementation.
 
Thanks!
 
-Brock
 

------=_NextPart_000_00AD_01D16F2C.D5E369F0--


From nobody Wed Feb 24 15:28:36 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047431A8900 for ; Wed, 24 Feb 2016 15:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 k6zxrXFHmhhY for ; Wed, 24 Feb 2016 15:28:29 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBFC1A88F9 for ; Wed, 24 Feb 2016 15:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fg/l9jKT8s3PE61a5SDq8+oPFLNygdzmccpTdToGJgE=; b=E9NfggLx310fQUUrB3irW5wPMBzP/tFbAGmtOJFOWNDX/fp9Irm57UcEp1m0+YII6wMOhkrtK3LXePgY99VrL4KxVlGIUO+OdFv9z+ZOAlnRAZrYVr/NlMzIoJR8QVIfs5xaIBVc95EfGEQQKm/cyxReEH7VrkOM8mOlf8xPLCQ=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 23:28:26 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 23:28:26 +0000
From: Mike Jones 
To: "Phil Hunt (IDM)" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKwgAAD14CAABMcsA==
Date: Wed, 24 Feb 2016 23:28:26 +0000
Message-ID: 
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0@oracle.com>
In-Reply-To: <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::650]
x-ms-office365-filtering-correlation-id: 2209e89a-87dd-483b-7229-08d33d723248
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:VnDwziDG2n8vfYoC+72YjUqpWzWMt0yxIhX/u441mdFaUQT840SkYGdN5F6OXBjXt2ZhDp/VyLUCbiTzOXpPO5NztWCzKpT/ZlF7syjUE+OhfGB1O2gJJFX7cPgZMEqZ9MPXWdYqlwIIc9abmPJM/A==; 24:WUJ7Py8xgWrGATnLvJtvd5NmzZaDE3olO+7pHDLZ4rC97rA0dQAHQOjx2Ck0FEaXK6TuZdDuBk8i3KBlm1/BgfHg/faudcaXWqAkcFhOR0M=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; 
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(377454003)(24454002)(106116001)(87936001)(99286002)(19300405004)(76576001)(76176999)(92566002)(5001960100002)(10090500001)(19617315012)(15395725005)(86362001)(16236675004)(54356999)(50986999)(189998001)(110136002)(86612001)(5002640100001)(1220700001)(3280700002)(19625215002)(33656002)(586003)(19580405001)(19580395003)(74316001)(3660700001)(93886004)(1096002)(102836003)(790700001)(5004730100002)(6116002)(19609705001)(10290500002)(5005710100001)(40100003)(10400500002)(122556002)(8990500004)(11100500001)(2906002)(2950100001)(2900100001)(5008740100001)(77096005)(4326007)(15975445007)(5003600100002)(3900700001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C4E813E7ADFED795526BF5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 23:28:26.6984 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 23:28:35 -0000

--_000_BY2PR03MB442C4E813E7ADFED795526BF5A50BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIFVzZXJJbmZvIEVuZHBvaW50IHBhdGggaXNu4oCZdCBmaXhlZCBhbmQgc28gaGFzIHRvIGJl
IGRpc2NvdmVyZWQuDQoNCkkgYWdyZWUgdGhhdCBmb3Igc29tZSBPQXV0aCBwcm9maWxlcywgb25l
IG9yIG1vcmUgcmVzb3VyY2Ugc2VydmVycyB3aWxsIGhhdmUgdG8gYmUgZGlzY292ZXJlZCBzdGFy
dGluZyBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFdvcmtpbmcgZ3JvdXAgbWVtYmVy
cyBoYXZlIGFsc28gZGVzY3JpYmVkIHdhbnRpbmcgdG8gZGlzY292ZXIgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXJzIHN0YXJ0aW5nIGZyb20gcmVzb3VyY2Ugc2VydmVycy4gIFRoZXJlIGlzbuKAmXQgYSBz
dGFuZGFyZCBwcmFjdGljZSBmb3IgYW55IG9mIHRoaXMsIHdoaWNoIGlzIHdoeSBpdOKAmXMgaW50
ZW50aW9uYWxseSBsZWZ0IG91dCBvZiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLg0KDQpPbmNl
IHRoZSBJQU5BIE9BdXRoIERpc2NvdmVyeSBNZXRhZGF0YSBSZWdpc3RyeSBoYXMgYmVlbiBlc3Rh
Ymxpc2hlZCwgd2hpY2ggd2lsbCBoYXBwZW4gYWZ0ZXIgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlv
biBoYXMgYmVlbiBhcHByb3ZlZCwgaXQgd2lsbCBiZSBlYXN5IGZvciBzdWJzZXF1ZW50IHNwZWNp
ZmljYXRpb25zIHRvIGRvY3VtZW50IGV4aXN0aW5nIHByYWN0aWNlIGZvciBkaWZmZXJlbnQgT0F1
dGggcHJvZmlsZXMgYW5kIHJlZ2lzdGVyIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMgc3VwcG9y
dGluZyB0aGVtLiAgU29tZSBvZiB0aG9zZSB2YWx1ZXMgd2lsbCBsaWtlbHkgZGVmaW5lIHdheXMg
dG8gZGlzY292ZXIgcmVzb3VyY2Ugc2VydmVycywgd2hlbiBhcHBsaWNhYmxlLg0KDQpCdXQgZmly
c3QsIHdlIG5lZWQgdG8gZmluaXNoIHRoZSBleGlzdGluZyBzcGVjLCBzbyB0aGF0IHRoZSByZWdp
c3RyeSBlbmFibGluZyB0aGVzZSBleHRlbnNpb25zIGdldHMgZXN0YWJsaXNoZWQgaW4gdGhlIGZp
cnN0IHBsYWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkgW21h
aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQs
IDIwMTYgMjoxMyBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bT4NCkNjOiA8b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
T0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KWXVwLiBBbmQgYmVjYXVz
ZSB0aGVyZSBtYW55IHJlbGF0aW9ucyB0aGUgY2xpZW50IG1pc3QgYmUgYWJsZSB0byBkaXNjb3Zl
ciBpdC4gVGhlIGNsaWVudCBkb2VzIG5vdCBrbm93IGlmIHRoZSByZXMgc2VydmVyIGlzIGxlZ2l0
Lg0KDQpUaGUgdXNlcmluZm8gaXMgYWx3YXlzIGZpeCBhbmQgc28gdSBkb250IG5lZWQgZGlzY292
ZXJ5Lg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTQ6MDUsIE1pa2UgSm9uZXMgPE1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tPj4gd3JvdGU6DQpJbiBPcGVuSUQgQ29ubmVjdCwgdGhlcmXigJlzIGEgcmVzb3VyY2Ugc2Vy
dmVyIGNhbGxlZCB0aGUgVXNlckluZm8gRW5kcG9pbnQgdGhhdCByZXR1cm5zIGNsYWltcyBhYm91
dCB0aGUgYXV0aGVudGljYXRlZCB1c2VyIGFzIGEgSlNPTiBkYXRhIHN0cnVjdHVyZS4gIEl0cyBs
b2NhdGlvbiBpcyBwdWJsaXNoZWQgaW4gT3BlbklEIENvbm5lY3QgZGlzY292ZXJ5IG1ldGFkYXRh
IGFzIHRoZSDigJx1c2VyaW5mb19lbmRwb2ludOKAnSBtZXRhZGF0YSB2YWx1ZSwgd2hpY2ggaXMg
ZGVmaW5lZCBhdCBodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3Zl
cnktMV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YS4NCg0KV2UgZGlkbuKAmXQgaW5jbHVkZSB0aGUg
VXNlckluZm8gRW5kcG9pbnQgaW4gdGhlIGdlbmVyaWMgT0F1dGggZGlzY292ZXJ5IHNwZWMgc2lu
Y2UgaW4gT0F1dGgsIHRoZXJlIGFyZSBsb3RzIG9mIHBvc3NpYmxlIHJlbGF0aW9uc2hpcHMgYmV0
d2VlbiBhdXRob3JpemF0aW9uIHNlcnZlcnMgYW5kIHJlc291cmNlIHNlcnZlcnMgYW5kIHRoZXkg
bmVlZG7igJl0IGJlIG9uZS10by1vbmUsIGFzIGlzIGJlaW5nIGFjdGl2ZWx5IGRpc2N1c3NlZCBi
eSB0aGUgd29ya2luZyBncm91cC4gIEZvciBpbnN0YW5jZSwgc2VlIEdlb3JnZSBGbGV0Y2hlcuKA
mXMgcmVjZW50IGNvbnRyaWJ1dGlvbi4NCg0KVGhhbmtzIGZvciB0aGUgZ29vZCBkaXNjdXNzaW9u
LCBQaGlsLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkgW21haWx0
bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIw
MTYgMToyNSBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h
dXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3Zl
cnkgTG9jYXRpb24NCg0KV2hlcmUgaXMgdGhlIHByb2ZpbGUgZW5kcG9pbnQgKG9pZGMncyByZXNv
dXJjZSBzZXJ2ZXIpIHB1Ymxpc2hlZD8gKEZvciB0aGUgbm9uIE9JREMgcGVvcGxlIG9uIHRoZSBs
aXN0KS4NCg0KUGhpbA0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDEzOjA5LCBNaWtlIEpvbmVzIDxN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbT4+IHdyb3RlOg0KVG8gdGhlIGV4dGVudCB0aGF0IGdlbmVyaWMgT0F1dGggMi4wIG5lZWRz
IHRvIHB1Ymxpc2ggc29tZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBPcGVuSUQgQ29ubmVj
dCDigJMgd2hpY2ggaXMgYnVpbHQgb24gZ2VuZXJpYyBPQXV0aCAyLjAg4oCTIGl0IG1ha2VzIHNl
bnNlIHRvIHB1Ymxpc2ggdGhhdCBpbmZvcm1hdGlvbiB1c2luZyBleGFjdGx5IHRoZSBzYW1lIHN5
bnRheCwgc2luY2UgdGhhdCBzeW50YXggaXMgYWxyZWFkeSBpbiB3aWRlc3ByZWFkIHVzZS4gIFRo
YXQgd2hhdCB0aGlzIGRyYWZ0IGFjY29tcGxpc2hlcy4NCg0KVGhlcmXigJlzIG5vdGhpbmcgQ29u
bmVjdC1zcGVjaWZpYyBhYm91dCB1c2luZyBtZXRhZGF0YSByZXNwb25zZSB2YWx1ZXMgbGlrZToN
Cg0KICAgImF1dGhvcml6YXRpb25fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5j
b20vYXV0aG9yaXplIiwNCiAgICJ0b2tlbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFt
cGxlLmNvbS90b2tlbiIsDQogICAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRl
ZCI6IFsiY2xpZW50X3NlY3JldF9iYXNpYyIsICJwcml2YXRlX2tleV9qd3QiXSwNCiAgICJyZWdp
c3RyYXRpb25fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0ZXIi
LA0KICAgInJlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCI6ICBbImNvZGUiLCAidG9rZW4iXSwNCiAg
ICJzZXJ2aWNlX2RvY3VtZW50YXRpb24iOiAiaHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2
aWNlX2RvY3VtZW50YXRpb24uaHRtbCIsDQoNCklzIHRoZXJlIGEgcmVhc29uIHRoYXQgeW91IHdv
dWxkIGxpa2UgdGhlIHN5bnRheCBmb3IgYW55IG9mIHRoZXNlIG9yIHRoZSBvdGhlciBnZW5lcmFs
bHkgYXBwbGljYWJsZSBPQXV0aCAyLjAgbWV0YWRhdGEgdmFsdWVzIHRvIGJlIGRpZmZlcmVudD8g
IEkgZG9u4oCZdCBzZWUgYW55IGdvb2QgcmVhc29uIGZvciB1bm5lY2Vzc2FyeSBkaWZmZXJlbmNl
cyB0byBiZSBpbnRyb2R1Y2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQg
KElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVi
cnVhcnkgMjQsIDIwMTYgMTI6NDUgUE0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWlj
cm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkNjOiBNaWtlIEpvbmVz
IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbT4+OyA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRo
QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCk1pa2UNCg0KUHVibGlzaGluZyBvbiBk
ZXYgcGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29mdHdhcmUgKGVzcCBvcGVuIHNvdXJjZSkgdGhh
dCBpcyBkZXBsb3llZCBib3RoIGluIGVudGVycHJpc2VzIGFuZCBvbiBQYWFTIGNsb3VkIHByb3Zp
ZGVycy4NCg0KVGhlIGN1cnJlbnQgZHJhZnQgaXMgbWF5IGNvZGlmeSBjdXJyZW50IE9JREMgcHJh
Y3RpY2UgYW5kIGJlIGFwcHJvcHJpYXRlIGZvciBvaWRjIGJ1dCBpdCBpcyBub3QgcmVhZHkgZm9y
IGdlbmVyaWMgb2F1dGguIFRoZXJlIGlzIG5vIGdlbmVyaWMgb2F1dGggZXhwZXJpZW5jZSBhdCB0
aGlzIHRpbWUuDQoNClBoaWwNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAxMDoyNSwgQW50aG9ueSBO
YWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv
bT4+IHdyb3RlOg0KU3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91IGhhdmUgbm93IG1hZGUgaXQg
ZmFyIGVhc2llciBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvZXMgbm90IGV2ZW4g
YWRkcmVzcyB0aGlzDQoNCkZyb206IE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh
cnkgMjQsIDIwMTYgMTA6MjIgQU0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9z
b2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkNjOiA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp
ZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExv
Y2F0aW9uDQoNCkFzIHdl4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZm
ZWN0aXZlIHNlY3VyaXR5IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24g
YmVpbmcgcHVibGlzaGVkIGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBh
bmQgaXQgYmVpbmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiAg4oCcU2VjdXJpdHkg
Ynkgb2JzY3VyaXR54oCdIGFkZHMgbm8gcmVhbCBzZWN1cml0eSBhdCBhbGwuDQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl
DQoNCkZyb206IEFudGhvbnkgTmFkYWxpbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwg
MjAxNiAxMDowMSBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IFBoaWwgSHVudCAoSURNKSA8
cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IE5hdCBT
YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0K
Q2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRo
IDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KPiBUaGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMgdG8g
ZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhh
dOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuDQoNClRoYXQgbWF5IGJlIHdpZGVseSBkZXBs
b3llZCBmb3IgT0lEQyBidXQgbm90IHdpZGVseSBkZXBsb3llZCBmb3IgT0F1dGguIFRoZXJlIGFy
ZSBzb21lIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBkaXNjb3ZlcnkgZm9yIGVuZHBvaW50IHRo
YXQgcmVhbGx5IHNob3VsZCBub3QgYmUgaW4gYW4gT0F1dGggc3RhbmRhcmQgc2luY2UgaXTigJlz
IHJlYWxseSBub3QgZGVhbHQgd2l0aC4gTm93IHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRpb24gaXMg
YXZhaWxhYmxlIGl0IG1ha2VzIHBva2luZyBhcm91bmQgdGhlIGVuZHBvaW50IG1vcmUgZm9jdXNl
ZCBmb3IgcGVvcGxlIHRoYXQgd2FudCB0byBkaXNydXB0IHlvdXIgZW5kcG9pbnRzLCB0aGF0IGlz
IHJlYWxseSBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0
aW9uIGF0IGFsbA0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAy
MDE2IDk6NTQgQU0NClRvOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1h
aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+OyBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWls
LmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4NCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFp
bHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9u
DQoNClRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUg
Y29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBs
b3llZC4NCg0KTm9uZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0aW5nIHRoYXQgYWRk
aXRpb25hbCByZWxhdGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVhdGVkLiAgSeKAmW0g
c3VyZSBpdCB3aWxsIGJlLiAgU29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgV2ViRmluZ2VyIHRv
IGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiAgU29tZSB3aWxsIHBvc3NpYmx5IHVzZSBs
aW5rIGhlYWRlcnMuICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNwZWNpZmlj
IC53ZWxsLWtub3duIHZhbHVlcy4gIEnigJltIHN1cmUgdGhlcmXigJlzIG90aGVyIHRoaW5ncyBJ
IGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuICBBbGwgb2YgdGhlc2UgZGVwZW5kIHVwb24g
aGF2aW5nIGEgZGlzY292ZXJ5IG1ldGFkYXRhIGRvY3VtZW50IGZvcm1hdCBhbmQgbm9uZSBvZiB0
aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdpc3RlciBhZGRpdGlv
bmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMuDQoNClNvIGJ5IGFsbCBtZWFucywgdGhlIHdv
cmtpbmcgZ3JvdXAgc2hvdWxkIGNvbnRpbnVlIGRpc2N1c3NpbmcgaW52ZW50aW5nIHBvc3NpYmxl
IG5ldyByZWxhdGVkIG1lY2hhbmlzbXMgdGhhdCBtYWtlIHNlbnNlIGluIHNvbWUgY29udGV4dHMu
ICBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBjYW4gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGFscmVh
ZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0aGF0IGFsbCBvZiB0aGVzZSBt
ZWNoYW5pc21zIHdpbGwgbmVlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50IChJRE0pDQpTZW50
OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDg6MzkgQU0NClRvOiBOYXQgU2FraW11cmEg
PHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4NCkNjOiA8b2F1
dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPG9hdXRoQGlldGYub3JnPG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlz
Y292ZXJ5IExvY2F0aW9uDQoNCkkgYW0gc3VnZ2VzdGluZyB0aGF0IHBhcnQgb2YgdGhlIGRpc2Nv
dmVyeSBzb2x1dGlvbiBoYXMgdG8gYmUgdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoYXQgcmVzb3Vy
Y2UgZW5kcG9pbnQgaXQgd2FudHMgdGhlIG9hdXRoIGNvbmZpZ3VyYXRpb24gZGF0YSBmb3IuDQoN
ClNvIGlmIHJlcy5leGFtcGxlLmV2aWwuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj
dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZyZXMuZXhhbXBsZS5ldmlsLmNvbSZk
YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFh
YWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNk
YXRhPVBjJTJiN2lsbkRZZ2ZqWW9Uc1FXb1pucG9iRyUyYlZKcDVXdTljR3BGVWd6M1MwJTNkPiBp
cyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgYXMuZXhhbXBsZS5jb208aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy
ZmFzLmV4YW1wbGUuY29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
ZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmc2RhdGE9NiUyYnF4aCUyZjdWQ1prc3dYaEpNdjZyJTJiMThkVFJiZzJJ
czEyV0IlMmZkWm0zY0o0JTNkPiB0aGUgYXV0aHogZGlzY292ZXJ5IHNob3VsZCBmYWlsIGluIHNv
bWUgd2F5IChlZyByZXR1cm4gbm90aGluZykuDQoNClRoZXJlIG1heSBiZSBiZXR0ZXIgd2F5cyB0
byBkbyB0aGlzLiBFZyBjb21iaW5lIGRpc2NvdmVyeS4gT3IgY2hhbmdlIHRoZSBvcmRlciBvZiBk
aXNjb3ZlcnkuDQoNCk9uZSBvZiBPQXV0aCdzIHN0cmVuZ3RoJ3MgYW5kIHdlYWtuZXNzZXMgaXMg
dGhhdCB0aGUgdGFyZ2V0IG9mIGF1dGhvcml6YXRpb24gKHRoZSByZXNvdXJjZSkgaXMgbmV2ZXIg
c3BlY2lmaWVkLiBJdCBpcyBvZnRlbiBib3VuZCB1cCBpbiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlv
biBhbmQgYW4gb2Z0ZW4gaW1wbGllZCAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gcmVzb3VyY2Ug
YW5kIGFzLiBHaXZlbiB0aGF0IGluIGRpc2NvdmVyeSBwaGFzZSByZWdpc3RyYXRpb24gaGFzIG5v
dCB5ZXQgb2NjdXJyZWQgaXQgc2VlbXMgaW1wb3J0YW50IHRoYXQgdGhlIGNsaWVudCBrbm93IGl0
IGhhcyBhIHZhbGlkIGNvbWJpbmF0aW9uIG9mIGVuZHBvaW50cyBldGMuDQoNClRoaXMgaXMgd2h5
IEkgd2FzIGRpc2FwcG9pbnRlZCBhYm91dCB3Z2xjIG9uIGRpc2NvdmVyeS4gV2UgaGFkIGEgc3Rh
cnRpbmcgcG9pbnQgZm9yIGdyb3VwIGFkb3B0aW9uIGJ1dCB3ZSBoYXZlbid0IHJlYWxseSBkZWZp
bmVkIHRoZSBmdWxsIHJlcXVpcmVtZW50cyBJTU8uDQoNCkkgYW0gb24gdmFjYXRpb24gb3IgSSB3
b3VsZCBwdXQgc29tZSB0aG91Z2h0IGludG8gc29tZSBkcmFmdCBjaGFuZ2VzIG9yIGEgbmV3IGRy
YWZ0LiBJIGFwb2xvZ2l6ZSBJIGNhbid0IGRvIGl0IG5vdy4NCg0KUGhpbA0KDQpPbiBGZWIgMjQs
IDIwMTYsIGF0IDA4OjEyLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86
c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBQaGlsLA0KDQpBcmUgeW91IHN1Z2dlc3Rp
bmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUgdGhlIFJTIFVSSXM/IEN1cnJl
bnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwgSSBndWVzcy4NCg0KVGhlIHdh
eSBvYXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQNCg0KMS4gUlMgdGVsbHMgdGhlIGNsaWVudCB3aGVy
ZSB0aGUgQVMgaXMuDQoyLiBBUyB0ZWxscyB0aGUgY2xpZW50IHdoaWNoIFJTIGVuZHBvaW50cyB0
aGUgdG9rZW4gY2FuIGJlIHVzZWQuDQoNCkV2ZW4gaWYgdGhlcmUgaXMgYSBiYWQgQVMgd2l0aCBh
IHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBSUywgdGhlIGNsaWVudCB3aWxs
IG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHogc2VydmVyIHdpbGwgc2F5IHRo
YXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50IHRvIHNlbmQgdGhlIHRva2Vu
IHRvLg0KDQpOYXQNCg0KMjAxNuW5tDLmnIgyNOaXpSjmsLQpIDIzOjU5IFBoaWwgSHVudCA8cGhp
bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46DQpOYXQsDQoN
CknigJltIG5vdCBzdXJlIHRoYXQgaGF2aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGVsbCB0aGUg
Y2xpZW50IHdoZXJlIGl0cyBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBzZWN1cmUgYnkgaXRzZWxm
LiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGFuZCB0
aGUgUmVzb3VyY2Ugc2VydmVyIG5lZWQgdG8gYmUgYm91bmQgdG9nZXRoZXIgaW4gb25lIG9mIHRo
ZSBkaXNjb3ZlcnkgZW5kcG9pbnRzICh0aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2
aWNlIGRpc2NvdmVyeSkuDQoNCklmIGEgY2xpZW50IGRpc2NvdmVycyBhIGZha2UgcmVzb3VyY2Ug
c2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9yIGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIgdGhlIGN1
cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBub3QgbGVhZCB0aGUgY2xpZW50IHRvIHVuZGVyc3Rh
bmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJjZSBzZXJ2ZXIuIFJhdGhlciB0aGUgZmFrZSByZXNv
dXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZlIGEgZmFrZSBkaXNjb3Zlcnkgc2VydmljZS4gVGhl
IGhhY2tlciBjYW4gbm93IGludGVyY2VwdCByZXNvdXJjZSBwYXlsb2FkIGFzIHdlbGwgYXMgdG9r
ZW5zIGJlY2F1c2UgdGhleSB3ZXJlIGFibGUgdG8gY29udmluY2UgdGhlIGNsaWVudCB0byB1c2Ug
dGhlIGxlZ2l0IGF1dGhvcml6YXRpb24gc2VydmljZSBidXQgdXNlIHRoZSB0b2tlbiBhZ2FpbnN0
IHRoZSBoYWNrZXJzIHByb3h5Lg0KDQpUaGUgT0F1dGggRGlzY292ZXJ5IHNlcnZpY2UgbmVlZHMg
dG8gY29uZmlybSB0byB0aGUgY2xpZW50IHRoYXQgdGhlIHNlcnZlciBpcyBhYmxlIHRvIGlzc3Vl
IHRva2VucyBmb3IgYSBzdGF0ZWQgcmVzb3VyY2UgZW5kcG9pbnQuDQoNClRoaXMgbm90IG9ubHkg
d29ya3MgaW4gbm9ybWFsIE9BdXRoIGJ1dCBzaG91bGQgYWRkIHNlY3VyaXR5IGV2ZW4gdG8gVU1B
IHNpdHVhdGlvbnMuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlk
LmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o
dHRwJTNhJTJmJTJmd3d3LmluZGVwZW5kZW50aWQuY29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9TUpXcEZCMTJ2VExCNGVjS3lZ
d2xaTG5SSkluYU5FdzFNd2x2dFUyNkJQQSUzZD4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0
bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAzOjU0
IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21h
aWwuY29tPj4gd3JvdGU6DQoNCg0KSGkgVGhvbWFzLA0KDQppbmxpbmU6DQoNCjIwMTblubQy5pyI
MjLml6Uo5pyIKSAxODo0NCBUaG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb208bWFpbHRv
OnQuYnJveWVyQGdtYWlsLmNvbT4+Og0KQ291bGRuJ3QgdGhlIGRvY3VtZW50IG9ubHkgZGVzY3Jp
YmUgdGhlIG1ldGFkYXRhPw0KSSBxdWl0ZSBsaWtlIHRoZSBpZGVhIG9mIGRyYWZ0LXNha2ltdXJh
LW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRpc2NvdmVyeSwgYW5kIGxlYXZl
IGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3BlY3MgdG8gZGVmaW5lIGEgLndl
bGwta25vd24gVVJMIGZvciAiYXV0by1jb25maWd1cmF0aW9uIi4NClRoZSBtZXRhZGF0YSBkZXNj
cmliZWQgaGVyZSB3b3VsZCB0aGVuIGVpdGhlciBiZSB1c2VkIGFzLWlzLCBhdCBhbnkgVVJMLCBy
ZXR1cm5lZCBhcyBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRoZSBSUzsg
b3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UgT3BlbklEIENvbm5l
Y3QpLg0KV2l0aCBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJ3MgImR1cmkiIGFuZCB0aGUgInNj
b3BlIiBhdHRyaWJ1dGUgb2YgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIsIHlvdSBo
YXZlIGV2ZXJ5dGhpbmcgeW91IG5lZWQgdG8gcHJvY2VlZA0KDQpZdXAuIFRoYXQncyBvbmUgb2Yg
dGhlIHJlcXVpcmVtZW50cyB0byBiZSBSRVNUZnVsLCBpcyBpdCBub3Q/DQoNCkluIE9BdXRoJ3Mg
Y2FzZSwgdGhlIHJlc291cmNlIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIHVzdWFs
bHkgdGlnaHRseSBjb3VwbGVkLiAoT3RoZXJ3aXNlLCB5b3UgbmVlZCBhbm90aGVyIHNwZWNzIGxp
a2UgVU1BLikNClNvLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIHRlbGwg
ZWl0aGVyIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogZW5kcG9pbnQuIEluIHNvbWUgdHJ1c3Rl
ZCBlbnZpcm9ubWVudCwgdGhlIHJlc291cmNlIG1heSBhcyB3ZWxsIHJldHVybiB0aGUgbG9jYXRp
b24gb2YgdGhlIGF1dGh6IHNlcnZlciBjb25maWd1cmF0aW9uIGRhdGEuIEluIHRoZXNlIGNhc2Vz
LCB5b3UgZG8gbm90IGhhdmUgdG8gZGVjaWRlIG9uIHdoYXQgLndlbGwta25vd24gdXJpIGFzIHlv
dSBzYXkuIFRoaXMgZnJlZXMgdXAgZGV2ZWxvcGVycyBmcm9tIGNvbmZpZ3VyYXRpb24gZmlsZSBs
b2NhdGlvbiBjb2xsaXNpb25zIGV0Yy4gV2Ugc2hvdWxkIHN0cml2ZSBub3QgdG8gcG9sbHV0ZSB0
aGUgdXJpIHNwYWNlIGFzIG11Y2ggYXMgcG9zc2libGUuDQoNCih3ZWxsLCBleGNlcHQgaWYgdGhl
cmUgYXJlIHNldmVyYWwgQVNzIGVhY2ggd2l0aCBkaWZmZXJlbnQgc2NvcGVzOyBzb3VuZHMgbGlr
ZSBhbiBlZGdlLWNhc2UgdG8gbWUgdGhvdWdoOyBtYXliZSBSRkM2NzUwIHNob3VsZCBpbnN0ZWFk
IGJlIHVwZGF0ZWQgd2l0aCBzdWNoIGEgcGFyYW1ldGVyIHN1Y2ggdGhhdCBhbiBSUyBjb3VsZCBy
ZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBpdHMgb3du
ICJzY29wZSIgYW5kICJkdXJpIiB2YWx1ZT8pDQoNClllYWgsIEkgZ3Vlc3MgaXQgaXMgYW4gZWRn
ZSBjYXNlLiBJIHdvdWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2ZXJzIHRv
IGRldmVsb3AgYSB0cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdyZWUgb24g
YSBzaW5nbGUgc2V0IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLg0KDQpDaGVlcnMs
DQoNCk5hdA0KDQoNCk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDEwOjU5IFBNIEp1c3RpbiBSaWNo
ZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpUaGUg
bmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBhbmQgbW92
aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxsIGhhdmUg
dG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9uZSBpc3N1
ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNlIG9mIOKAnC8u
d2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292ZXJ5IHBvcnRp
b24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBPcGVuSUQgQ29u
bmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFzb24gdG8gdGll
IHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlzbS4NCg0KSSBwcm9wb3NlIHRo
YXQgd2UgdXNlIOKAnC8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAnSBh
cyB0aGUgZGVmYXVsdCBkaXNjb3ZlcnkgbG9jYXRpb24sIGFuZCBzdGF0ZSB0aGF0IHRoZSBkb2N1
bWVudCBNQVkgYWxzbyBiZSByZWFjaGFibGUgZnJvbSDigJwvLndlbGwta25vd24vb3BlbmlkLWNv
bmZpZ3VyYXRpb27igJ0gaWYgdGhlIHNlcnZlciBhbHNvIHByb3ZpZGVzIE9wZW5JRCBDb25uZWN0
IG9uIHRoZSBzYW1lIGRvbWFpbi4gT3RoZXIgYXBwbGljYXRpb25zIFNIT1VMRCB1c2UgdGhlIHNh
bWUgcGFyYW1ldGVyIG5hbWVzIHRvIGRlc2NyaWJlIE9BdXRoIGVuZHBvaW50cyBhbmQgZnVuY3Rp
b25zIGluc2lkZSB0aGVpciBzZXJ2aWNlLXNwZWNpZmljIGRpc2NvdmVyeSBkb2N1bWVudC4NCg0K
IOKAlCBKdXN0aW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl
MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3
Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWdvMUZoTCUy
YkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZD4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJm
bGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJnNkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4
NDBwWlBKeHRsNCUzZD4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0
cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2El
MmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdj
MDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNk
NDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWdvMUZo
TCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBwWlBKeHRsNCUzZD4NCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz
dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_BY2PR03MB442C4E813E7ADFED795526BF5A50BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAg
MCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiOw0K
CXBhbm9zZS0xOjIgMTEgNSAzIDIgMCAwIDIgMCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv
QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv
b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l
Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw
YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi
Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5
bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250
LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxT
dHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzAwMjA2MDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls
ZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBVc2VySW5mbyBFbmRwb2ludCBwYXRoIGlzbuKA
mXQgZml4ZWQgYW5kIHNvIGhhcyB0byBiZSBkaXNjb3ZlcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBhZ3JlZSB0aGF0IGZvciBzb21lIE9BdXRoIHByb2Zp
bGVzLCBvbmUgb3IgbW9yZSByZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSBkaXNjb3Zl
cmVkIHN0YXJ0aW5nIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAmbmJzcDtXb3JraW5n
IGdyb3VwIG1lbWJlcnMgaGF2ZQ0KIGFsc28gZGVzY3JpYmVkIHdhbnRpbmcgdG8gZGlzY292ZXIg
YXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHN0YXJ0aW5nIGZyb20gcmVzb3VyY2Ugc2VydmVycy4mbmJz
cDsgVGhlcmUgaXNu4oCZdCBhIHN0YW5kYXJkIHByYWN0aWNlIGZvciBhbnkgb2YgdGhpcywgd2hp
Y2ggaXMgd2h5IGl04oCZcyBpbnRlbnRpb25hbGx5IGxlZnQgb3V0IG9mIHRoZSBjdXJyZW50IHNw
ZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5P
bmNlIHRoZSBJQU5BIE9BdXRoIERpc2NvdmVyeSBNZXRhZGF0YSBSZWdpc3RyeSBoYXMgYmVlbiBl
c3RhYmxpc2hlZCwgd2hpY2ggd2lsbCBoYXBwZW4gYWZ0ZXIgdGhlIGN1cnJlbnQgc3BlY2lmaWNh
dGlvbiBoYXMgYmVlbiBhcHByb3ZlZCwgaXQgd2lsbCBiZSBlYXN5IGZvcg0KIHN1YnNlcXVlbnQg
c3BlY2lmaWNhdGlvbnMgdG8gZG9jdW1lbnQgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIGRpZmZlcmVu
dCBPQXV0aCBwcm9maWxlcyBhbmQgcmVnaXN0ZXIgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyBz
dXBwb3J0aW5nIHRoZW0uJm5ic3A7IFNvbWUgb2YgdGhvc2UgdmFsdWVzIHdpbGwgbGlrZWx5IGRl
ZmluZSB3YXlzIHRvIGRpc2NvdmVyIHJlc291cmNlIHNlcnZlcnMsIHdoZW4gYXBwbGljYWJsZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkJ1dCBmaXJzdCwgd2Ug
bmVlZCB0byBmaW5pc2ggdGhlIGV4aXN0aW5nIHNwZWMsIHNvIHRoYXQgdGhlIHJlZ2lzdHJ5IGVu
YWJsaW5nIHRoZXNlIGV4dGVuc2lvbnMgZ2V0cyBlc3RhYmxpc2hlZCBpbiB0aGUgZmlyc3QgcGxh
Y2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4gUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAx
NiAyOjEzIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7ICZs
dDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZdXAuIEFuZCBiZWNhdXNlIHRoZXJlIG1hbnkgcmVs
YXRpb25zIHRoZSBjbGllbnQgbWlzdCBiZSBhYmxlIHRvIGRpc2NvdmVyIGl0LiBUaGUgY2xpZW50
IGRvZXMgbm90IGtub3cgaWYgdGhlIHJlcyBzZXJ2ZXIgaXMgbGVnaXQuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN
YWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB1c2VyaW5mbyBpcyBhbHdh
eXMgZml4IGFuZCBzbyB1IGRvbnQgbmVlZCBkaXNjb3ZlcnkuJm5ic3A7PGJyPg0KPGJyPg0KUGhp
bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDE0OjA1
LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPkluIE9wZW5JRCBDb25uZWN0LCB0aGVyZeKAmXMgYSByZXNvdXJj
ZSBzZXJ2ZXIgY2FsbGVkIHRoZSBVc2VySW5mbyBFbmRwb2ludCB0aGF0IHJldHVybnMgY2xhaW1z
IGFib3V0IHRoZSBhdXRoZW50aWNhdGVkIHVzZXIgYXMgYSBKU09OIGRhdGEgc3RydWN0dXJlLiZu
YnNwOyBJdHMgbG9jYXRpb24NCiBpcyBwdWJsaXNoZWQgaW4gT3BlbklEIENvbm5lY3QgZGlzY292
ZXJ5IG1ldGFkYXRhIGFzIHRoZSDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs
YWNrIj51c2VyaW5mb19lbmRwb2ludDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+4oCdIG1ldGFkYXRhDQogdmFsdWUsIHdoaWNoIGlzIGRlZmluZWQgYXQgPGEgaHJlZj0iaHR0
cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1By
b3ZpZGVyTWV0YWRhdGEiPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3Qt
ZGlzY292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0YWRhdGE8L2E+Ljwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgZGlkbuKAmXQgaW5jbHVkZSB0aGUgVXNlcklu
Zm8gRW5kcG9pbnQgaW4gdGhlIGdlbmVyaWMgT0F1dGggZGlzY292ZXJ5IHNwZWMgc2luY2UgaW4g
T0F1dGgsIHRoZXJlIGFyZSBsb3RzIG9mIHBvc3NpYmxlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBh
dXRob3JpemF0aW9uIHNlcnZlcnMNCiBhbmQgcmVzb3VyY2Ugc2VydmVycyBhbmQgdGhleSBuZWVk
buKAmXQgYmUgb25lLXRvLW9uZSwgYXMgaXMgYmVpbmcgYWN0aXZlbHkgZGlzY3Vzc2VkIGJ5IHRo
ZSB3b3JraW5nIGdyb3VwLiZuYnNwOyBGb3IgaW5zdGFuY2UsIHNlZSBHZW9yZ2UgRmxldGNoZXLi
gJlzIHJlY2VudCBjb250cmlidXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBnb29kIGRpc2N1c3Npb24sIFBoaWwuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi
PiBQaGlsIEh1bnQgKElETSkgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDE6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9u
ZXM8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h
dXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVyZSBpcyB0aGUgcHJvZmlsZSBlbmRwb2ludCAo
b2lkYydzIHJlc291cmNlIHNlcnZlcikgcHVibGlzaGVkPyAoRm9yIHRoZSBub24gT0lEQyBwZW9w
bGUgb24gdGhlIGxpc3QpLiZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KT24gRmViIDI0LCAyMDE2LCBhdCAxMzowOSwgTWlrZSBKb25lcyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0Bt
aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5U
byB0aGUgZXh0ZW50IHRoYXQgZ2VuZXJpYyBPQXV0aCAyLjAgbmVlZHMgdG8gcHVibGlzaCBzb21l
IG9mIHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIE9wZW5JRCBDb25uZWN0IOKAkyB3aGljaCBpcyBi
dWlsdCBvbiBnZW5lcmljIE9BdXRoIDIuMCDigJMgaXQgbWFrZXMgc2Vuc2UgdG8NCiBwdWJsaXNo
IHRoYXQgaW5mb3JtYXRpb24gdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBzeW50YXgsIHNpbmNlIHRo
YXQgc3ludGF4IGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UuJm5ic3A7IFRoYXQgd2hhdCB0
aGlzIGRyYWZ0IGFjY29tcGxpc2hlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMDIwNjAiPlRoZXJl4oCZcyBub3RoaW5nIENvbm5lY3Qtc3BlY2lmaWMgYWJvdXQgdXNpbmcg
bWV0YWRhdGEgcmVzcG9uc2UgdmFsdWVzIGxpa2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7YXV0aG9yaXphdGlvbl9lbmRwb2lu
dCZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9y
aXplIj5odHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRob3JpemU8L2E+JnF1b3Q7LDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnQmcXVvdDs6ICZx
dW90OzxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIj5odHRwczovL3Nl
cnZlci5leGFtcGxlLmNvbS90b2tlbjwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNw
OyZuYnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkJnF1b3Q7
OiBbJnF1b3Q7Y2xpZW50X3NlY3JldF9iYXNpYyZxdW90OywgJnF1b3Q7cHJpdmF0ZV9rZXlfand0
JnF1b3Q7XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7ICZxdW90O3JlZ2lzdHJhdGlv
bl9lbmRwb2ludCZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5j
b20vcmVnaXN0ZXIiPmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyPC9hPiZxdW90
Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7ICZxdW90O3Jlc3BvbnNlX3R5cGVzX3N1
cHBvcnRlZCZxdW90OzombmJzcDsgWyZxdW90O2NvZGUmcXVvdDssICZxdW90O3Rva2VuJnF1b3Q7
XSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7ICZxdW90O3NlcnZpY2VfZG9jdW1lbnRh
dGlvbiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2
aWNlX2RvY3VtZW50YXRpb24uaHRtbCI+aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2aWNl
X2RvY3VtZW50YXRpb24uaHRtbDwvYT4mcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj5JcyB0aGVyZSBhIHJlYXNvbiB0aGF0IHlvdSB3b3VsZCBsaWtlIHRo
ZSBzeW50YXggZm9yIGFueSBvZiB0aGVzZSBvciB0aGUgb3RoZXIgZ2VuZXJhbGx5IGFwcGxpY2Fi
bGUgT0F1dGggMi4wIG1ldGFkYXRhIHZhbHVlcyB0byBiZSBkaWZmZXJlbnQ/Jm5ic3A7IEkgZG9u
4oCZdCBzZWUgYW55DQogZ29vZCByZWFzb24gZm9yIHVubmVjZXNzYXJ5IGRpZmZlcmVuY2VzIHRv
IGJlIGludHJvZHVjZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUGhpbCBIdW50IChJRE0pIFs8YSBocmVm
PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAx
Mjo0NSBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWls
dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxi
cj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7ICZs
dDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDsg
Jmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5
IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk1pa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2ln
bmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UHVibGlzaGluZyBvbiBkZXYgcGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29mdHdhcmUgKGVzcCBv
cGVuIHNvdXJjZSkgdGhhdCBpcyBkZXBsb3llZCBib3RoIGluIGVudGVycHJpc2VzIGFuZCBvbiBQ
YWFTIGNsb3VkIHByb3ZpZGVycy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhlIGN1cnJlbnQgZHJhZnQgaXMgbWF5IGNvZGlmeSBjdXJyZW50IE9J
REMgcHJhY3RpY2UgYW5kIGJlIGFwcHJvcHJpYXRlIGZvciBvaWRjIGJ1dCBpdCBpcyBub3QgcmVh
ZHkgZm9yIGdlbmVyaWMgb2F1dGguIFRoZXJlIGlzIG5vIGdlbmVyaWMgb2F1dGggZXhwZXJpZW5j
ZSBhdCB0aGlzIHRpbWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFw
cGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpQaGlsPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTA6MjUsIEFudGhv
bnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9u
eW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5TdXJlIHRoZXJlIGlzLCBpdCBpcyBhcyB5b3UgaGF2ZSBub3cgbWFkZSBpdCBmYXIgZWFz
aWVyIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9lcyBub3QgZXZlbiBhZGRyZXNz
IHRoaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l
PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+IE1pa2UgSm9uZXMNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjIyIEFNPGJyPg0KPGI+VG86PC9iPiBBbnRob255
IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnlu
YWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJt
YWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj5BcyB3ZeKAmWQgZGlzY3Vzc2VkIGluIHBlcnNvbiwgdGhlcmXigJlz
IG5vIGVmZmVjdGl2ZSBzZWN1cml0eSBkaWZmZXJlbmNlIGJldHdlZW4gZGlzY292ZXJ5IGluZm9y
bWF0aW9uIGJlaW5nIHB1Ymxpc2hlZCBpbiBhbiBhZC1ob2MgZmFzaGlvbiBvbiBkZXZlbG9wZXIg
cGFnZXMgYW5kDQogaXQgYmVpbmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiZuYnNw
OyDigJxTZWN1cml0eSBieSBvYnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFs
bC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbnRob255IE5hZGFsaW4N
Cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFN
PGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozsg
UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i
PnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs7IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDs8YnI+
DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll
dGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBPQXV0
aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiBUaGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMg
dG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkN
CiB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoYXQgbWF5IGJlIHdpZGVseSBkZXBsb3llZCBmb3IgT0lE
QyBidXQgbm90IHdpZGVseSBkZXBsb3llZCBmb3IgT0F1dGguIFRoZXJlIGFyZSBzb21lIGF1dGhl
bnRpY2F0aW9uIG1lY2hhbmlzbSBkaXNjb3ZlcnkgZm9yIGVuZHBvaW50IHRoYXQgcmVhbGx5IHNo
b3VsZCBub3QNCiBiZSBpbiBhbiBPQXV0aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5v
dCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUg
aXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9w
bGUgdGhhdCB3YW50IHRvIGRpc3J1cHQgeW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5v
dCBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQogc2VjdGlvbiBhdCBh
bGwgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEg
aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNl
bnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDk6NTQgQU08YnI+DQo8Yj5Ubzo8
L2I+IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu
Y29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OyBOYXQgU2FraW11cmEgJmx0OzxhIGhy
ZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7
PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0
aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h
dXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgcG9p
bnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292
ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5Ob25lIG9mIE5hdCBvciBKb2hu
IG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0
eSB3b27igJl0IGJlIGNyZWF0ZWQuJm5ic3A7IEnigJltIHN1cmUgaXQgd2lsbCBiZS4mbmJzcDsg
U29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgV2ViRmluZ2VyIHRvDQogbG9jYXRlIHRoZSBkaXNj
b3ZlcnkgbWV0YWRhdGEuJm5ic3A7IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJz
LiZuYnNwOyBTb21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNwZWNpZmljIC53ZWxs
LWtub3duIHZhbHVlcy4mbmJzcDsgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkg
aGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4mbmJzcDsgQWxsIG9mIHRoZXNlIGRlcGVuZCB1
cG9uIGhhdmluZyBhIGRpc2NvdmVyeSBtZXRhZGF0YSBkb2N1bWVudA0KIGZvcm1hdCBhbmQgbm9u
ZSBvZiB0aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdpc3RlciBh
ZGRpdGlvbmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj5TbyBieSBhbGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3Vw
IHNob3VsZCBjb250aW51ZSBkaXNjdXNzaW5nIGludmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRl
ZCBtZWNoYW5pc21zIHRoYXQgbWFrZSBzZW5zZSBpbiBzb21lIGNvbnRleHRzLiZuYnNwOyBBdCB0
aGUgc2FtZSB0aW1lLCB3ZQ0KIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3
aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hh
bmlzbXMgd2lsbCBuZWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9B
dXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQgKElE
TSk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFN
PGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZn
dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVy
eSBMb2NhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRp
b24gaGFzIHRvIGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50
IGl0IHdhbnRzIHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEgZm9yLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl
TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiA8YSBocmVmPSJodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm
JTJmcmVzLmV4YW1wbGUuZXZpbC5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVBjJTJiN2lsbkRZZ2ZqWW9Uc1FX
b1pucG9iRyUyYlZKcDVXdTljR3BGVWd6M1MwJTNkIj4NCnJlcy5leGFtcGxlLmV2aWwuY29tPC9h
PiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgPGEgaHJlZj0iaHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFz
LmV4YW1wbGUuY29tJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT02JTJicXhoJTJmN1ZDWmtzd1hoSk12NnIlMmIxOGRU
UmJnMklzMTJXQiUyZmRabTNjSjQlM2QiPg0KYXMuZXhhbXBsZS5jb208L2E+IHRoZSBhdXRoeiBk
aXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgbWF5
IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBPciBjaGFu
Z2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25l
c3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBp
cyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVn
aXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiBy
ZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4NCiBkaXNjb3ZlcnkgcGhhc2UgcmVnaXN0cmF0
aW9uIGhhcyBub3QgeWV0IG9jY3VycmVkIGl0IHNlZW1zIGltcG9ydGFudCB0aGF0IHRoZSBjbGll
bnQga25vdyBpdCBoYXMgYSB2YWxpZCBjb21iaW5hdGlvbiBvZiBlbmRwb2ludHMgZXRjLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdo
eSBJIHdhcyBkaXNhcHBvaW50ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0
YXJ0aW5nIHBvaW50IGZvciBncm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVm
aW5lZCB0aGUgZnVsbCByZXF1aXJlbWVudHMgSU1PLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVy
ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0
IHNvbWUgdGhvdWdodCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBh
cG9sb2dpemUgSSBjYW4ndCBkbyBpdCBub3cuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2Fr
aW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdt
YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRo
ZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBk
b2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd2F5IG9hdXRoLW1l
dGEgd29ya3MgaXMgdGhhdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBSUyB0ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBp
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBj
YW4gYmUgdXNlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+RXZlbiBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2Vy
dHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJTLCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQg
dGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3Qg
dGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUgdG9rZW4gdG8uJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KTmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+MjAxNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuW5tDwvc3Bhbj4y
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5pyIPC9zcGFuPjI0PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj7msLQ8L3NwYW4+KSAyMzo1OSBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCw8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB0
aGF0IGhhdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVyZSBpdHMg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIHNlcnZl
ciBuZWVkIHRvIGJlIGJvdW5kIHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5DQogZW5k
cG9pbnRzICh0aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2aWNlIGRpc2NvdmVyeSku
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg
YSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWlu
ZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3
aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJl
c291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0
IGhhdmUNCiBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRl
cmNlcHQgcmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2Vy
ZSBhYmxlIHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0
aW9uIHNlcnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl
IE9BdXRoIERpc2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0
aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291
cmNlIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGlzIG5vdCBvbmx5IHdvcmtzIGluIG5vcm1hbCBPQXV0aCBidXQgc2hvdWxk
IGFkZCBzZWN1cml0eSBldmVuIHRvIFVNQSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5A
aW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUy
Znd3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9TUpXcEZCMTJ2VExCNGVjS3lZd2xa
TG5SSkluYU5FdzFNd2x2dFUyNkJQQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVu
dGlkLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp
bC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAyNCwg
MjAxNiwgYXQgMzo1NCBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11
cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48YnI+DQpIaSBUaG9tYXMsJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPmlubGluZTombmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW5
tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
nIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYi
PuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4oPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlm
Ij7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KQ0KIDE4OjQ0IFRob21hcyBCcm95ZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50LmJy
b3llckBnbWFpbC5jb208L2E+Jmd0Ozo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNvdWxkbid0IHRoZSBkb2N1bWVu
dCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBxdWl0ZSBsaWtlIHRo
ZSBpZGVhIG9mJm5ic3A7ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdh
bnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0
byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICZxdW90O2F1dG8t
Y29uZmlndXJhdGlvbiZxdW90Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbWV0YWRhdGEgZGVz
Y3JpYmVkIGhlcmUgd291bGQgdGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwg
cmV0dXJuZWQgYXMmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0IHRo
ZSBSUzsgb3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UNCiBPcGVu
SUQgQ29ubmVjdCkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+V2l0aCZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAmcXVvdDtk
dXJpJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsgYXR0cmlidXRlIG9mIFdXVy1BdXRo
ZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBuZWVkIHRv
IHByb2NlZWQmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WXVwLiBUaGF0J3Mgb25lIG9mIHRo
ZSByZXF1aXJlbWVudHMgdG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90PyAmbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiBPQXV0aCdzIGNhc2UsIHRo
ZSByZXNvdXJjZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0
bHkgY291cGxlZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4p
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxk
IGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2lu
dC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwg
cmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUNCiBhdXRoeiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBk
YXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBoYXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53
ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZyZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBj
b25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlzaW9ucyBldGMuIFdlIHNob3VsZCBzdHJp
dmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBhcyBtdWNoIGFzIHBvc3NpYmxlLiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4o
d2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFyZSBzZXZlcmFsIEFTcyBlYWNoIHdpdGggZGlmZmVyZW50
IHNjb3Blczsgc291bmRzIGxpa2UgYW4gZWRnZS1jYXNlIHRvIG1lIHRob3VnaDsgbWF5YmUgUkZD
Njc1MCBzaG91bGQgaW5zdGVhZCBiZSB1cGRhdGVkIHdpdGggc3VjaCBhIHBhcmFtZXRlciBzdWNo
DQogdGhhdCBhbiBSUyBjb3VsZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFy
ZXIsIGVhY2ggd2l0aCBpdHMgb3duICZxdW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtkdXJpJnF1
b3Q7IHZhbHVlPyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBl
ZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMg
dG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBv
biBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlcg0KIHZhbHVlcy4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsJm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TmF0PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmks
IEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls
dG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZn
dDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPlRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVu
dCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywg
aG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5l
Y3Qgb3JpZ2lucy4gT25lDQogaXNzdWUgaW4gcGFydGljdWxhciBzdGlsbCByZWFsbHkgYm90aGVy
cyBtZTogdGhlIHVzZSBvZiDigJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb27igJ0g
aW4gdGhlIGRpc2NvdmVyeSBwb3J0aW9uLiBJcyB0aGlzIGFuIE9BdXRoIGRpc2NvdmVyeSBkb2N1
bWVudCwgb3IgYW4gT3BlbklEIENvbm5lY3Qgb25lPyBUaGVyZSBpcyBhYnNvbHV0ZWx5IG5vIGNv
bXBlbGxpbmcgcmVhc29uIHRvIHRpZSB0aGUgVVJMIHRvIHRoZSBPSURDIGRpc2NvdmVyeQ0KIG1l
Y2hhbmlzbS48YnI+DQo8YnI+DQpJIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3du
L29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBs
b2NhdGlvbiwgYW5kIHN0YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJs
ZSBmcm9tIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2Vy
dmVyIGFsc28gcHJvdmlkZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhl
cg0KIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBk
ZXNjcmliZSBPQXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2Vydmlj
ZS1zcGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A74oCUIEp1c3Rp
bjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl
MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3
YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMz
ZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9
Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v
cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z28xRmhMJTJiRGE2
eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh
bj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy
Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp
bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
ZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043
RUp4NDBwWlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B
dXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_BY2PR03MB442C4E813E7ADFED795526BF5A50BY2PR03MB442namprd_--


From nobody Wed Feb 24 15:52:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5E11A8AAE for ; Wed, 24 Feb 2016 15:52:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQCUFxxUYlVP for ; Wed, 24 Feb 2016 15:52:22 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCBA1A88CB for ; Wed, 24 Feb 2016 15:52:22 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1ONqLU3032338 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Feb 2016 23:52:21 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1ONqLLD028797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 23:52:21 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1ONqKpE015394; Wed, 24 Feb 2016 23:52:21 GMT
Received: from [192.168.0.22] (/24.67.230.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 15:52:19 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-BE9C60ED-F078-4A27-B307-0F4592971A9A
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Wed, 24 Feb 2016 15:52:17 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! @oracle.com> 
To: Mike Jones 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2016 23:52:28 -0000

--Apple-Mail-BE9C60ED-F078-4A27-B307-0F4592971A9A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Mike

Take a look at the assumptions you are making.=20

You seem to be assuming application software dictates oauth infrastructure a=
rchitecture by suggesting that apps register in iana. =20

Would ms azure allow custom arch?

Phil

> On Feb 24, 2016, at 15:28, Mike Jones  wrote:=

>=20
> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be discovered=
.
> =20
> I agree that for some OAuth profiles, one or more resource servers will ha=
ve to be discovered starting from the authorization server.  Working group m=
embers have also described wanting to discover authorization servers startin=
g from resource servers.  There isn=E2=80=99t a standard practice for any of=
 this, which is why it=E2=80=99s intentionally left out of the current speci=
fication.
> =20
> Once the IANA OAuth Discovery Metadata Registry has been established, whic=
h will happen after the current specification has been approved, it will be e=
asy for subsequent specifications to document existing practice for differen=
t OAuth profiles and register discovery metadata values supporting them.  So=
me of those values will likely define ways to discover resource servers, whe=
n applicable.
> =20
> But first, we need to finish the existing spec, so that the registry enabl=
ing these extensions gets established in the first place.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Yup. And because there many relations the client mist be able to discover i=
t. The client does not know if the res server is legit.=20
> =20
> The userinfo is always fix and so u dont need discovery.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 14:05, Mike Jones  wrote:=

>=20
> In OpenID Connect, there=E2=80=99s a resource server called the UserInfo E=
ndpoint that returns claims about the authenticated user as a JSON data stru=
cture.  Its location is published in OpenID Connect discovery metadata as th=
e =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is defined at ht=
tp://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
> =20
> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth disco=
very spec since in OAuth, there are lots of possible relationships between a=
uthorization servers and resource servers and they needn=E2=80=99t be one-to=
-one, as is being actively discussed by the working group.  For instance, se=
e George Fletcher=E2=80=99s recent contribution.
> =20
> Thanks for the good discussion, Phil.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Where is the profile endpoint (oidc's resource server) published? (For the=
 non OIDC people on the list).=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:=

>=20
> To the extent that generic OAuth 2.0 needs to publish some of the same inf=
ormation as OpenID Connect =E2=80=93 which is built on generic OAuth 2.0 =E2=
=80=93 it makes sense to publish that information using exactly the same syn=
tax, since that syntax is already in widespread use.  That what this draft a=
ccomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response val=
ues like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize",
>    "token_endpoint": "https://server.example.com/token",
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", "priva=
te_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register",
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": "http://server.example.com/service_documentati=
on.html",
> =20
> Is there a reason that you would like the syntax for any of these or the o=
ther generally applicable OAuth 2.0 metadata values to be different?  I don=E2=
=80=99t see any good reason for unnecessary differences to be introduced.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) that i=
s deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be appropriate f=
or oidc but it is not ready for generic oauth. There is no generic oauth exp=
erience at this time.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
>=20
> Sure there is, it is as you have now made it far easier and the security c=
onsiderations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective security=
 difference between discovery information being published in an ad-hoc fashi=
on on developer pages and it being published in a standard format.  =E2=80=9C=
Security by obscurity=E2=80=9D adds no real security at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> > The point of the WGLC is to finish standardizing the core discovery func=
tionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for OAuth. Th=
ere are some authentication mechanism discovery for endpoint that really sho=
uld not be in an OAuth standard since it=E2=80=99s really not dealt with. No=
w that all this information is available it makes poking around the endpoint=
 more focused for people that want to disrupt your endpoints, that is really=
 not addressed in the security considerations section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery functi=
onality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related functional=
ity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applicatio=
ns will use WebFinger to locate the discovery metadata.  Some will possibly u=
se link headers.  Some will possibly use application-specific .well-known va=
lues.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even t=
hought about.  All of these depend upon having a discovery metadata document=
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.
> =20
> So by all means, the working group should continue discussing inventing po=
ssible new related mechanisms that make sense in some contexts.  At the same=
 time, we can finish standardizing the already widely deployed core function=
ality that all of these mechanisms will need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the client i=
ndicating what resource endpoint it wants the oauth configuration data for.=20=

> =20
> So if res.example.evil.com is not a valid resource endpoint for as.example=
.com the authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change the o=
rder of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of authorizati=
on (the resource) is never specified. It is often bound up in the client reg=
istration and an often implied 1:1 relationship between resource and as. Giv=
en that in discovery phase registration has not yet occurred it seems import=
ant that the client know it has a valid combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a starting p=
oint for group adoption but we haven't really defined the full requirements I=
MO.=20
> =20
> I am on vacation or I would put some thought into some draft changes or a n=
ew draft. I apologize I can't do it now.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>=20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? Curren=
tly, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good RS, t=
he client will not send the token there as the authz server will say that is=
 not the place the client may want to send the token to.=20
>=20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client where=
 its authorization server is secure by itself. The relationship between the A=
uthorization Server and the Resource server need to be bound together in one=
 of the discovery endpoints (the resource and/or the oauth service discovery=
).
> =20
> If a client discovers a fake resource server that is proxying for a real r=
esource server the current discovery spec will not lead the client to unders=
tand it has the wrong resource server. Rather the fake resource service will=
 just have a fake discovery service. The hacker can now intercept resource p=
ayload as well as tokens because they were able to convince the client to us=
e the legit authorization service but use the token against the hackers prox=
y.
> =20
> The OAuth Discovery service needs to confirm to the client that the server=
 is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to UMA si=
tuations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> =20
> =20
> =20
>=20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
> =20
>=20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to d=
o discovery, and leave it open to implementers / to other specs to define a .=
well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, r=
eturned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for o=
ther metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-A=
uthenticate response header, you have everything you need to proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually tig=
htly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of the a=
uthz endpoint. In some trusted environment, the resource may as well return t=
he location of the authz server configuration data. In these cases, you do n=
ot have to decide on what .well-known uri as you say. This frees up develope=
rs from configuration file location collisions etc. We should strive not to p=
ollute the uri space as much as possible.=20
> =20
> (well, except if there are several ASs each with different scopes; sounds l=
ike an edge-case to me though; maybe RFC6750 should instead be updated with s=
uch a parameter such that an RS could return several WWW-Authenticate: Beare=
r, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these authz s=
ervers to develop a trust framework under which they can agree on a single s=
et of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
>=20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the ri=
ght direction. It does, however, still have too many vestiges of its OpenID C=
onnect origins. One issue in particular still really bothers me: the use of =E2=
=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery portion. I=
s this an OAuth discovery document, or an OpenID Connect one? There is absol=
utely no compelling reason to tie the URL to the OIDC discovery mechanism.
>=20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other applications SH=
OULD use the same parameter names to describe OAuth endpoints and functions i=
nside their service-specific discovery document.
>=20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-BE9C60ED-F078-4A27-B307-0F4592971A9A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Mike

Take a look at the assumptions y=
ou are making. 

You seem to be assuming application software dictates o=
auth infrastructure architecture by suggesting that apps register in iana. &=
nbsp;

Would ms azure allow custom arch?

Phil

On Feb 24=
, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> wrote:











The UserInfo Endpoint path isn=E2=80=99=
t fixed and so has to be discovered.


 


I agree that for some OAuth profiles, o=
ne or more resource servers will have to be discovered starting from the aut=
horization server.  Working group members have
 also described wanting to discover authorization servers starting from reso=
urce servers.  There isn=E2=80=99t a standard practice for any of this,=
 which is why it=E2=80=99s intentionally left out of the current specificati=
on.


 


Once the IANA OAuth Discovery Metadata R=
egistry has been established, which will happen after the current specificat=
ion has been approved, it will be easy for
 subsequent specifications to document existing practice for different OAuth=
 profiles and register discovery metadata values supporting them.  Some=
 of those values will likely define ways to discover resource servers, when a=
pplicable.


 


But first, we need to finish the existi=
ng spec, so that the registry enabling these extensions gets established in t=
he first place.


 


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


 






From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]


Sent: Wednesday, February 24, 2016 2:13 PM

To: Mike Jones <Mic=
hael.Jones@microsoft.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




Yup. And because there many relations the client mist=
 be able to discover it. The client does not know if the res server is legit=
. 






 






The userinfo is always fix and so u dont need discove=
ry. 



Phil








On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> wrote:








In OpenID Connect, there=E2=80=99s a re=
source server called the UserInfo Endpoint that returns claims about the aut=
henticated user as a JSON data structure.  Its location
 is published in OpenID Connect discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata
 value, which is defined at 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.


 


We didn=E2=80=99t include the UserInfo E=
ndpoint in the generic OAuth discovery spec since in OAuth, there are lots o=
f possible relationships between authorization servers
 and resource servers and they needn=E2=80=99t be one-to-one, as is being ac=
tively discussed by the working group.  For instance, see George Fletch=
er=E2=80=99s recent contribution.


 


Thanks for the good discussion, Phil.


 


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


 






From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]


Sent: Wednesday, February 24, 2016 1:25 PM

To: Mike Jones

Cc: <oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




Where is the profile endpoint (oidc's resource server=
) published? (For the non OIDC people on the list). 



Phil








On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:








To the extent that generic OAuth 2.0 ne=
eds to publish some of the same information as OpenID Connect =E2=80=93 whic=
h is built on generic OAuth 2.0 =E2=80=93 it makes sense to
 publish that information using exactly the same syntax, since that syntax i=
s already in widespread use.  That what this draft accomplishes.=



 


There=E2=80=99s nothing Connect-specifi=
c about using metadata response values like:


 


   "authorization_endpoint": "=
https://server.example.com/=
authorize",


   "token_endpoint": "https://server.example.com/token",=



   "token_endpoint_auth_metho=
ds_supported": ["client_secret_basic", "private_key_jwt"],=



   "registration_endpoint": "=
https://server.example.com/r=
egister",


   "response_types_supported"=
:  ["code", "token"],


   "service_documentation": "=
http://serv=
er.example.com/service_documentation.html",


 


Is there a reason that you would like t=
he syntax for any of these or the other generally applicable OAuth 2.0 metad=
ata values to be different?  I don=E2=80=99t see any
 good reason for unnecessary differences to be introduced.=



 


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


 






From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]


Sent: Wednesday, February 24, 2016 12:45 PM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: Mike Jones <Mic=
hael.Jones@microsoft.com>; <oaut=
h@ietf.org> <oauth@ietf.org&=
gt;

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




Mike






 






Publishing on dev pages does not work for software (e=
sp open source) that is deployed both in enterprises and on PaaS cloud provi=
ders. 






 






The current draft is may codify current OIDC practice=
 and be appropriate for oidc but it is not ready for generic oauth. There is=
 no generic oauth experience at this time. 








Phil








On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> wrote:








Sure there is, it is as you have now ma=
de it far easier and the security considerations does not even address this<=
/span>


 






From: Mike Jones


Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


As we=E2=80=99d discussed in person, th=
ere=E2=80=99s no effective security difference between discovery information=
 being published in an ad-hoc fashion on developer pages and
 it being published in a standard format.  =E2=80=9CSecurity by obscuri=
ty=E2=80=9D adds no real security at all.


 


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


 






From: Anthony Nadalin


Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <Mic=
hael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


> The point of t=
he WGLC is to finish standardizing the core discovery functionality
 that=E2=80=99s already widely deployed.


 


That may be widely deployed for OIDC bu=
t not widely deployed for OAuth. There are some authentication mechanism dis=
covery for endpoint that really should not
 be in an OAuth standard since it=E2=80=99s really not dealt with. Now that a=
ll this information is available it makes poking around the endpoint more fo=
cused for people that want to disrupt your endpoints, that is really not add=
ressed in the security considerations
 section at all 


 






From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <phil.=
hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 


The point of the WGLC is to finish stan=
dardizing the core discovery functionality that=E2=80=99s already widely dep=
loyed.


 


None of Nat or John or I are suggesting=
 that additional related functionality won=E2=80=99t be created.  I=E2=80=
=99m sure it will be.  Some applications will use WebFinger to
 locate the discovery metadata.  Some will possibly use link headers.&n=
bsp; Some will possibly use application-specific .well-known values.  I=
=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even thought a=
bout.  All of these depend upon having a discovery metadata document
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.


 


So by all means, the working group shou=
ld continue discussing inventing possible new related mechanisms that make s=
ense in some contexts.  At the same time, we
 can finish standardizing the already widely deployed core functionality tha=
t all of these mechanisms will need.


 


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


 






From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <sakimura@g=
mail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




I am suggesting that part of the discovery solution h=
as to be the client indicating what resource endpoint it wants the oauth con=
figuration data for. 






 






So if 
res.example.evil.com is not a valid resource endpoint for 
as.example.com the authz discovery should fail in some way (eg return no=
thing). 






 






There may be better ways to do this. Eg combine disco=
very. Or change the order of discovery. 






 






One of OAuth's strength's and weaknesses is that the t=
arget of authorization (the resource) is never specified. It is often bound u=
p in the client registration and an often implied 1:1 relationship between r=
esource and as. Given that in
 discovery phase registration has not yet occurred it seems important that t=
he client know it has a valid combination of endpoints etc. =







 






This is why I was disappointed about wglc on discover=
y. We had a starting point for group adoption but we haven't really defined t=
he full requirements IMO. 






 






I am on vacation or I would put some thought into som=
e draft changes or a new draft. I apologize I can't do it now. 



Phil








On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:










Hi Phil, 




 






Are you suggesting that the AS metadata should includ=
e the RS URIs? Currently, it does not, but it can be done, I guess. 






 






The way oauth-meta works is that 
=






 






1. RS tells the client where the AS is. 






2. AS tells the client which RS endpoints the token c=
an be used. 






 






Even if there is a bad AS with a valid certs that pro=
xies to the good RS, the client will not send the token there as the authz s=
erver will say that is not the place the client may want to send the token t=
o. 










Nat






 






2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4=
) 23:59 Phil Hunt <phil.hu=
nt@oracle.com>:










Nat,






 




I=E2=80=99m not sure that having the resource server t=
ell the client where its authorization server is secure by itself. The relat=
ionship between the Authorization Server and the Resource server need to be b=
ound together in one of the discovery
 endpoints (the resource and/or the oauth service discovery).
=




 








If a client discovers a fake resource server that is p=
roxying for a real resource server the current discovery spec will not lead t=
he client to understand it has the wrong resource server. Rather the fake re=
source service will just have
 a fake discovery service. The hacker can now intercept resource payload as w=
ell as tokens because they were able to convince the client to use the legit=
 authorization service but use the token against the hackers proxy.






 






The OAuth Discovery service needs to confirm to the c=
lient that the server is able to issue tokens for a stated resource endpoint=
.






 






This not only works in normal OAuth but should add se=
curity even to UMA situations.






 


















Phil





 <=
/p>





@independentid











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





 <=
/p>





 <=
/p>



 
















 








On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> w=
rote:




 








Hi Thomas, 




 






inline: 






 






2016=E5=B9=B42=E6=9C=
=8822=E6=97=A5(=E6=9C=88)
 18:44 Thomas Broyer <t.broyer@gmail.com>:








Couldn't the document only describe the metadata?




I quite like the idea of draft-sakimura-oauth-m=
eta if you really want to do discovery, and leave it open to implementers / t=
o other specs to define a .well-known URL for "auto-configuration".






The metadata described here would then either be use=
d as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at t=
he RS; or as a basis for other metadata specs (like
 OpenID Connect). 
















With draft-sakimura-oauth-meta's "duri" and the=
 "scope" attribute of WWW-Authenticate response header, you have everything y=
ou need to proceed 












 






Yup. That's one of the requirements to be RESTful, i=
s it not?  






 






In OAuth's case, the resource and the authorization s=
erver are usually tightly coupled. (Otherwise, you need another specs like U=
MA.) 






So, the resource server should be able to tell eithe=
r the location of the authz endpoint. In some trusted environment, the resou=
rce may as well return the location of the
 authz server configuration data. In these cases, you do not have to decide o=
n what .well-known uri as you say. This frees up developers from configurati=
on file location collisions etc. We should strive not to pollute the uri spa=
ce as much as possible. 






 












(well, except if there are several ASs each with dif=
ferent scopes; sounds like an edge-case to me though; maybe RFC6750 should i=
nstead be updated with such a parameter such
 that an RS could return several WWW-Authenticate: Bearer, each with its own=
 "scope" and "duri" value?)












 






Yeah, I guess it is an edge case. I would rather lik=
e to see these authz servers to develop a trust framework under which they c=
an agree on a single set of common scope parameter
 values. 






 






Cheers, 






 






Nat






 












 






On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu> w=
rote:






The newly-trimmed OAuth Discovery document is helpfu=
l and moving in the right direction. It does, however, still have too many v=
estiges of its OpenID Connect origins. One
 issue in particular still really bothers me: the use of =E2=80=9C/.well-kno=
wn/openid-configuration=E2=80=9D in the discovery portion. Is this an OAuth d=
iscovery document, or an OpenID Connect one? There is absolutely no compelli=
ng reason to tie the URL to the OIDC discovery
 mechanism.



I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other
 applications SHOULD use the same parameter names to describe OAuth endpoint=
s and functions inside their service-specific discovery document.



 =E2=80=94 Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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










_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 











































=

--Apple-Mail-BE9C60ED-F078-4A27-B307-0F4592971A9A--


From nobody Wed Feb 24 16:04:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED061AC3CA for ; Wed, 24 Feb 2016 16:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=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 dyAExjReZhE5 for ; Wed, 24 Feb 2016 16:04:14 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83BE1A9132 for ; Wed, 24 Feb 2016 16:04:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eppz/qC+O+6BdeTorFZU+xLJst3qqdIPX2GwUfVEMCk=; b=hD/NNT9NdqvY/72OiQqHkwvwCnJQz4T98uo1AZdg2+mutrAMFS/lPaRSHuwJrqnO/7b18bfHzokCTd5/SKaluB6gXpmlGk4nC4L1cFKYUWrxp8Fmfn0VW1gYeo489p6wIY5bdbbjIxygGq45yQzIVLP2SPfHb999EcHL/1C5AmY=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 25 Feb 2016 00:04:13 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Thu, 25 Feb 2016 00:04:13 +0000
From: Mike Jones 
To: "Phil Hunt (IDM)" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKwgAAD14CAABMcsIAACLCAgAAAzOA=
Date: Thu, 25 Feb 2016 00:04:12 +0000
Message-ID: 
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>
In-Reply-To: <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:2::7c0]
x-ms-office365-filtering-correlation-id: d568a101-287a-46fa-4057-08d33d77317e
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:AF38okVCHXqcF0WF4baDKa9PM8iY3Iw6cIv4yp3JXRkJwlRw5AzAEnz+QyA9hmZ7LCRpXH8qX/6CX+OfUfAO7z1UZ3ff68SzG8r3UyUSPCU5OKdMQmW7wwHwp5/rWcdDVqW+YQbEWocZkyt6j6rvGw==; 24:vfmm02WsV1vJ/XUM2xT7YhF4yy/FYuHxeSLn5jCQBmch+XnYBgUz1+q6DgEL8z3OCf8/fP72jBC4JnYNRg5a/DA6dwexawGLTZekyqVON1U=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; 
x-forefront-prvs: 08635C03D4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(377454003)(24454002)(19580405001)(586003)(19580395003)(93886004)(74316001)(3280700002)(19625215002)(5003600100002)(33656002)(1220700001)(19609705001)(3660700001)(2900100001)(4326007)(77096005)(15975445007)(2950100001)(2906002)(10290500002)(5005710100001)(5008740100001)(102836003)(5004730100002)(6116002)(790700001)(1096002)(3900700001)(122556002)(10400500002)(8990500004)(40100003)(11100500001)(76576001)(19300405004)(76176999)(92566002)(99286002)(5002640100001)(106116001)(87936001)(19617315012)(86612001)(189998001)(5001960100002)(110136002)(10090500001)(54356999)(50986999)(86362001)(15395725005)(16236675004)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442847F4E292B4AA0498F52F5A60BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2016 00:04:12.8257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 00:04:23 -0000

--_000_BY2PR03MB442847F4E292B4AA0498F52F5A60BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXp1cmUgZGVmaW5lcyB3YXlzIGZvciByZXNvdXJjZSBzZXJ2ZXJzIHRvIGJlIHJlZ2lzdGVyZWQg
Zm9yIHVzZSB3aXRoIGEgY2xpZW50IGFuZCBmb3IgY2xpZW50cyB0byBkeW5hbWljYWxseSByZXF1
ZXN0IGFuIGFjY2VzcyB0b2tlbiBmb3IgdXNlIGF0IGEgcGFydGljdWxhciByZXNvdXJjZSBzZXJ2
ZXIuICBZb3UgY2FuIGNhbGwgdGhhdCBjdXN0b20gYXJjaGl0ZWN0dXJlIGlmIHlvdSB3YW50LiAg
SXTigJlzIHdlbGwtZGVmaW5lZCBidXQgaXTigJlzIG5vdCBjdXJyZW50bHkgaW4gdGhlIHN0YW5k
YXJkcyByZWFsbS4gIEkga25vdyB0aGF0IEdvb2dsZSBoYXMgc3ludGF4IGZvciBkb2luZyB0aGUg
c2FtZSwgYXMgSeKAmW0gc3VyZSBkbyBhIGxvdCBvZiBvdGhlciBjbG91ZCBPQXV0aCBkZXBsb3lt
ZW50cywgc3VjaCBhcyBPcmFjbGXigJlzLiAgRm9yIHdoYXQgaXTigJlzIHdvcnRoLCB0aGUgd29y
a2luZyBncm91cCB0YWxrZWQgYWJvdXQgcG9zc2libHkgcHJvZHVjaW5nIGEgc3RhbmRhcmQgdmVy
c2lvbiBvZiBzeW50YXggZm9yIG1ha2luZyB0aGVzZSBraW5kcyBvZiByZXF1ZXN0cyBkdXJpbmcg
b3VyIGRpc2N1c3Npb25zIGluIFByYWd1ZSAoZHVyaW5nIHRoZSBUb2tlbiBFeGNoYW5nZSBkaXNj
dXNzaW9uKSBidXQgbm9ib2R5IGhhcyBydW4gd2l0aCB0aGlzIHlldC4NCg0KSW4gdGhpcyBzZW5z
ZSwgeWVzLCBBenVyZSBpcyBhbiBhcHBsaWNhdGlvbiBvZiB0aGUga2luZCB3ZeKAmXJlIHRhbGtp
bmcgYWJvdXQuICBBenVyZSBhbHJlYWR5IGRvZXMgZGVmaW5lIHNwZWNpZmljIG5ldyBPQXV0aCAy
LjAgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyB0aGF0IGFyZSB1c2VkIGluIHByb2R1Y3Rpb24u
ICBBIHJlZ2lzdHJ5IGp1c3QgZG9lc27igJl0IHlldCBleGlzdCBpbiB3aGljaCBpdCBjYW4gcmVn
aXN0ZXIgdGhvc2UgdGhhdCBhcmUgb2YgZ2VuZXJhbCBhcHBsaWNhYmlsaXR5Lg0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LS0gTWlrZQ0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMzo1MiBQTQ0KVG86IE1p
a2UgSm9uZXMNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBP
QXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCk1pa2UNCg0KVGFrZSBhIGxvb2sgYXQgdGhl
IGFzc3VtcHRpb25zIHlvdSBhcmUgbWFraW5nLg0KDQpZb3Ugc2VlbSB0byBiZSBhc3N1bWluZyBh
cHBsaWNhdGlvbiBzb2Z0d2FyZSBkaWN0YXRlcyBvYXV0aCBpbmZyYXN0cnVjdHVyZSBhcmNoaXRl
Y3R1cmUgYnkgc3VnZ2VzdGluZyB0aGF0IGFwcHMgcmVnaXN0ZXIgaW4gaWFuYS4NCg0KV291bGQg
bXMgYXp1cmUgYWxsb3cgY3VzdG9tIGFyY2g/DQoNClBoaWwNCg0KT24gRmViIDI0LCAyMDE2LCBh
dCAxNToyOCwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZSBVc2VySW5mbyBFbmRwb2lu
dCBwYXRoIGlzbuKAmXQgZml4ZWQgYW5kIHNvIGhhcyB0byBiZSBkaXNjb3ZlcmVkLg0KDQpJIGFn
cmVlIHRoYXQgZm9yIHNvbWUgT0F1dGggcHJvZmlsZXMsIG9uZSBvciBtb3JlIHJlc291cmNlIHNl
cnZlcnMgd2lsbCBoYXZlIHRvIGJlIGRpc2NvdmVyZWQgc3RhcnRpbmcgZnJvbSB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIuICBXb3JraW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSBhbHNvIGRlc2NyaWJl
ZCB3YW50aW5nIHRvIGRpc2NvdmVyIGF1dGhvcml6YXRpb24gc2VydmVycyBzdGFydGluZyBmcm9t
IHJlc291cmNlIHNlcnZlcnMuICBUaGVyZSBpc27igJl0IGEgc3RhbmRhcmQgcHJhY3RpY2UgZm9y
IGFueSBvZiB0aGlzLCB3aGljaCBpcyB3aHkgaXTigJlzIGludGVudGlvbmFsbHkgbGVmdCBvdXQg
b2YgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbi4NCg0KT25jZSB0aGUgSUFOQSBPQXV0aCBEaXNj
b3ZlcnkgTWV0YWRhdGEgUmVnaXN0cnkgaGFzIGJlZW4gZXN0YWJsaXNoZWQsIHdoaWNoIHdpbGwg
aGFwcGVuIGFmdGVyIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gaGFzIGJlZW4gYXBwcm92ZWQs
IGl0IHdpbGwgYmUgZWFzeSBmb3Igc3Vic2VxdWVudCBzcGVjaWZpY2F0aW9ucyB0byBkb2N1bWVu
dCBleGlzdGluZyBwcmFjdGljZSBmb3IgZGlmZmVyZW50IE9BdXRoIHByb2ZpbGVzIGFuZCByZWdp
c3RlciBkaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzIHN1cHBvcnRpbmcgdGhlbS4gIFNvbWUgb2Yg
dGhvc2UgdmFsdWVzIHdpbGwgbGlrZWx5IGRlZmluZSB3YXlzIHRvIGRpc2NvdmVyIHJlc291cmNl
IHNlcnZlcnMsIHdoZW4gYXBwbGljYWJsZS4NCg0KQnV0IGZpcnN0LCB3ZSBuZWVkIHRvIGZpbmlz
aCB0aGUgZXhpc3Rpbmcgc3BlYywgc28gdGhhdCB0aGUgcmVnaXN0cnkgZW5hYmxpbmcgdGhlc2Ug
ZXh0ZW5zaW9ucyBnZXRzIGVzdGFibGlzaGVkIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0tIE1pa2UNCg0KRnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDI6MTMgUE0NClRvOiBN
aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz4+IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDog
UmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQpZdXAuIEFuZCBi
ZWNhdXNlIHRoZXJlIG1hbnkgcmVsYXRpb25zIHRoZSBjbGllbnQgbWlzdCBiZSBhYmxlIHRvIGRp
c2NvdmVyIGl0LiBUaGUgY2xpZW50IGRvZXMgbm90IGtub3cgaWYgdGhlIHJlcyBzZXJ2ZXIgaXMg
bGVnaXQuDQoNClRoZSB1c2VyaW5mbyBpcyBhbHdheXMgZml4IGFuZCBzbyB1IGRvbnQgbmVlZCBk
aXNjb3ZlcnkuDQoNClBoaWwNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAxNDowNSwgTWlrZSBKb25l
cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb20+PiB3cm90ZToNCkluIE9wZW5JRCBDb25uZWN0LCB0aGVyZeKAmXMgYSByZXNvdXJj
ZSBzZXJ2ZXIgY2FsbGVkIHRoZSBVc2VySW5mbyBFbmRwb2ludCB0aGF0IHJldHVybnMgY2xhaW1z
IGFib3V0IHRoZSBhdXRoZW50aWNhdGVkIHVzZXIgYXMgYSBKU09OIGRhdGEgc3RydWN0dXJlLiAg
SXRzIGxvY2F0aW9uIGlzIHB1Ymxpc2hlZCBpbiBPcGVuSUQgQ29ubmVjdCBkaXNjb3ZlcnkgbWV0
YWRhdGEgYXMgdGhlIOKAnHVzZXJpbmZvX2VuZHBvaW504oCdIG1ldGFkYXRhIHZhbHVlLCB3aGlj
aCBpcyBkZWZpbmVkIGF0IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRp
c2NvdmVyeS0xXzAuaHRtbCNQcm92aWRlck1ldGFkYXRhLg0KDQpXZSBkaWRu4oCZdCBpbmNsdWRl
IHRoZSBVc2VySW5mbyBFbmRwb2ludCBpbiB0aGUgZ2VuZXJpYyBPQXV0aCBkaXNjb3Zlcnkgc3Bl
YyBzaW5jZSBpbiBPQXV0aCwgdGhlcmUgYXJlIGxvdHMgb2YgcG9zc2libGUgcmVsYXRpb25zaGlw
cyBiZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgcmVzb3VyY2Ugc2VydmVycyBhbmQg
dGhleSBuZWVkbuKAmXQgYmUgb25lLXRvLW9uZSwgYXMgaXMgYmVpbmcgYWN0aXZlbHkgZGlzY3Vz
c2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAgRm9yIGluc3RhbmNlLCBzZWUgR2VvcmdlIEZsZXRj
aGVy4oCZcyByZWNlbnQgY29udHJpYnV0aW9uLg0KDQpUaGFua3MgZm9yIHRoZSBnb29kIGRpc2N1
c3Npb24sIFBoaWwuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBb
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAy
NCwgMjAxNiAxOjI1IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWls
dG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERp
c2NvdmVyeSBMb2NhdGlvbg0KDQpXaGVyZSBpcyB0aGUgcHJvZmlsZSBlbmRwb2ludCAob2lkYydz
IHJlc291cmNlIHNlcnZlcikgcHVibGlzaGVkPyAoRm9yIHRoZSBub24gT0lEQyBwZW9wbGUgb24g
dGhlIGxpc3QpLg0KDQpQaGlsDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTM6MDksIE1pa2UgSm9u
ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPj4gd3JvdGU6DQpUbyB0aGUgZXh0ZW50IHRoYXQgZ2VuZXJpYyBPQXV0aCAyLjAg
bmVlZHMgdG8gcHVibGlzaCBzb21lIG9mIHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIE9wZW5JRCBD
b25uZWN0IOKAkyB3aGljaCBpcyBidWlsdCBvbiBnZW5lcmljIE9BdXRoIDIuMCDigJMgaXQgbWFr
ZXMgc2Vuc2UgdG8gcHVibGlzaCB0aGF0IGluZm9ybWF0aW9uIHVzaW5nIGV4YWN0bHkgdGhlIHNh
bWUgc3ludGF4LCBzaW5jZSB0aGF0IHN5bnRheCBpcyBhbHJlYWR5IGluIHdpZGVzcHJlYWQgdXNl
LiAgVGhhdCB3aGF0IHRoaXMgZHJhZnQgYWNjb21wbGlzaGVzLg0KDQpUaGVyZeKAmXMgbm90aGlu
ZyBDb25uZWN0LXNwZWNpZmljIGFib3V0IHVzaW5nIG1ldGFkYXRhIHJlc3BvbnNlIHZhbHVlcyBs
aWtlOg0KDQogICAiYXV0aG9yaXphdGlvbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFt
cGxlLmNvbS9hdXRob3JpemUiLA0KICAgInRva2VuX2VuZHBvaW50IjogImh0dHBzOi8vc2VydmVy
LmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3Vw
cG9ydGVkIjogWyJjbGllbnRfc2VjcmV0X2Jhc2ljIiwgInByaXZhdGVfa2V5X2p3dCJdLA0KICAg
InJlZ2lzdHJhdGlvbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdp
c3RlciIsDQogICAicmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkIjogIFsiY29kZSIsICJ0b2tlbiJd
LA0KICAgInNlcnZpY2VfZG9jdW1lbnRhdGlvbiI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29t
L3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sIiwNCg0KSXMgdGhlcmUgYSByZWFzb24gdGhhdCB5
b3Ugd291bGQgbGlrZSB0aGUgc3ludGF4IGZvciBhbnkgb2YgdGhlc2Ugb3IgdGhlIG90aGVyIGdl
bmVyYWxseSBhcHBsaWNhYmxlIE9BdXRoIDIuMCBtZXRhZGF0YSB2YWx1ZXMgdG8gYmUgZGlmZmVy
ZW50PyAgSSBkb27igJl0IHNlZSBhbnkgZ29vZCByZWFzb24gZm9yIHVubmVjZXNzYXJ5IGRpZmZl
cmVuY2VzIHRvIGJlIGludHJvZHVjZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFBoaWwg
SHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5
LCBGZWJydWFyeSAyNCwgMjAxNiAxMjo0NSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5h
ZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IE1pa2Ug
Sm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0Bt
aWNyb3NvZnQuY29tPj47IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8
b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FV
VEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KTWlrZQ0KDQpQdWJsaXNoaW5n
IG9uIGRldiBwYWdlcyBkb2VzIG5vdCB3b3JrIGZvciBzb2Z0d2FyZSAoZXNwIG9wZW4gc291cmNl
KSB0aGF0IGlzIGRlcGxveWVkIGJvdGggaW4gZW50ZXJwcmlzZXMgYW5kIG9uIFBhYVMgY2xvdWQg
cHJvdmlkZXJzLg0KDQpUaGUgY3VycmVudCBkcmFmdCBpcyBtYXkgY29kaWZ5IGN1cnJlbnQgT0lE
QyBwcmFjdGljZSBhbmQgYmUgYXBwcm9wcmlhdGUgZm9yIG9pZGMgYnV0IGl0IGlzIG5vdCByZWFk
eSBmb3IgZ2VuZXJpYyBvYXV0aC4gVGhlcmUgaXMgbm8gZ2VuZXJpYyBvYXV0aCBleHBlcmllbmNl
IGF0IHRoaXMgdGltZS4NCg0KUGhpbA0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDEwOjI1LCBBbnRo
b255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3Nv
ZnQuY29tPj4gd3JvdGU6DQpTdXJlIHRoZXJlIGlzLCBpdCBpcyBhcyB5b3UgaGF2ZSBub3cgbWFk
ZSBpdCBmYXIgZWFzaWVyIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9lcyBub3Qg
ZXZlbiBhZGRyZXNzIHRoaXMNCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAyNCwgMjAxNiAxMDoyMiBBTQ0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBt
aWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9h
dXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3Zl
cnkgTG9jYXRpb24NCg0KQXMgd2XigJlkIGRpc2N1c3NlZCBpbiBwZXJzb24sIHRoZXJl4oCZcyBu
byBlZmZlY3RpdmUgc2VjdXJpdHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGRpc2NvdmVyeSBpbmZvcm1h
dGlvbiBiZWluZyBwdWJsaXNoZWQgaW4gYW4gYWQtaG9jIGZhc2hpb24gb24gZGV2ZWxvcGVyIHBh
Z2VzIGFuZCBpdCBiZWluZyBwdWJsaXNoZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQuICDigJxTZWN1
cml0eSBieSBvYnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC4NCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t
IE1pa2UNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5
IDI0LCAyMDE2IDEwOjAxIEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv
ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgUGhpbCBIdW50IChJ
RE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pjsg
TmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNv
bT4+DQpDYzogPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+IDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQo+IFRoZSBwb2ludCBvZiB0aGUgV0dMQyBp
cyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0
eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC4NCg0KVGhhdCBtYXkgYmUgd2lkZWx5
IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVkIGZvciBPQXV0aC4gVGhl
cmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2NvdmVyeSBmb3IgZW5kcG9p
bnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBPQXV0aCBzdGFuZGFyZCBzaW5jZSBp
dOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlv
biBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0aGUgZW5kcG9pbnQgbW9yZSBm
b2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1cHQgeW91ciBlbmRwb2ludHMsIHRo
YXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z
IHNlY3Rpb24gYXQgYWxsDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkg
MjQsIDIwMTYgOTo1NCBBTQ0KVG86IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5j
b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFA
Z21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9y
ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll
dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9j
YXRpb24NCg0KVGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5n
IHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5
IGRlcGxveWVkLg0KDQpOb25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhh
dCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0ZWQuICBJ
4oCZbSBzdXJlIGl0IHdpbGwgYmUuICBTb21lIGFwcGxpY2F0aW9ucyB3aWxsIHVzZSBXZWJGaW5n
ZXIgdG8gbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuICBTb21lIHdpbGwgcG9zc2libHkg
dXNlIGxpbmsgaGVhZGVycy4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgYXBwbGljYXRpb24tc3Bl
Y2lmaWMgLndlbGwta25vd24gdmFsdWVzLiAgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhp
bmdzIEkgaGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4gIEFsbCBvZiB0aGVzZSBkZXBlbmQg
dXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgZm9ybWF0IGFuZCBub25l
IG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRvIHJlZ2lzdGVyIGFk
ZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy4NCg0KU28gYnkgYWxsIG1lYW5zLCB0
aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9z
c2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250
ZXh0cy4gIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUg
YWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRo
ZXNlIG1lY2hhbmlzbXMgd2lsbCBuZWVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElETSkN
ClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgODozOSBBTQ0KVG86IE5hdCBTYWtp
bXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0KQ2M6
IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PiA8b2F1dGhAaWV0Zi5vcmc8
bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIu
MCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KSSBhbSBzdWdnZXN0aW5nIHRoYXQgcGFydCBvZiB0aGUg
ZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGluZGljYXRpbmcgd2hhdCBy
ZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmlndXJhdGlvbiBkYXRhIGZv
ci4NCg0KU28gaWYgcmVzLmV4YW1wbGUuZXZpbC5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w
cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnJlcy5leGFtcGxlLmV2aWwu
Y29tJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZj
NGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3
YzEmc2RhdGE9UGMlMmI3aWxuRFlnZmpZb1RzUVdvWm5wb2JHJTJiVkpwNVd1OWNHcEZVZ3ozUzAl
M2Q+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50IGZvciBhcy5leGFtcGxlLmNvbTxo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNh
JTJmJTJmYXMuZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5j
b20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3YzcyZjk4OGJmODZmMTQxYWY5
MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT02JTJicXhoJTJmN1ZDWmtzd1hoSk12NnIlMmIxOGRU
UmJnMklzMTJXQiUyZmRabTNjSjQlM2Q+IHRoZSBhdXRoeiBkaXNjb3Zlcnkgc2hvdWxkIGZhaWwg
aW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5nKS4NCg0KVGhlcmUgbWF5IGJlIGJldHRlciB3
YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5LiBPciBjaGFuZ2UgdGhlIG9yZGVy
IG9mIGRpc2NvdmVyeS4NCg0KT25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25lc3Nl
cyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBpcyBu
ZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVnaXN0
cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiByZXNv
dXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBo
YXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhhdCB0aGUgY2xpZW50IGtu
b3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5kcG9pbnRzIGV0Yy4NCg0KVGhpcyBp
cyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdnbGMgb24gZGlzY292ZXJ5LiBXZSBoYWQg
YSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRpb24gYnV0IHdlIGhhdmVuJ3QgcmVhbGx5
IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElNTy4NCg0KSSBhbSBvbiB2YWNhdGlvbiBv
ciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21lIGRyYWZ0IGNoYW5nZXMgb3IgYSBu
ZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQgbm93Lg0KDQpQaGlsDQoNCk9uIEZl
YiAyNCwgMjAxNiwgYXQgMDg6MTIsIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1h
aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFBoaWwsDQoNCkFyZSB5b3Ugc3Vn
Z2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8g
Q3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLg0KDQpU
aGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdA0KDQoxLiBSUyB0ZWxscyB0aGUgY2xpZW50
IHdoZXJlIHRoZSBBUyBpcy4NCjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9p
bnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4NCg0KRXZlbiBpZiB0aGVyZSBpcyBhIGJhZCBBUyB3
aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJTLCB0aGUgY2xpZW50
IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBzZXJ2ZXIgd2lsbCBz
YXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8gc2VuZCB0aGUg
dG9rZW4gdG8uDQoNCk5hdA0KDQoyMDE25bm0MuaciDI05pelKOawtCkgMjM6NTkgUGhpbCBIdW50
IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCk5h
dCwNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNlcnZlciB0ZWxs
IHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNlY3VyZSBieSBp
dHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg
YW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhlciBpbiBvbmUg
b2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNvdXJjZSBhbmQvb3IgdGhlIG9hdXRo
IHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KSWYgYSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNv
dXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWluZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0
aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5k
ZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJlc291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtl
IHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0IGhhdmUgYSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNl
LiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2VsbCBh
cyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50IHRv
IHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFn
YWluc3QgdGhlIGhhY2tlcnMgcHJveHkuDQoNClRoZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBu
ZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8g
aXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBlbmRwb2ludC4NCg0KVGhpcyBub3Qg
b25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0
byBVTUEgc2l0dWF0aW9ucy4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5k
ZW50aWQuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5jb20mZGF0YT0wMSU3YzAxJTdjdG9u
eW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3
YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1NSldwRkIxMnZUTEI0
ZWNLeVl3bFpMblJKSW5hTkV3MU13bHZ0VTI2QlBBJTNkPg0KcGhpbC5odW50QG9yYWNsZS5jb208
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0
IDM6NTQgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpIaSBUaG9tYXMsDQoNCmlubGluZToNCg0KMjAxNuW5
tDLmnIgyMuaXpSjmnIgpIDE4OjQ0IFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbTxt
YWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46DQpDb3VsZG4ndCB0aGUgZG9jdW1lbnQgb25seSBk
ZXNjcmliZSB0aGUgbWV0YWRhdGE/DQpJIHF1aXRlIGxpa2UgdGhlIGlkZWEgb2YgZHJhZnQtc2Fr
aW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQg
bGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0byBvdGhlciBzcGVjcyB0byBkZWZpbmUg
YSAud2VsbC1rbm93biBVUkwgZm9yICJhdXRvLWNvbmZpZ3VyYXRpb24iLg0KVGhlIG1ldGFkYXRh
IGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJlIHVzZWQgYXMtaXMsIGF0IGFueSBV
UkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgbWV0YWRhdGEgYXQgdGhl
IFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBtZXRhZGF0YSBzcGVjcyAobGlrZSBPcGVuSUQg
Q29ubmVjdCkuDQpXaXRoIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEncyAiZHVyaSIgYW5kIHRo
ZSAic2NvcGUiIGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciwg
eW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9jZWVkDQoNCll1cC4gVGhhdCdzIG9u
ZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWwsIGlzIGl0IG5vdD8NCg0KSW4gT0F1
dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUg
dXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlvdSBuZWVkIGFub3RoZXIgc3Bl
Y3MgbGlrZSBVTUEuKQ0KU28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8g
dGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2ludC4gSW4gc29tZSB0
cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwgcmV0dXJuIHRoZSBs
b2NhdGlvbiBvZiB0aGUgYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2Ug
Y2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkg
YXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBm
aWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xs
dXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KKHdlbGwsIGV4Y2VwdCBp
ZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5k
cyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGlu
c3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3VjaCB0aGF0IGFuIFJTIGNv
dWxkIHJldHVybiBzZXZlcmFsIFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciwgZWFjaCB3aXRoIGl0
cyBvd24gInNjb3BlIiBhbmQgImR1cmkiIHZhbHVlPykNCg0KWWVhaCwgSSBndWVzcyBpdCBpcyBh
biBlZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZl
cnMgdG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3Jl
ZSBvbiBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuDQoNCkNo
ZWVycywNCg0KTmF0DQoNCg0KT24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMTA6NTkgUE0gSnVzdGlu
IFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToN
ClRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2NvdmVyeSBkb2N1bWVudCBpcyBoZWxwZnVsIGFu
ZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi4gSXQgZG9lcywgaG93ZXZlciwgc3RpbGwg
aGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMgT3BlbklEIENvbm5lY3Qgb3JpZ2lucy4gT25l
IGlzc3VlIGluIHBhcnRpY3VsYXIgc3RpbGwgcmVhbGx5IGJvdGhlcnMgbWU6IHRoZSB1c2Ugb2Yg
4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGluIHRoZSBkaXNjb3Zlcnkg
cG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0aCBkaXNjb3ZlcnkgZG9jdW1lbnQsIG9yIGFuIE9wZW5J
RCBDb25uZWN0IG9uZT8gVGhlcmUgaXMgYWJzb2x1dGVseSBubyBjb21wZWxsaW5nIHJlYXNvbiB0
byB0aWUgdGhlIFVSTCB0byB0aGUgT0lEQyBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KDQpJIHByb3Bv
c2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy
4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5kIHN0YXRlIHRoYXQgdGhl
IGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8ud2VsbC1rbm93bi9vcGVu
aWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28gcHJvdmlkZXMgT3BlbklEIENv
bm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlciBhcHBsaWNhdGlvbnMgU0hPVUxEIHVzZSB0
aGUgc2FtZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5kcG9pbnRzIGFuZCBm
dW5jdGlvbnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292ZXJ5IGRvY3VtZW50
Lg0KDQog4oCUIEp1c3Rpbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQz
M2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28x
RmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz
dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxt
YW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3
TjdFSng0MHBaUEp4dGw0JTNkPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
cyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9
MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcw
OGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9
Z28xRmhMJTJiRGE2eUJTS21jczN3cWw3MUJza1k3TjdFSng0MHBaUEp4dGw0JTNkPg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

--_000_BY2PR03MB442847F4E292B4AA0498F52F5A60BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg
MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6
MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7
DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiTWFsZ3VuIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA1IDMg
MiAwIDAgMiAwIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNYWxndW4gR290aGlj
IjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u
cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46
MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4
dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFs
bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv
bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIw
NjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u
RW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwMjA2MDsNCglmb250LXdlaWdodDpub3Jt
YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpz
cGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm
b250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1h
aWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF6dXJlIGRlZmluZXMgd2F5
cyBmb3IgcmVzb3VyY2Ugc2VydmVycyB0byBiZSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIGNs
aWVudCBhbmQgZm9yIGNsaWVudHMgdG8gZHluYW1pY2FsbHkgcmVxdWVzdCBhbiBhY2Nlc3MgdG9r
ZW4gZm9yIHVzZSBhdCBhIHBhcnRpY3VsYXINCiByZXNvdXJjZSBzZXJ2ZXIuJm5ic3A7IFlvdSBj
YW4gY2FsbCB0aGF0IGN1c3RvbSBhcmNoaXRlY3R1cmUgaWYgeW91IHdhbnQuJm5ic3A7IEl04oCZ
cyB3ZWxsLWRlZmluZWQgYnV0IGl04oCZcyBub3QgY3VycmVudGx5IGluIHRoZSBzdGFuZGFyZHMg
cmVhbG0uJm5ic3A7IEkga25vdyB0aGF0IEdvb2dsZSBoYXMgc3ludGF4IGZvciBkb2luZyB0aGUg
c2FtZSwgYXMgSeKAmW0gc3VyZSBkbyBhIGxvdCBvZiBvdGhlciBjbG91ZCBPQXV0aCBkZXBsb3lt
ZW50cywgc3VjaCBhcyBPcmFjbGXigJlzLiZuYnNwOw0KIEZvciB3aGF0IGl04oCZcyB3b3J0aCwg
dGhlIHdvcmtpbmcgZ3JvdXAgdGFsa2VkIGFib3V0IHBvc3NpYmx5IHByb2R1Y2luZyBhIHN0YW5k
YXJkIHZlcnNpb24gb2Ygc3ludGF4IGZvciBtYWtpbmcgdGhlc2Uga2luZHMgb2YgcmVxdWVzdHMg
ZHVyaW5nIG91ciBkaXNjdXNzaW9ucyBpbiBQcmFndWUgKGR1cmluZyB0aGUgVG9rZW4gRXhjaGFu
Z2UgZGlzY3Vzc2lvbikgYnV0IG5vYm9keSBoYXMgcnVuIHdpdGggdGhpcyB5ZXQuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5JbiB0aGlzIHNlbnNlLCB5ZXMsIEF6dXJlIGlzIGFuIGFwcGxpY2F0aW9uIG9mIHRoZSBraW5k
IHdl4oCZcmUgdGFsa2luZyBhYm91dC4mbmJzcDsgQXp1cmUgYWxyZWFkeSBkb2VzIGRlZmluZSBz
cGVjaWZpYyBuZXcgT0F1dGggMi4wIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMgdGhhdA0KIGFy
ZSB1c2VkIGluIHByb2R1Y3Rpb24uJm5ic3A7IEEgcmVnaXN0cnkganVzdCBkb2VzbuKAmXQgeWV0
IGV4aXN0IGluIHdoaWNoIGl0IGNhbiByZWdpc3RlciB0aG9zZSB0aGF0IGFyZSBvZiBnZW5lcmFs
IGFwcGxpY2FiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCAoSURNKSBbbWFpbHRv
OnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVi
cnVhcnkgMjQsIDIwMTYgMzo1MiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxi
PkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2U8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu
YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFrZSBhIGxvb2sgYXQgdGhlIGFzc3VtcHRp
b25zIHlvdSBhcmUgbWFraW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5Zb3Ugc2VlbSB0byBiZSBhc3N1bWluZyBhcHBsaWNhdGlvbiBzb2Z0d2Fy
ZSBkaWN0YXRlcyBvYXV0aCBpbmZyYXN0cnVjdHVyZSBhcmNoaXRlY3R1cmUgYnkgc3VnZ2VzdGlu
ZyB0aGF0IGFwcHMgcmVnaXN0ZXIgaW4gaWFuYS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJl
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIG1zIGF6dXJlIGFsbG93IGN1c3RvbSBhcmNo
Pzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRmViIDI0
LCAyMDE2LCBhdCAxNToyOCwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5UaGUgVXNlcklu
Zm8gRW5kcG9pbnQgcGF0aCBpc27igJl0IGZpeGVkIGFuZCBzbyBoYXMgdG8gYmUgZGlzY292ZXJl
ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDIwNjAiPkkgYWdyZWUgdGhhdCBmb3Igc29tZSBPQXV0aCBwcm9maWxlcywgb25lIG9y
IG1vcmUgcmVzb3VyY2Ugc2VydmVycyB3aWxsIGhhdmUgdG8gYmUgZGlzY292ZXJlZCBzdGFydGlu
ZyBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gJm5ic3A7V29ya2luZyBncm91cCBtZW1i
ZXJzDQogaGF2ZSBhbHNvIGRlc2NyaWJlZCB3YW50aW5nIHRvIGRpc2NvdmVyIGF1dGhvcml6YXRp
b24gc2VydmVycyBzdGFydGluZyBmcm9tIHJlc291cmNlIHNlcnZlcnMuJm5ic3A7IFRoZXJlIGlz
buKAmXQgYSBzdGFuZGFyZCBwcmFjdGljZSBmb3IgYW55IG9mIHRoaXMsIHdoaWNoIGlzIHdoeSBp
dOKAmXMgaW50ZW50aW9uYWxseSBsZWZ0IG91dCBvZiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9u
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzAwMjA2MCI+T25jZSB0aGUgSUFOQSBPQXV0aCBEaXNjb3ZlcnkgTWV0YWRhdGEgUmVnaXN0
cnkgaGFzIGJlZW4gZXN0YWJsaXNoZWQsIHdoaWNoIHdpbGwgaGFwcGVuIGFmdGVyIHRoZSBjdXJy
ZW50IHNwZWNpZmljYXRpb24gaGFzIGJlZW4gYXBwcm92ZWQsIGl0IHdpbGwgYmUgZWFzeSBmb3IN
CiBzdWJzZXF1ZW50IHNwZWNpZmljYXRpb25zIHRvIGRvY3VtZW50IGV4aXN0aW5nIHByYWN0aWNl
IGZvciBkaWZmZXJlbnQgT0F1dGggcHJvZmlsZXMgYW5kIHJlZ2lzdGVyIGRpc2NvdmVyeSBtZXRh
ZGF0YSB2YWx1ZXMgc3VwcG9ydGluZyB0aGVtLiZuYnNwOyBTb21lIG9mIHRob3NlIHZhbHVlcyB3
aWxsIGxpa2VseSBkZWZpbmUgd2F5cyB0byBkaXNjb3ZlciByZXNvdXJjZSBzZXJ2ZXJzLCB3aGVu
IGFwcGxpY2FibGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDAyMDYwIj5CdXQgZmlyc3QsIHdlIG5lZWQgdG8gZmluaXNoIHRoZSBl
eGlzdGluZyBzcGVjLCBzbyB0aGF0IHRoZSByZWdpc3RyeSBlbmFibGluZyB0aGVzZSBleHRlbnNp
b25zIGdldHMgZXN0YWJsaXNoZWQgaW4gdGhlIGZpcnN0IHBsYWNlLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t
Ij5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMjoxMyBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBK
b25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBo
cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDsgJmx0Ozxh
IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0
aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pll1cC4gQW5kIGJlY2F1c2UgdGhlcmUgbWFueSByZWxhdGlvbnMgdGhlIGNsaWVudCBtaXN0IGJl
IGFibGUgdG8gZGlzY292ZXIgaXQuIFRoZSBjbGllbnQgZG9lcyBub3Qga25vdyBpZiB0aGUgcmVz
IHNlcnZlciBpcyBsZWdpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i
QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIHVzZXJpbmZvIGlzIGFsd2F5cyBmaXggYW5kIHNvIHUgZG9udCBuZWVk
IGRpc2NvdmVyeS4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
Pjxicj4NCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTQ6MDUsIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9
Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SW4gT3BlbklEIENvbm5lY3QsIHRoZXJl4oCZcyBhIHJlc291cmNlIHNlcnZlciBjYWxs
ZWQgdGhlIFVzZXJJbmZvIEVuZHBvaW50IHRoYXQgcmV0dXJucyBjbGFpbXMgYWJvdXQgdGhlIGF1
dGhlbnRpY2F0ZWQgdXNlciBhcyBhIEpTT04gZGF0YSBzdHJ1Y3R1cmUuJm5ic3A7IEl0cyBsb2Nh
dGlvbg0KIGlzIHB1Ymxpc2hlZCBpbiBPcGVuSUQgQ29ubmVjdCBkaXNjb3ZlcnkgbWV0YWRhdGEg
YXMgdGhlIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnVzZXJpbmZv
X2VuZHBvaW50PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij7igJ0gbWV0YWRhdGENCiB2YWx1ZSwgd2hpY2ggaXMgZGVmaW5lZCBhdCA8YSBocmVmPSJodHRw
Oi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjUHJv
dmlkZXJNZXRhZGF0YSI+DQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1k
aXNjb3ZlcnktMV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YTwvYT4uPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBkaWRu
4oCZdCBpbmNsdWRlIHRoZSBVc2VySW5mbyBFbmRwb2ludCBpbiB0aGUgZ2VuZXJpYyBPQXV0aCBk
aXNjb3Zlcnkgc3BlYyBzaW5jZSBpbiBPQXV0aCwgdGhlcmUgYXJlIGxvdHMgb2YgcG9zc2libGUg
cmVsYXRpb25zaGlwcyBiZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycw0KIGFuZCByZXNvdXJj
ZSBzZXJ2ZXJzIGFuZCB0aGV5IG5lZWRu4oCZdCBiZSBvbmUtdG8tb25lLCBhcyBpcyBiZWluZyBh
Y3RpdmVseSBkaXNjdXNzZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IEZvciBpbnN0YW5j
ZSwgc2VlIEdlb3JnZSBGbGV0Y2hlcuKAmXMgcmVjZW50IGNvbnRyaWJ1dGlvbi48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlRoYW5rcyBmb3IgdGhlIGdvb2QgZGlzY3Vzc2lvbiwgUGhpbC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu
IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBoaWwg
SHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5tYWlsdG86
cGhpbC5odW50QG9yYWNsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg
RmVicnVhcnkgMjQsIDIwMTYgMToyNSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4N
CjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0
Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAy
LjAgRGlzY292ZXJ5IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPldoZXJlIGlzIHRoZSBwcm9maWxlIGVuZHBvaW50IChvaWRjJ3Mg
cmVzb3VyY2Ugc2VydmVyKSBwdWJsaXNoZWQ/IChGb3IgdGhlIG5vbiBPSURDIHBlb3BsZSBvbiB0
aGUgbGlzdCkuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
YnI+DQpPbiBGZWIgMjQsIDIwMTYsIGF0IDEzOjA5LCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt
YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIw
NjAiPlRvIHRoZSBleHRlbnQgdGhhdCBnZW5lcmljIE9BdXRoIDIuMCBuZWVkcyB0byBwdWJsaXNo
IHNvbWUgb2YgdGhlIHNhbWUgaW5mb3JtYXRpb24gYXMgT3BlbklEIENvbm5lY3Qg4oCTIHdoaWNo
IGlzIGJ1aWx0IG9uIGdlbmVyaWMgT0F1dGggMi4wIOKAkyBpdCBtYWtlcyBzZW5zZQ0KIHRvIHB1
Ymxpc2ggdGhhdCBpbmZvcm1hdGlvbiB1c2luZyBleGFjdGx5IHRoZSBzYW1lIHN5bnRheCwgc2lu
Y2UgdGhhdCBzeW50YXggaXMgYWxyZWFkeSBpbiB3aWRlc3ByZWFkIHVzZS4mbmJzcDsgVGhhdCB3
aGF0IHRoaXMgZHJhZnQgYWNjb21wbGlzaGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYw
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhlcmXigJlzIG5vdGhpbmcg
Q29ubmVjdC1zcGVjaWZpYyBhYm91dCB1c2luZyBtZXRhZGF0YSByZXNwb25zZSB2YWx1ZXMgbGlr
ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyAmcXVvdDthdXRob3JpemF0aW9uX2VuZHBvaW50JnF1
b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRob3JpemUi
Pmh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGhvcml6ZTwvYT4mcXVvdDssPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludCZx
dW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iPmh0
dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuPC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7ICZxdW90O3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0
aG9kc19zdXBwb3J0ZWQmcXVvdDs6IFsmcXVvdDtjbGllbnRfc2VjcmV0X2Jhc2ljJnF1b3Q7LCAm
cXVvdDtwcml2YXRlX2tleV9qd3QmcXVvdDtdLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYw
Ij4mbmJzcDsmbmJzcDsgJnF1b3Q7cmVnaXN0cmF0aW9uX2VuZHBvaW50JnF1b3Q7OiAmcXVvdDs8
YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdpc3RlciI+aHR0cHM6Ly9zZXJ2
ZXIuZXhhbXBsZS5jb20vcmVnaXN0ZXI8L2E+JnF1b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7cmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkJnF1b3Q7
OiZuYnNwOyBbJnF1b3Q7Y29kZSZxdW90OywgJnF1b3Q7dG9rZW4mcXVvdDtdLDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsgJnF1b3Q7c2VydmljZV9kb2N1bWVudGF0
aW9uJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZp
Y2VfZG9jdW1lbnRhdGlvbi5odG1sIj5odHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2Vf
ZG9jdW1lbnRhdGlvbi5odG1sPC9hPiZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPklzIHRoZXJlIGEgcmVhc29u
IHRoYXQgeW91IHdvdWxkIGxpa2UgdGhlIHN5bnRheCBmb3IgYW55IG9mIHRoZXNlIG9yIHRoZSBv
dGhlciBnZW5lcmFsbHkgYXBwbGljYWJsZSBPQXV0aCAyLjAgbWV0YWRhdGEgdmFsdWVzIHRvIGJl
IGRpZmZlcmVudD8mbmJzcDsgSSBkb27igJl0IHNlZQ0KIGFueSBnb29kIHJlYXNvbiBmb3IgdW5u
ZWNlc3NhcnkgZGlmZmVyZW5jZXMgdG8gYmUgaW50cm9kdWNlZC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiBQaGlsIEh1bnQgKElETSkgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEyOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255
IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnlu
YWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDs8
YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu
b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FV
VEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVy
ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QdWJsaXNoaW5nIG9uIGRldiBwYWdlcyBkb2VzIG5v
dCB3b3JrIGZvciBzb2Z0d2FyZSAoZXNwIG9wZW4gc291cmNlKSB0aGF0IGlzIGRlcGxveWVkIGJv
dGggaW4gZW50ZXJwcmlzZXMgYW5kIG9uIFBhYVMgY2xvdWQgcHJvdmlkZXJzLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFw
cGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCBkcmFm
dCBpcyBtYXkgY29kaWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBhbmQgYmUgYXBwcm9wcmlhdGUg
Zm9yIG9pZGMgYnV0IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJpYyBvYXV0aC4gVGhlcmUgaXMg
bm8gZ2VuZXJpYyBvYXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGltZS4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRmVi
IDI0LCAyMDE2LCBhdCAxMDoyNSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86
dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cmUgdGhlcmUgaXMs
IGl0IGlzIGFzIHlvdSBoYXZlIG5vdyBtYWRlIGl0IGZhciBlYXNpZXIgYW5kIHRoZSBzZWN1cml0
eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBldmVuIGFkZHJlc3MgdGhpczwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWlrZSBKb25lcw0KPGJyPg0K
PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTA6MjIgQU08YnI+DQo8
Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWlj
cm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZn
dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292
ZXJ5IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkFzIHdl4oCZZCBk
aXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZmZWN0aXZlIHNlY3VyaXR5IGRpZmZl
cmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gYmVpbmcgcHVibGlzaGVkIGluIGFu
IGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcw0KIGFuZCBpdCBiZWluZyBwdWJsaXNo
ZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQuJm5ic3A7IOKAnFNlY3VyaXR5IGJ5IG9ic2N1cml0eeKA
nSBhZGRzIG5vIHJlYWwgc2VjdXJpdHkgYXQgYWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAy
MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+IEFudGhvbnkgTmFkYWxpbg0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l
c2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTA6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9u
ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhy
ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+
Jmd0OzsgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29t
Ij5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9
Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+IFRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0
byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBkaXNjb3ZlcnkNCiBmdW5jdGlvbmFsaXR5
IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhhdCBtYXkgYmUg
d2lkZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVkIGZvciBPQXV0
aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2NvdmVyeSBmb3Ig
ZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdA0KIGJlIGluIGFuIE9BdXRoIHN0YW5kYXJk
IHNpbmNlIGl04oCZcyByZWFsbHkgbm90IGRlYWx0IHdpdGguIE5vdyB0aGF0IGFsbCB0aGlzIGlu
Zm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpdCBtYWtlcyBwb2tpbmcgYXJvdW5kIHRoZSBlbmRwb2lu
dCBtb3JlIGZvY3VzZWQgZm9yIHBlb3BsZSB0aGF0IHdhbnQgdG8gZGlzcnVwdCB5b3VyIGVuZHBv
aW50cywgdGhhdCBpcyByZWFsbHkgbm90IGFkZHJlc3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lk
ZXJhdGlvbnMNCiBzZWN0aW9uIGF0IGFsbCA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFs8
YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+
U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTTxicj4NCjxiPlRv
OjwvYj4gUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs7IE5hdCBTYWtpbXVyYSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZn
dDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h
dXRoQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+
b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH
XSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDIwNjAiPlRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0
aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBk
ZXBsb3llZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMwMDIwNjAiPk5vbmUgb2YgTmF0IG9yIEpvaG4gb3IgSSBhcmUgc3VnZ2VzdGlu
ZyB0aGF0IGFkZGl0aW9uYWwgcmVsYXRlZCBmdW5jdGlvbmFsaXR5IHdvbuKAmXQgYmUgY3JlYXRl
ZC4mbmJzcDsgSeKAmW0gc3VyZSBpdCB3aWxsIGJlLiZuYnNwOyBTb21lIGFwcGxpY2F0aW9ucyB3
aWxsIHVzZSBXZWJGaW5nZXINCiB0byBsb2NhdGUgdGhlIGRpc2NvdmVyeSBtZXRhZGF0YS4mbmJz
cDsgU29tZSB3aWxsIHBvc3NpYmx5IHVzZSBsaW5rIGhlYWRlcnMuJm5ic3A7IFNvbWUgd2lsbCBw
b3NzaWJseSB1c2UgYXBwbGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24gdmFsdWVzLiZuYnNw
OyBJ4oCZbSBzdXJlIHRoZXJl4oCZcyBvdGhlciB0aGluZ3MgSSBoYXZlbuKAmXQgZXZlbiB0aG91
Z2h0IGFib3V0LiZuYnNwOyBBbGwgb2YgdGhlc2UgZGVwZW5kIHVwb24gaGF2aW5nIGEgZGlzY292
ZXJ5IG1ldGFkYXRhIGRvY3VtZW50DQogZm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0
IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5
IG1ldGFkYXRhIHZhbHVlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPlNvIGJ5IGFsbCBtZWFucywgdGhlIHdvcmtpbmcg
Z3JvdXAgc2hvdWxkIGNvbnRpbnVlIGRpc2N1c3NpbmcgaW52ZW50aW5nIHBvc3NpYmxlIG5ldyBy
ZWxhdGVkIG1lY2hhbmlzbXMgdGhhdCBtYWtlIHNlbnNlIGluIHNvbWUgY29udGV4dHMuJm5ic3A7
IEF0IHRoZSBzYW1lIHRpbWUsDQogd2UgY2FuIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBhbHJl
YWR5IHdpZGVseSBkZXBsb3llZCBjb3JlIGZ1bmN0aW9uYWxpdHkgdGhhdCBhbGwgb2YgdGhlc2Ug
bWVjaGFuaXNtcyB3aWxsIG5lZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwg
SHVudCAoSURNKTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2
IDg6MzkgQU08YnI+DQo8Yj5Ubzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5D
Yzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn
PC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5v
cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAg
RGlzY292ZXJ5IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgYW0gc3VnZ2VzdGluZyB0aGF0IHBhcnQgb2YgdGhlIGRpc2NvdmVy
eSBzb2x1dGlvbiBoYXMgdG8gYmUgdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoYXQgcmVzb3VyY2Ug
ZW5kcG9pbnQgaXQgd2FudHMgdGhlIG9hdXRoIGNvbmZpZ3VyYXRpb24gZGF0YSBmb3IuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp
ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGlmIDxhIGhy
ZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHAlM2ElMmYlMmZyZXMuZXhhbXBsZS5ldmlsLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2NmNmEzMmE3NzBkNmM0ZjBhYWFkNzA4ZDMzZDQzN2NmOSU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9UGMlMmI3aWxuRFln
ZmpZb1RzUVdvWm5wb2JHJTJiVkpwNVd1OWNHcEZVZ3ozUzAlM2QiPg0KcmVzLmV4YW1wbGUuZXZp
bC5jb208L2E+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50IGZvciA8YSBocmVmPSJo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNh
JTJmJTJmYXMuZXhhbXBsZS5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv
ZnQuY29tJTdjZjZhMzJhNzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0
MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTYlMmJxeGglMmY3VkNaa3N3WGhKTXY2
ciUyYjE4ZFRSYmcySXMxMldCJTJmZFptM2NKNCUzZCI+DQphcy5leGFtcGxlLmNvbTwvYT4gdGhl
IGF1dGh6IGRpc2NvdmVyeSBzaG91bGQgZmFpbCBpbiBzb21lIHdheSAoZWcgcmV0dXJuIG5vdGhp
bmcpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu
YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGVyZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8gZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3Zlcnku
IE9yIGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlzY292ZXJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h
dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgb2YgT0F1dGgncyBzdHJlbmd0aCdzIGFu
ZCB3ZWFrbmVzc2VzIGlzIHRoYXQgdGhlIHRhcmdldCBvZiBhdXRob3JpemF0aW9uICh0aGUgcmVz
b3VyY2UpIGlzIG5ldmVyIHNwZWNpZmllZC4gSXQgaXMgb2Z0ZW4gYm91bmQgdXAgaW4gdGhlIGNs
aWVudCByZWdpc3RyYXRpb24gYW5kIGFuIG9mdGVuIGltcGxpZWQgMToxIHJlbGF0aW9uc2hpcCBi
ZXR3ZWVuIHJlc291cmNlIGFuZCBhcy4gR2l2ZW4gdGhhdCBpbg0KIGRpc2NvdmVyeSBwaGFzZSBy
ZWdpc3RyYXRpb24gaGFzIG5vdCB5ZXQgb2NjdXJyZWQgaXQgc2VlbXMgaW1wb3J0YW50IHRoYXQg
dGhlIGNsaWVudCBrbm93IGl0IGhhcyBhIHZhbGlkIGNvbWJpbmF0aW9uIG9mIGVuZHBvaW50cyBl
dGMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h
dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo
aXMgaXMgd2h5IEkgd2FzIGRpc2FwcG9pbnRlZCBhYm91dCB3Z2xjIG9uIGRpc2NvdmVyeS4gV2Ug
aGFkIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGdyb3VwIGFkb3B0aW9uIGJ1dCB3ZSBoYXZlbid0IHJl
YWxseSBkZWZpbmVkIHRoZSBmdWxsIHJlcXVpcmVtZW50cyBJTU8uJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWls
U2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gb24gdmFjYXRpb24gb3IgSSB3
b3VsZCBwdXQgc29tZSB0aG91Z2h0IGludG8gc29tZSBkcmFmdCBjaGFuZ2VzIG9yIGEgbmV3IGRy
YWZ0LiBJIGFwb2xvZ2l6ZSBJIGNhbid0IGRvIGl0IG5vdy4mbmJzcDs8YnI+DQo8YnI+DQpQaGls
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEZlYiAyNCwgMjAxNiwgYXQgMDg6MTIs
IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+c2Fr
aW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBQaGlsLCZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlvdSBzdWdnZXN0aW5n
IHRoYXQgdGhlIEFTIG1ldGFkYXRhIHNob3VsZCBpbmNsdWRlIHRoZSBSUyBVUklzPyBDdXJyZW50
bHksIGl0IGRvZXMgbm90LCBidXQgaXQgY2FuIGJlIGRvbmUsIEkgZ3Vlc3MuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3YXkg
b2F1dGgtbWV0YSB3b3JrcyBpcyB0aGF0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIFJTIHRlbGxzIHRoZSBjbGllbnQgd2hlcmUg
dGhlIEFTIGlzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Mi4gQVMgdGVsbHMgdGhlIGNsaWVudCB3aGljaCBSUyBlbmRwb2ludHMgdGhl
IHRva2VuIGNhbiBiZSB1c2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGlmIHRoZXJlIGlzIGEgYmFkIEFTIHdpdGggYSB2
YWxpZCBjZXJ0cyB0aGF0IHByb3hpZXMgdG8gdGhlIGdvb2QgUlMsIHRoZSBjbGllbnQgd2lsbCBu
b3Qgc2VuZCB0aGUgdG9rZW4gdGhlcmUgYXMgdGhlIGF1dGh6IHNlcnZlciB3aWxsIHNheSB0aGF0
IGlzIG5vdCB0aGUgcGxhY2UgdGhlIGNsaWVudCBtYXkgd2FudCB0byBzZW5kIHRoZSB0b2tlbiB0
by4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQpOYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5bm0
PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7mnIg8L3NwYW4+MjQ8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpTaW1TdW4iPuawtDwvc3Bhbj4pIDIzOjU5IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0
LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5v
dCBzdXJlIHRoYXQgaGF2aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGVsbCB0aGUgY2xpZW50IHdo
ZXJlIGl0cyBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBzZWN1cmUgYnkgaXRzZWxmLiBUaGUgcmVs
YXRpb25zaGlwIGJldHdlZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGFuZCB0aGUgUmVzb3Vy
Y2Ugc2VydmVyIG5lZWQgdG8gYmUgYm91bmQgdG9nZXRoZXIgaW4gb25lIG9mIHRoZSBkaXNjb3Zl
cnkNCiBlbmRwb2ludHMgKHRoZSByZXNvdXJjZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlz
Y292ZXJ5KS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JZiBhIGNsaWVudCBkaXNjb3ZlcnMgYSBmYWtlIHJlc291cmNlIHNlcnZlciB0aGF0IGlz
IHByb3h5aW5nIGZvciBhIHJlYWwgcmVzb3VyY2Ugc2VydmVyIHRoZSBjdXJyZW50IGRpc2NvdmVy
eSBzcGVjIHdpbGwgbm90IGxlYWQgdGhlIGNsaWVudCB0byB1bmRlcnN0YW5kIGl0IGhhcyB0aGUg
d3JvbmcgcmVzb3VyY2Ugc2VydmVyLiBSYXRoZXIgdGhlIGZha2UgcmVzb3VyY2Ugc2VydmljZSB3
aWxsIGp1c3QgaGF2ZQ0KIGEgZmFrZSBkaXNjb3Zlcnkgc2VydmljZS4gVGhlIGhhY2tlciBjYW4g
bm93IGludGVyY2VwdCByZXNvdXJjZSBwYXlsb2FkIGFzIHdlbGwgYXMgdG9rZW5zIGJlY2F1c2Ug
dGhleSB3ZXJlIGFibGUgdG8gY29udmluY2UgdGhlIGNsaWVudCB0byB1c2UgdGhlIGxlZ2l0IGF1
dGhvcml6YXRpb24gc2VydmljZSBidXQgdXNlIHRoZSB0b2tlbiBhZ2FpbnN0IHRoZSBoYWNrZXJz
IHByb3h5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGUgT0F1dGggRGlzY292ZXJ5IHNlcnZpY2UgbmVlZHMgdG8gY29uZmlybSB0byB0aGUg
Y2xpZW50IHRoYXQgdGhlIHNlcnZlciBpcyBhYmxlIHRvIGlzc3VlIHRva2VucyBmb3IgYSBzdGF0
ZWQgcmVzb3VyY2UgZW5kcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbm90IG9ubHkgd29ya3MgaW4gbm9ybWFsIE9BdXRoIGJ1
dCBzaG91bGQgYWRkIHNlY3VyaXR5IGV2ZW4gdG8gVU1BIHNpdHVhdGlvbnMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGls
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPkBpbmRlcGVuZGVudGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVm
PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
JTNhJTJmJTJmd3d3LmluZGVwZW5kZW50aWQuY29tJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFk
JTQwbWljcm9zb2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJm
OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1NSldwRkIxMnZUTEI0
ZWNLeVl3bFpMblJKSW5hTkV3MU13bHZ0VTI2QlBBJTNkIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lmlu
ZGVwZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js
YW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
RmViIDI0LCAyMDE2LCBhdCAzOjU0IEFNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0
bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208
L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkhpIFRob21hcywmbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+aW5saW5lOiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuaciDwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPig8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNYWxn
dW4gR290aGljJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuaciDwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4pDQogMTg6NDQgVGhvbWFzIEJyb3llciAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnQuYnJveWVyQGdt
YWlsLmNvbTwvYT4mZ3Q7Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q291bGRuJ3QgdGhlIGRv
Y3VtZW50IG9ubHkgZGVzY3JpYmUgdGhlIG1ldGFkYXRhPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5JIHF1aXRlIGxpa2UgdGhlIGlkZWEgb2YmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRh
IGlmIHlvdSByZWFsbHkgd2FudCB0byBkbyBkaXNjb3ZlcnksIGFuZCBsZWF2ZSBpdCBvcGVuIHRv
IGltcGxlbWVudGVycyAvIHRvIG90aGVyIHNwZWNzIHRvIGRlZmluZSBhIC53ZWxsLWtub3duIFVS
TCBmb3INCiAmcXVvdDthdXRvLWNvbmZpZ3VyYXRpb24mcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+VGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0
aGVyIGJlIHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzJm5ic3A7ZHJhZnQtc2Fr
aW11cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMgZm9yIG90
aGVyIG1ldGFkYXRhIHNwZWNzDQogKGxpa2UgT3BlbklEIENvbm5lY3QpLiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldp
dGgmbmJzcDtkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJ3MgJnF1b3Q7ZHVyaSZxdW90OyBhbmQg
dGhlICZxdW90O3Njb3BlJnF1b3Q7IGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGljYXRlIHJlc3Bv
bnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9jZWVkJm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPll1cC4gVGhhdCdz
IG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWwsIGlzIGl0IG5vdD8gJm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+SW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRo
b3JpemF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2Us
IHlvdSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPlNvLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBiZSBhYmxlIHRv
IHRlbGwgZWl0aGVyIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogZW5kcG9pbnQuIEluIHNvbWUg
dHJ1c3RlZCBlbnZpcm9ubWVudCwgdGhlIHJlc291cmNlIG1heSBhcyB3ZWxsIHJldHVybiB0aGUg
bG9jYXRpb24gb2YgdGhlDQogYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhl
c2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1
cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlv
biBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBw
b2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+KHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3
aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91
Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBw
YXJhbWV0ZXIgc3VjaA0KIHRoYXQgYW4gUlMgY291bGQgcmV0dXJuIHNldmVyYWwgV1dXLUF1dGhl
bnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRzIG93biAmcXVvdDtzY29wZSZxdW90OyBhbmQg
JnF1b3Q7ZHVyaSZxdW90OyB2YWx1ZT8pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPlllYWgsIEkgZ3Vlc3MgaXQgaXMgYW4gZWRnZSBjYXNlLiBJIHdvdWxkIHJh
dGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2ZXJzIHRvIGRldmVsb3AgYSB0cnVzdCBm
cmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdyZWUgb24gYSBzaW5nbGUgc2V0IG9mIGNv
bW1vbiBzY29wZQ0KIHBhcmFtZXRlciB2YWx1ZXMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hlZXJz
LCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPk5hdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y
aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
T24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMTA6NTkgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVk
dTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgbmV3bHktdHJpbW1lZCBPQXV0
aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBhbmQgbW92aW5nIGluIHRoZSByaWdodCBk
aXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxsIGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMg
b2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9uZQ0KIGlzc3VlIGluIHBhcnRpY3VsYXIg
c3RpbGwgcmVhbGx5IGJvdGhlcnMgbWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29wZW5p
ZC1jb25maWd1cmF0aW9u4oCdIGluIHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBhbiBP
QXV0aCBkaXNjb3ZlcnkgZG9jdW1lbnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhlcmUg
aXMgYWJzb2x1dGVseSBubyBjb21wZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0aGUg
T0lEQyBkaXNjb3ZlcnkNCiBtZWNoYW5pc20uPGJyPg0KPGJyPg0KSSBwcm9wb3NlIHRoYXQgd2Ug
dXNlIOKAnC8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAnSBhcyB0aGUg
ZGVmYXVsdCBkaXNjb3ZlcnkgbG9jYXRpb24sIGFuZCBzdGF0ZSB0aGF0IHRoZSBkb2N1bWVudCBN
QVkgYWxzbyBiZSByZWFjaGFibGUgZnJvbSDigJwvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3Vy
YXRpb27igJ0gaWYgdGhlIHNlcnZlciBhbHNvIHByb3ZpZGVzIE9wZW5JRCBDb25uZWN0IG9uIHRo
ZSBzYW1lIGRvbWFpbi4gT3RoZXINCiBhcHBsaWNhdGlvbnMgU0hPVUxEIHVzZSB0aGUgc2FtZSBw
YXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5kcG9pbnRzIGFuZCBmdW5jdGlvbnMg
aW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292ZXJ5IGRvY3VtZW50Ljxicj4NCjxi
cj4NCiZuYnNwO+KAlCBKdXN0aW48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm
b2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJh
NzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBw
WlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm
b2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZjZhMzJh
NzcwZDZjNGYwYWFhZDcwOGQzM2Q0MzdjZjklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmYW1wO3NkYXRhPWdvMUZoTCUyYkRhNnlCU0ttY3Mzd3FsNzFCc2tZN043RUp4NDBw
WlBKeHRsNCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxt
YW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9z
b2Z0LmNvbSU3Y2Y2YTMyYTc3MGQ2YzRmMGFhYWQ3MDhkMzNkNDM3Y2Y5JTdjNzJmOTg4YmY4NmYx
NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1nbzFGaEwlMmJEYTZ5QlNLbWNzM3dx
bDcxQnNrWTdON0VKeDQwcFpQSnh0bDQlM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BY2PR03MB442847F4E292B4AA0498F52F5A60BY2PR03MB442namprd_--


From nobody Wed Feb 24 16:25:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E841AC422 for ; Wed, 24 Feb 2016 16:25:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilNF5dx46IBB for ; Wed, 24 Feb 2016 16:25:37 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934C51AC3B3 for ; Wed, 24 Feb 2016 16:25:37 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1P0PaXq031437 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Feb 2016 00:25:36 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1P0Pa93024155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Feb 2016 00:25:36 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u1P0PZpH009958; Thu, 25 Feb 2016 00:25:35 GMT
Received: from [25.173.73.160] (/24.114.27.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Feb 2016 16:25:35 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-71568E68-4A41-46A3-B7BE-0C2F14F425DF
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Wed, 24 Feb 2016 16:25:26 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References:           <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com> 
To: Mike Jones 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 00:25:43 -0000

--Apple-Mail-71568E68-4A41-46A3-B7BE-0C2F14F425DF
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

And so does oracle and so does google. Each different.=20

So how can an app dictate it then unless we all go to a common architecture?=


Phil

> On Feb 24, 2016, at 16:04, Mike Jones  wrote:=

>=20
> Azure defines ways for resource servers to be registered for use with a cl=
ient and for clients to dynamically request an access token for use at a par=
ticular resource server.  You can call that custom architecture if you want.=
  It=E2=80=99s well-defined but it=E2=80=99s not currently in the standards r=
ealm.  I know that Google has syntax for doing the same, as I=E2=80=99m sure=
 do a lot of other cloud OAuth deployments, such as Oracle=E2=80=99s.  For w=
hat it=E2=80=99s worth, the working group talked about possibly producing a s=
tandard version of syntax for making these kinds of requests during our disc=
ussions in Prague (during the Token Exchange discussion) but nobody has run w=
ith this yet.
> =20
> In this sense, yes, Azure is an application of the kind we=E2=80=99re talk=
ing about.  Azure already does define specific new OAuth 2.0 discovery metad=
ata values that are used in production.  A registry just doesn=E2=80=99t yet=
 exist in which it can register those that are of general applicability.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Take a look at the assumptions you are making.=20
> =20
> You seem to be assuming application software dictates oauth infrastructure=
 architecture by suggesting that apps register in iana. =20
> =20
> Would ms azure allow custom arch?
>=20
> Phil
>=20
> On Feb 24, 2016, at 15:28, Mike Jones  wrote:=

>=20
> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be discovered=
.
> =20
> I agree that for some OAuth profiles, one or more resource servers will ha=
ve to be discovered starting from the authorization server.  Working group m=
embers have also described wanting to discover authorization servers startin=
g from resource servers.  There isn=E2=80=99t a standard practice for any of=
 this, which is why it=E2=80=99s intentionally left out of the current speci=
fication.
> =20
> Once the IANA OAuth Discovery Metadata Registry has been established, whic=
h will happen after the current specification has been approved, it will be e=
asy for subsequent specifications to document existing practice for differen=
t OAuth profiles and register discovery metadata values supporting them.  So=
me of those values will likely define ways to discover resource servers, whe=
n applicable.
> =20
> But first, we need to finish the existing spec, so that the registry enabl=
ing these extensions gets established in the first place.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Yup. And because there many relations the client mist be able to discover i=
t. The client does not know if the res server is legit.=20
> =20
> The userinfo is always fix and so u dont need discovery.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 14:05, Mike Jones  wrote:=

>=20
> In OpenID Connect, there=E2=80=99s a resource server called the UserInfo E=
ndpoint that returns claims about the authenticated user as a JSON data stru=
cture.  Its location is published in OpenID Connect discovery metadata as th=
e =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is defined at ht=
tp://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
> =20
> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth disco=
very spec since in OAuth, there are lots of possible relationships between a=
uthorization servers and resource servers and they needn=E2=80=99t be one-to=
-one, as is being actively discussed by the working group.  For instance, se=
e George Fletcher=E2=80=99s recent contribution.
> =20
> Thanks for the good discussion, Phil.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Where is the profile endpoint (oidc's resource server) published? (For the=
 non OIDC people on the list).=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:=

>=20
> To the extent that generic OAuth 2.0 needs to publish some of the same inf=
ormation as OpenID Connect =E2=80=93 which is built on generic OAuth 2.0 =E2=
=80=93 it makes sense to publish that information using exactly the same syn=
tax, since that syntax is already in widespread use.  That what this draft a=
ccomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response val=
ues like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize",
>    "token_endpoint": "https://server.example.com/token",
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", "priva=
te_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register",
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": "http://server.example.com/service_documentati=
on.html",
> =20
> Is there a reason that you would like the syntax for any of these or the o=
ther generally applicable OAuth 2.0 metadata values to be different?  I don=E2=
=80=99t see any good reason for unnecessary differences to be introduced.
> =20
>                                                                 -- Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) that i=
s deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be appropriate f=
or oidc but it is not ready for generic oauth. There is no generic oauth exp=
erience at this time.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
>=20
> Sure there is, it is as you have now made it far easier and the security c=
onsiderations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective security=
 difference between discovery information being published in an ad-hoc fashi=
on on developer pages and it being published in a standard format.  =E2=80=9C=
Security by obscurity=E2=80=9D adds no real security at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> > The point of the WGLC is to finish standardizing the core discovery func=
tionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for OAuth. Th=
ere are some authentication mechanism discovery for endpoint that really sho=
uld not be in an OAuth standard since it=E2=80=99s really not dealt with. No=
w that all this information is available it makes poking around the endpoint=
 more focused for people that want to disrupt your endpoints, that is really=
 not addressed in the security considerations  section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery functi=
onality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related functional=
ity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applicatio=
ns will use WebFinger to locate the discovery metadata.  Some will possibly u=
se link headers.  Some will possibly use application-specific .well-known va=
lues.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even t=
hought about.  All of these depend upon having a discovery metadata document=
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.
> =20
> So by all means, the working group should continue discussing inventing po=
ssible new related mechanisms that make sense in some contexts.  At the same=
 time, we can finish standardizing the already widely deployed core function=
ality that all of these mechanisms will need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the client i=
ndicating what resource endpoint it wants the oauth configuration data for.=20=

> =20
> So if res.example.evil.com is not a valid resource endpoint for as.example=
.com the authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change the o=
rder of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of authorizati=
on (the resource) is never specified. It is often bound up in the client reg=
istration and an often implied 1:1 relationship between resource and as. Giv=
en that in discovery phase registration has not yet occurred it seems import=
ant that the client know it has a valid combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a starting p=
oint for group adoption but we haven't really defined the full requirements I=
MO.=20
> =20
> I am on vacation or I would put some thought into some draft changes or a n=
ew draft. I apologize I can't do it now.=20
>=20
> Phil
>=20
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>=20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? Curren=
tly, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good RS, t=
he client will not send the token there as the authz server will say that is=
 not the place the client may want to send the token to.=20
>=20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client where=
 its authorization server is secure by itself. The relationship between the A=
uthorization Server and the Resource server need to be bound together in one=
 of the discovery endpoints (the resource and/or the oauth service discovery=
).
> =20
> If a client discovers a fake resource server that is proxying for a real r=
esource server the current discovery spec will not lead the client to unders=
tand it has the wrong resource server. Rather the fake resource service will=
 just have a fake discovery service. The hacker can now intercept resource p=
ayload as well as tokens because they were able to convince the client to us=
e the legit authorization service but use the token against the hackers prox=
y.
> =20
> The OAuth Discovery service needs to confirm to the client that the server=
 is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to UMA si=
tuations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> =20
> =20
> =20
>=20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
> =20
>=20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to d=
o discovery, and leave it open to implementers / to other specs to define a .=
well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, r=
eturned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for o=
ther metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-A=
uthenticate response header, you have everything you need to proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually tig=
htly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of the a=
uthz endpoint. In some trusted environment, the resource may as well return t=
he location of the authz server configuration data. In these cases, you do n=
ot have to decide on what .well-known uri as you say. This frees up develope=
rs from configuration file location collisions etc. We should strive not to p=
ollute the uri space as much as possible.=20
> =20
> (well, except if there are several ASs each with different scopes; sounds l=
ike an edge-case to me though; maybe RFC6750 should instead be updated with s=
uch a parameter such that an RS could return several WWW-Authenticate: Beare=
r, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these authz s=
ervers to develop a trust framework under which they can agree on a single s=
et of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
>=20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the ri=
ght direction. It does, however, still have too many vestiges of its OpenID C=
onnect origins. One issue in particular still really bothers me: the use of =E2=
=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery portion. I=
s this an OAuth discovery document, or an OpenID Connect one? There is absol=
utely no compelling reason to tie the URL to the OIDC discovery mechanism.
>=20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other applications SH=
OULD use the same parameter names to describe OAuth endpoints and functions i=
nside their service-specific discovery document.
>=20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-71568E68-4A41-46A3-B7BE-0C2F14F425DF
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


And so does oracle and so does google.=
 Each different. 

So how can an app dictate it then unless we all go t=
o a common architecture?

Phil

On Feb 24, 2016, at 16:04=
, Mike Jones <Michael.Jone=
s@microsoft.com> wrote:











Azure defines ways for reso=
urce servers to be registered for use with a client and for clients to dynam=
ically request an access token for use at a particular
 resource server.  You can call that custom architecture if you want.&n=
bsp; It=E2=80=99s well-defined but it=E2=80=99s not currently in the standar=
ds realm.  I know that Google has syntax for doing the same, as I=E2=80=
=99m sure do a lot of other cloud OAuth deployments, such as Oracle=E2=80=99=
s. 
 For what it=E2=80=99s worth, the working group talked about possibly produc=
ing a standard version of syntax for making these kinds of requests during o=
ur discussions in Prague (during the Token Exchange discussion) but nobody h=
as run with this yet.


 

In this sense, yes, Azure i=
s an application of the kind we=E2=80=99re talking about.  Azure alread=
y does define specific new OAuth 2.0 discovery metadata values that
 are used in production.  A registry just doesn=E2=80=99t yet exist in w=
hich it can register those that are of general applicability.


 

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

 





From: Phil Hunt (=
IDM) [mailto:phil.hunt@oracle.com]


Sent: Wednesday, February 24, 2016 3:52 PM

To: Mike Jones

Cc: <oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




Mike






 






Take a look at the assumptions you are making. <=
o:p>






 






You seem to be assuming application software dictates=
 oauth infrastructure architecture by suggesting that apps register in iana.=
  






 






Would ms azure allow custom arch?



Phil








On Feb 24, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> wrote:








The UserInfo Endpoint path i=
sn=E2=80=99t fixed and so has to be discovered.


 

I agree that for some OAuth=
 profiles, one or more resource servers will have to be discovered starting f=
rom the authorization server.  Working group members
 have also described wanting to discover authorization servers starting from=
 resource servers.  There isn=E2=80=99t a standard practice for any of t=
his, which is why it=E2=80=99s intentionally left out of the current specifi=
cation.


 

Once the IANA OAuth Discove=
ry Metadata Registry has been established, which will happen after the curre=
nt specification has been approved, it will be easy for
 subsequent specifications to document existing practice for different OAuth=
 profiles and register discovery metadata values supporting them.  Some=
 of those values will likely define ways to discover resource servers, when a=
pplicable.


 

But first, we need to finis=
h the existing spec, so that the registry enabling these extensions gets est=
ablished in the first place.


 

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

 



 




Yup. And because there many relations the client mist=
 be able to discover it. The client does not know if the res server is legit=
. 






 






The userinfo is always fix and so u dont need discove=
ry. 



Phil








On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> wrote:








In OpenID Connect, there=E2=
=80=99s a resource server called the UserInfo Endpoint that returns claims a=
bout the authenticated user as a JSON data structure.  Its location
 is published in OpenID Connect discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D m=
etadata
 value, which is defined at 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.


 

We didn=E2=80=99t include t=
he UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, the=
re are lots of possible relationships between authorization servers
 and resource servers and they needn=E2=80=99t be one-to-one, as is being ac=
tively discussed by the working group.  For instance, see George Fletch=
er=E2=80=99s recent contribution.


 

Thanks for the good discuss=
ion, Phil.


 

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


 



 




Where is the profile endpoint (oidc's resource server=
) published? (For the non OIDC people on the list). 



Phil








On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:








To the extent that generic O=
Auth 2.0 needs to publish some of the same information as OpenID Connect =E2=
=80=93 which is built on generic OAuth 2.0 =E2=80=93 it makes sense
 to publish that information using exactly the same syntax, since that synta=
x is already in widespread use.  That what this draft accomplishes.


 

There=E2=80=99s nothing Con=
nect-specific about using metadata response values like:

 

   "authorization=
_endpoint": "https://server=
.example.com/authorize",


   "token_endpoin=
t": "https://server.example.com=
/token",


   "token_endpoin=
t_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],


   "registration_=
endpoint": "https://server.e=
xample.com/register",


   "response_type=
s_supported":  ["code", "token"],


   "service_docum=
entation": "http://server.example.com/service_documentation.html",


 

Is there a reason that you w=
ould like the syntax for any of these or the other generally applicable OAut=
h 2.0 metadata values to be different?  I don=E2=80=99t see
 any good reason for unnecessary differences to be introduced.


 

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

 



 




Mike






 






Publishing on dev pages does not work for software (e=
sp open source) that is deployed both in enterprises and on PaaS cloud provi=
ders. 






 






The current draft is may codify current OIDC practice=
 and be appropriate for oidc but it is not ready for generic oauth. There is=
 no generic oauth experience at this time. 








Phil








On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> wrote:








Sure there is, it is as you=
 have now made it far easier and the security considerations does not even a=
ddress this


 






From: Mike Jone=
s


Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <tony=
nad@microsoft.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


As we=E2=80=99d discussed i=
n person, there=E2=80=99s no effective security difference between discovery=
 information being published in an ad-hoc fashion on developer pages
 and it being published in a standard format.  =E2=80=9CSecurity by obs=
curity=E2=80=9D adds no real security at all.


 

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


 





From: Anthony N=
adalin


Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <Mic=
hael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location






 


> The point of the WGLC is to finish standardizing the core discove=
ry
 functionality that=E2=80=99s already widely deployed.
=


 

That may be widely deployed=
 for OIDC but not widely deployed for OAuth. There are some authentication m=
echanism discovery for endpoint that really should not
 be in an OAuth standard since it=E2=80=99s really not dealt with. Now that a=
ll this information is available it makes poking around the endpoint more fo=
cused for people that want to disrupt your endpoints, that is really not add=
ressed in the security considerations
 section at all 


 





From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <phil.=
hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 


The point of the WGLC is to=
 finish standardizing the core discovery functionality that=E2=80=99s alread=
y widely deployed.


 

None of Nat or John or I ar=
e suggesting that additional related functionality won=E2=80=99t be created.=
  I=E2=80=99m sure it will be.  Some applications will use WebFing=
er
 to locate the discovery metadata.  Some will possibly use link headers=
.  Some will possibly use application-specific .well-known values. =
; I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even thoug=
ht about.  All of these depend upon having a discovery metadata documen=
t
 format and none of them change it =E2=80=93 other than possibly to register=
 additional discovery metadata values.


 

So by all means, the workin=
g group should continue discussing inventing possible new related mechanisms=
 that make sense in some contexts.  At the same time,
 we can finish standardizing the already widely deployed core functionality t=
hat all of these mechanisms will need.


 

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


 





From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <sakimura@g=
mail.com>

Cc: <oauth@ietf.org> <=
oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location






 




I am suggesting that part of the discovery solution h=
as to be the client indicating what resource endpoint it wants the oauth con=
figuration data for. 






 






So if 
res.example.evil.com is not a valid resource endpoint for 
as.example.com the authz discovery should fail in some way (eg return no=
thing). 






 






There may be better ways to do this. Eg combine disco=
very. Or change the order of discovery. 






 






One of OAuth's strength's and weaknesses is that the t=
arget of authorization (the resource) is never specified. It is often bound u=
p in the client registration and an often implied 1:1 relationship between r=
esource and as. Given that in
 discovery phase registration has not yet occurred it seems important that t=
he client know it has a valid combination of endpoints etc. =







 






This is why I was disappointed about wglc on discover=
y. We had a starting point for group adoption but we haven't really defined t=
he full requirements IMO. 






 






I am on vacation or I would put some thought into som=
e draft changes or a new draft. I apologize I can't do it now. 



Phil








On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:










Hi Phil, 




 






Are you suggesting that the AS metadata should includ=
e the RS URIs? Currently, it does not, but it can be done, I guess. 






 






The way oauth-meta works is that 
=






 






1. RS tells the client where the AS is. 






2. AS tells the client which RS endpoints the token c=
an be used. 






 






Even if there is a bad AS with a valid certs that pro=
xies to the good RS, the client will not send the token there as the authz s=
erver will say that is not the place the client may want to send the token t=
o. 










Nat






 






2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4=
) 23:59 Phil Hunt <phil.hu=
nt@oracle.com>:










Nat,






 




I=E2=80=99m not sure that having the resource server t=
ell the client where its authorization server is secure by itself. The relat=
ionship between the Authorization Server and the Resource server need to be b=
ound together in one of the discovery
 endpoints (the resource and/or the oauth service discovery).
=




 








If a client discovers a fake resource server that is p=
roxying for a real resource server the current discovery spec will not lead t=
he client to understand it has the wrong resource server. Rather the fake re=
source service will just have
 a fake discovery service. The hacker can now intercept resource payload as w=
ell as tokens because they were able to convince the client to use the legit=
 authorization service but use the token against the hackers proxy.






 






The OAuth Discovery service needs to confirm to the c=
lient that the server is able to issue tokens for a stated resource endpoint=
.






 






This not only works in normal OAuth but should add se=
curity even to UMA situations.






 


















Phil





 <=
/p>





@independentid











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





 <=
/p>





 <=
/p>



 
















 








On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> w=
rote:




 








Hi Thomas, 




 






inline: 






 






2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=
=9C=88)
 18:44 Thomas Broyer <t.broyer@gmail.com>:








Couldn't the document only describe the m=
etadata?




I quite like the idea of draft-saki=
mura-oauth-meta if you really want to do discovery, and leave it open to imp=
lementers / to other specs to define a .well-known URL for
 "auto-configuration".






The metadata described here would then e=
ither be used as-is, at any URL, returned as draft-sakimura-oauth-meta m=
etadata at the RS; or as a basis for other metadata specs
 (like OpenID Connect). 
















With draft-sakimura-oauth-meta's "d=
uri" and the "scope" attribute of WWW-Authenticate response header, you have=
 everything you need to proceed 












 






Yup. That's one of the requirements to b=
e RESTful, is it not?  






 






In OAuth's case, the resource and the au=
thorization server are usually tightly coupled. (Otherwise, you need another=
 specs like UMA.) 






So, the resource server should be able t=
o tell either the location of the authz endpoint. In some trusted environmen=
t, the resource may as well return the location of the
 authz server configuration data. In these cases, you do not have to decide o=
n what .well-known uri as you say. This frees up developers from configurati=
on file location collisions etc. We should strive not to pollute the uri spa=
ce as much as possible. 






 












(well, except if there are several ASs e=
ach with different scopes; sounds like an edge-case to me though; maybe RFC6=
750 should instead be updated with such a parameter such
 that an RS could return several WWW-Authenticate: Bearer, each with its own=
 "scope" and "duri" value?)












 






Yeah, I guess it is an edge case. I woul=
d rather like to see these authz servers to develop a trust framework under w=
hich they can agree on a single set of common scope
 parameter values. 






 






Cheers, 






 






Nat






 












 






On Fri, Feb 19, 2016 at 10:59 PM Justin R=
icher <jricher@mit.e=
du> wrote:






The newly-trimmed OAuth Discovery docume=
nt is helpful and moving in the right direction. It does, however, still hav=
e too many vestiges of its OpenID Connect origins. One
 issue in particular still really bothers me: the use of =E2=80=9C/.well-kno=
wn/openid-configuration=E2=80=9D in the discovery portion. Is this an OAuth d=
iscovery document, or an OpenID Connect one? There is absolutely no compelli=
ng reason to tie the URL to the OIDC discovery
 mechanism.



I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=80=
=9D as the default discovery location, and state that the document MAY also b=
e reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the s=
erver also provides OpenID Connect on the same domain. Other
 applications SHOULD use the same parameter names to describe OAuth endpoint=
s and functions inside their service-specific discovery document.



 =E2=80=94 Justin

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












________________________________________=
_______

OAuth mailing list

OAuth@ietf.org

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










________________________________________=
_______

OAuth mailing list

OAut=
h@ietf.org

https://www.ietf.org/mailman/listinfo/oau=
th








 






























_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






















=

--Apple-Mail-71568E68-4A41-46A3-B7BE-0C2F14F425DF--


From nobody Wed Feb 24 21:17:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84551B31F5 for ; Wed, 24 Feb 2016 21:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level: 
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, URI_HEX=1.122] autolearn=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 JBhD1wlFdMiA for ; Wed, 24 Feb 2016 21:17:12 -0800 (PST)
Received: from www.sakimura.org (www.sakimura.org [52.69.28.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079D51B31F1 for ; Wed, 24 Feb 2016 21:17:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) (uid 33) by www.sakimura.org with local; Thu, 25 Feb 2016 05:17:31 +0000 id 0000000000087AD9.0000000056CE8E6B.00005AF4
To: Anthony Nadalin 
X-PHP-Originating-Script: 0:rcmail.php
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 25 Feb 2016 14:17:31 +0900
From: sakimura@gmail.com
In-Reply-To: 
References: <20160212094043.13011.44662.idtracker@ietfa.amsl.com>    
Message-ID: 
X-Sender: sakimura@gmail.com
User-Agent: Roundcube Webmail/0.9.5
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 05:17:13 -0000

The link relations registry is a regular IANA registry, just like OAuth 
parameters registry.
It is also available in XML format but so is the OAuth parameters 
registry, i.e.:

http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml

You do not say that OAuth is XML based because the parameter registry is 
available also in XML, do you?

# OTHT, it would be an interesting idea to suggest to IANA to make
# those registries available in JSON as well.

Nat

2016-02-25 06:06 ã« Anthony Nadalin ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ:
> So as I understand it in the Link Relations repository are XML
> documents that one has to create, are you suggesting as part of this
> effort is to rewrite all that in JSON and make a proposal for that
> also ?
> 
> FROM: Nat Sakimura [mailto:sakimura@gmail.com]
>  SENT: Tuesday, February 16, 2016 4:55 PM
>  TO: Anthony Nadalin ; oauth 
>  SUBJECT: Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-sakimura-oauth-meta-07.txt
> 
> Link relation is not at all XML. It is a step forward to RESTfulness.
> 
> In the older version of the draft, I was using JSONized version of it
> as well, but I splitted it out for the sake of brevity.
> 
> It is all about dynamic metadata about the response.
> 
> Once we do it with RFC5988, we could easily create a parallel to it
> with JSON meta object of your flavour.
> 
> (Currently, JSON schema seems to be in fashion, though I personally
> prefer HAL.)
> 
> Good things about using JSONized version is that it will be usable
> outside the HTTP and the fact that it can be stored in a single JSON
> object together with the data.
> 
> Bad thing about it is that we have to start from the syntax for it,
> which we can avoid by using RFC5988.
> 
> If people want the JSON version of this, I could do it as well.
> 
> However, since we are processing HTTP response headers anyways, there
> is not much compelling reason for that as long as we stick with HTTP.
> 
> That's why I am just sticking with RFC5988.
> 
> Nat.
> 
> 2016年2月17日(水) 8:50 Anthony Nadalin :
> 
>> I really think that this is a step backwards relative to technology
>> and what the developers would accept. The Link Relations takes us
>> back to the XML days, I thought we have all moved on from that and
>> at least trying to move Oauth to JSON. I think if this were adopted
>> we might be splitting the developers into folks that are already
>> going down the current JSON path with Oauth and those that want to
>> go back to XML.
>> 
>> This just seems a very odd draft to adopt this technology.
>> 
>> FROM: OAuth [mailto:oauth-bounces@ietf.org] ON BEHALF OF Nat
>> Sakimura
>> SENT: Monday, February 15, 2016 3:59 PM
>> TO: oauth 
>> SUBJECT: [OAUTH-WG] Fwd: New Version Notification for
>> draft-sakimura-oauth-meta-07.txt
>> 
>> It now shows how to return multiple endpoints in web linking.
>> 
>> Also, added Resource Endpoint response header.
>> 
>> Best,
>> 
>> nat
>> 
>> ---------- Forwarded message ---------
>> From: 
>> Date: 2016年2月12日(金) 18:40
>> Subject: New Version Notification for
>> draft-sakimura-oauth-meta-07.txt
>> To: Nov Matake , Nat Sakimura ,
>> Sascha Preibisch , Sascha Preibisch
>> 
>> 
>> A new version of I-D, draft-sakimura-oauth-meta-07.txt
>> has been successfully submitted by Nat Sakimura and posted to the
>> IETF repository.
>> 
>> Name: draft-sakimura-oauth-meta
>> Revision: 07
>> Title: OAuth Response Metadata
>> Document date: 2016-02-12
>> Group: Individual Submission
>> Pages: 10
>> URL:
>> 
> https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt
>> [1]
>> Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
>> [2]
>> Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
>> [3]
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07 [4]
>> 
>> Abstract:
>> This specification defines an extensible metadata that may be
>> inserted into the OAuth 2.0 responses to assist the clients to
>> process those responses. It is expressed either as a link header,
>> or
>> query parameters. It will allow the client to learn where the
>> members in the response could be used, what is the characteristics
>> of
>> the payload is, how it should be processed, and so on. Since they
>> are just additional response header/query parameters, any client
>> that
>> does not understand this extension should not break and work
>> normally
>> while supporting clients can utilize the metadata to take the
>> advantage of the extension.
>> 
>> 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
>> [5].
>> 
>> The IETF Secretariat
> 
> 
> Links:
> ------
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d
> [2]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKwM%3d
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kh2nH4IyNm3OAA5nkrSFzZN16Xic%2b2EDUOfr%2fG6CjVY%3d
> [4]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ICtk5U1e6kBPFI8ov0n06TAcqDX3HurgFTydXKD73Yo%3d
> [5]
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aijC6rAn01n04mDyB5lpV7tQitxIyf0drdheleR955A%3d


From nobody Wed Feb 24 23:07:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8965E1A8A99 for ; Wed, 24 Feb 2016 23:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=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 9uCIXtb0-Rzd for ; Wed, 24 Feb 2016 23:07:08 -0800 (PST)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4161A8978 for ; Wed, 24 Feb 2016 23:07:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,497,1449493200";  d="scan'208,217";a="150378054"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 25 Feb 2016 18:05:59 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8085"; a="83330451"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcavi.tcif.telstra.com.au with ESMTP; 25 Feb 2016 18:03:14 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3752.srv.dir.telstra.com ([fe80::91f4:aabc:bfb0:95c4%16]) with mapi; Thu, 25 Feb 2016 18:02:36 +1100
From: "Manger, James" 
To: George Fletcher , "" 
Date: Thu, 25 Feb 2016 18:02:35 +1100
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AdFvN/cbviXvE7HsQxyyCWEJ5zKKMAAXzyEw
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
References:     <56CE01B1.7060501@aol.com>
In-Reply-To: <56CE01B1.7060501@aol.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBB0194A6WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 07:07:10 -0000

--_000_255B9BB34FB7D647A506DC292726F6E13BBB0194A6WSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBJJ20gY29uY2VybmVkIHRoYXQgZm9yY2luZyB0aGUgQVMgdG8ga25vdyBhYm91dCBhbGwgUlMn
cyBlbmRwb2ludHMgdGhhdCB3aWxsIGFjY2VwdCBpdCdzIHRva2VucyBjcmVhdGVzIGEgdmVyeSBi
cml0dGxlIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlDQoNClRoZSBBUyBpcyBpc3N1aW5nIHRlbXBv
cmFyeSBjcmVkZW50aWFscyAoYWNjZXNzX3Rva2VucykgdG8gY2xpZW50cyBidXQgZG9lc27igJl0
IGtub3cgd2hlcmUgdGhvc2UgY3JlZGVudGlhbHMgd2lsbCB3b3JrPyBUaGF04oCZcyBicm9rZW4u
DQoNCkFuIEFTIHNob3VsZCBhYnNvbHV0ZWx5IGluZGljYXRlIHdoZXJlIGFuIGFjY2Vzc190b2tl
biBjYW4gYmUgdXNlZC4gZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBzdWdnZXN0cyBpbmRpY2F0
aW5nIHRoaXMgd2l0aCAxIG9yIG1vcmUg4oCccnVyaeKAnSAocmVzb3VyY2UgVVJJKSB2YWx1ZXMg
aW4gYW4gSFRUUCBMaW5rIGhlYWRlci4gQSBiZXR0ZXIgYXBwcm9hY2ggd291bGQgYmUgaW5jbHVk
aW5nIGEgbGlzdCBvZiB3ZWIgb3JpZ2lucyBpbiB0aGUgdG9rZW4gcmVzcG9uc2UgYmVzaWRlIHRo
ZSBhY2Nlc3NfdG9rZW4gZmllbGQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogT0F1dGgg
W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvcmdlIEZsZXRj
aGVyDQpTZW50OiBUaHVyc2RheSwgMjUgRmVicnVhcnkgMjAxNiA2OjE3IEFNDQpUbzogUGhpbCBI
dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwu
Y29tPg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQpJJ20gY29uY2VybmVk
IHRoYXQgZm9yY2luZyB0aGUgQVMgdG8ga25vdyBhYm91dCBhbGwgUlMncyBlbmRwb2ludHMgdGhh
dCB3aWxsIGFjY2VwdCBpdCdzIHRva2VucyBjcmVhdGVzIGEgdmVyeSBicml0dGxlIGRlcGxveW1l
bnQgYXJjaGl0ZWN0dXJlLiBXaGF0IGlmIGEgUlMgbW92ZXMgdG8gYSBuZXcgZW5kcG9pbnQ/IEFs
bCBjbGllbnRzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGdldCBuZXcgdG9rZW5zIChpZiBJIHVuZGVy
c3RhbmQgY29ycmVjdGx5KS4gQW5kIHRoZSBSUyBtb3ZlIHdvdWxkIGhhdmUgdG8gY29vcmRpbmF0
ZSB3aXRoIHRoZSBBUyB0byBtYWtlIHN1cmUgYWxsIHRoZSB0aW1pbmcgaXMgcGVyZmVjdCBpbiB0
aGUgc3dpdGNoIG92ZXIgb2YgZW5kcG9pbnRzLg0KDQpJIHN1c3BlY3QgYSBjb21tb24gZGVwbG95
bWVudCBhcmNoaXRlY3R1cmUgdG9kYXkgaXMgdGhhdCBlYWNoIFJTIHJlcXVpcmVzIG9uZSBvciBt
b3JlIHNjb3BlcyB0byBhY2Nlc3MgaXQncyByZXNvdXJjZXMuIFRoZSBjbGllbnQgdGhlbiBhc2tz
IHRoZSB1c2VyIHRvIGF1dGhvcml6ZSBhIHRva2VuIHdpdGggYSByZXF1ZXN0ZWQgbGlzdCBvZiBz
Y29wZXMuIFRoZSBjbGllbnQgY2FuIHRoZW4gc2VuZCB0aGUgdG9rZW4gdG8gdGhlIGFwcHJvcHJp
YXRlIFJTIGVuZHBvaW50LiBUaGUgUlMgd2lsbCBub3QgYXV0aG9yaXplIGFjY2VzcyB1bmxlc3Mg
dGhlIHRva2VuIGhhcyB0aGUgcmVxdWlyZWQgc2NvcGVzLg0KDQpJZiB0aGUgY29uY2VybiBpcyB0
aGF0IHRoZSBjbGllbnQgbWF5IGFjY2lkZW50YWxseSBzZW5kIHRoZSB0b2tlbiB0byBhICJiYWQi
IFJTIHdoaWNoIHdpbGwgdGhlbiByZXBsYXkgdGhlIHRva2VuLCB0aGVuIEknZCByYXRoZXIgdXNl
IGEgUG9QIG1lY2hhbmlzbSBiZWNhdXNlIHRoZSBwb2ludCBpcyB0aGF0IHlvdSB3YW50IHRvIGVu
c3VyZSB0aGUgY29ycmVjdCBjbGllbnQgaXMgcHJlc2VudGluZyB0aGUgdG9rZW4uIFRyeWluZyB0
byBlbnN1cmUgdGhlIGNsaWVudCBkb2Vzbid0IHNlbmQgdGhlIHRva2VuIHRvIHRoZSB3cm9uZyBl
bmRwb2ludCBzZWVtcyBmcmF1Z2h0IHdpdGggcHJvYmxlbXMuDQoNClRoYW5rcywNCkdlb3JnZQ0K

--_000_255B9BB34FB7D647A506DC292726F6E13BBB0194A6WSMSG3153Vsrv_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K
CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy
IDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp
bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh
cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn
aW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1h
cmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFj
azt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUt
c3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBs
ZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5
bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29u
c29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx
Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBiZ2Nv
bG9yPXdoaXRlIGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv
cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyc+Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5
OiJIZWx2ZXRpY2EiLHNhbnMtc2VyaWYnPkknbSBjb25jZXJuZWQgdGhhdCBmb3JjaW5nIHRoZSBB
UyB0byBrbm93IGFib3V0IGFsbCBSUydzIGVuZHBvaW50cyB0aGF0IHdpbGwgYWNjZXB0IGl0J3Mg
dG9rZW5zIGNyZWF0ZXMgYSB2ZXJ5IGJyaXR0bGUgZGVwbG95bWVudCBhcmNoaXRlY3R1cmU8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZh
bWlseToiSGVsdmV0aWNhIixzYW5zLXNlcmlmJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAnPlRoZSBBUyBpcyBpc3N1aW5n
IHRlbXBvcmFyeSBjcmVkZW50aWFscyAoYWNjZXNzX3Rva2VucykgdG8gY2xpZW50cyBidXQgZG9l
c27igJl0IGtub3cgd2hlcmUgdGhvc2UgY3JlZGVudGlhbHMgd2lsbCB3b3JrPyBUaGF04oCZcyBi
cm9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xv
cjojMDAyMDYwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAnPkFuIEFTIHNob3VsZCBhYnNvbHV0ZWx5IGluZGljYXRlIHdo
ZXJlIGFuIGFjY2Vzc190b2tlbiBjYW4gYmUgdXNlZC4gZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0
YSBzdWdnZXN0cyBpbmRpY2F0aW5nIHRoaXMgd2l0aCAxIG9yIG1vcmUg4oCccnVyaeKAnSAocmVz
b3VyY2UgVVJJKSB2YWx1ZXMgaW4gYW4gSFRUUCBMaW5rIGhlYWRlci4gQSBiZXR0ZXIgYXBwcm9h
Y2ggd291bGQgYmUgaW5jbHVkaW5nIGEgbGlzdCBvZiB3ZWIgb3JpZ2lucyBpbiB0aGUgdG9rZW4g
cmVzcG9uc2UgYmVzaWRlIHRoZSBhY2Nlc3NfdG9rZW4gZmllbGQuPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwO21zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjA7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPi0tPG86
cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5
bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtj
b2xvcjp3aW5kb3d0ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjp3
aW5kb3d0ZXh0Jz4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC
ZWhhbGYgT2YgPC9iPkdlb3JnZSBGbGV0Y2hlcjxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIDI1
IEZlYnJ1YXJ5IDIwMTYgNjoxNyBBTTxicj48Yj5Ubzo8L2I+IFBoaWwgSHVudCAmbHQ7cGhpbC5o
dW50QG9yYWNsZS5jb20mZ3Q7OyBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZn
dDs8YnI+PGI+Q2M6PC9iPiAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7ICZsdDtvYXV0aEBpZXRmLm9y
ZyZndDs8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3Zl
cnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy
Z2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiSGVsdmV0aWNhIixz
YW5zLXNlcmlmJz5JJ20gY29uY2VybmVkIHRoYXQgZm9yY2luZyB0aGUgQVMgdG8ga25vdyBhYm91
dCBhbGwgUlMncyBlbmRwb2ludHMgdGhhdCB3aWxsIGFjY2VwdCBpdCdzIHRva2VucyBjcmVhdGVz
IGEgdmVyeSBicml0dGxlIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlLiBXaGF0IGlmIGEgUlMgbW92
ZXMgdG8gYSBuZXcgZW5kcG9pbnQ/IEFsbCBjbGllbnRzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGdl
dCBuZXcgdG9rZW5zIChpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5KS4gQW5kIHRoZSBSUyBtb3Zl
IHdvdWxkIGhhdmUgdG8gY29vcmRpbmF0ZSB3aXRoIHRoZSBBUyB0byBtYWtlIHN1cmUgYWxsIHRo
ZSB0aW1pbmcgaXMgcGVyZmVjdCBpbiB0aGUgc3dpdGNoIG92ZXIgb2YgZW5kcG9pbnRzLjxicj48
YnI+SSBzdXNwZWN0IGEgY29tbW9uIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlIHRvZGF5IGlzIHRo
YXQgZWFjaCBSUyByZXF1aXJlcyBvbmUgb3IgbW9yZSBzY29wZXMgdG8gYWNjZXNzIGl0J3MgcmVz
b3VyY2VzLiBUaGUgY2xpZW50IHRoZW4gYXNrcyB0aGUgdXNlciB0byBhdXRob3JpemUgYSB0b2tl
biB3aXRoIGEgcmVxdWVzdGVkIGxpc3Qgb2Ygc2NvcGVzLiBUaGUgY2xpZW50IGNhbiB0aGVuIHNl
bmQgdGhlIHRva2VuIHRvIHRoZSBhcHByb3ByaWF0ZSBSUyBlbmRwb2ludC4gVGhlIFJTIHdpbGwg
bm90IGF1dGhvcml6ZSBhY2Nlc3MgdW5sZXNzIHRoZSB0b2tlbiBoYXMgdGhlIHJlcXVpcmVkIHNj
b3Blcy48YnI+PGJyPklmIHRoZSBjb25jZXJuIGlzIHRoYXQgdGhlIGNsaWVudCBtYXkgYWNjaWRl
bnRhbGx5IHNlbmQgdGhlIHRva2VuIHRvIGEgJnF1b3Q7YmFkJnF1b3Q7IFJTIHdoaWNoIHdpbGwg
dGhlbiByZXBsYXkgdGhlIHRva2VuLCB0aGVuIEknZCByYXRoZXIgdXNlIGEgUG9QIG1lY2hhbmlz
bSBiZWNhdXNlIHRoZSBwb2ludCBpcyB0aGF0IHlvdSB3YW50IHRvIGVuc3VyZSB0aGUgY29ycmVj
dCBjbGllbnQgaXMgcHJlc2VudGluZyB0aGUgdG9rZW4uIFRyeWluZyB0byBlbnN1cmUgdGhlIGNs
aWVudCBkb2Vzbid0IHNlbmQgdGhlIHRva2VuIHRvIHRoZSB3cm9uZyBlbmRwb2ludCBzZWVtcyBm
cmF1Z2h0IHdpdGggcHJvYmxlbXMuPGJyPjxicj5UaGFua3MsPGJyPkdlb3JnZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_255B9BB34FB7D647A506DC292726F6E13BBB0194A6WSMSG3153Vsrv_--


From nobody Wed Feb 24 23:22:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748981A01A8 for ; Wed, 24 Feb 2016 23:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH2h8CT08Dl2 for ; Wed, 24 Feb 2016 23:22:40 -0800 (PST)
Received: from p3plsmtpa08-04.prod.phx3.secureserver.net (p3plsmtpa08-04.prod.phx3.secureserver.net [173.201.193.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C611A016A for ; Wed, 24 Feb 2016 23:22:40 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-04.prod.phx3.secureserver.net with  id NXNe1s00715ZTut01XNfWH; Thu, 25 Feb 2016 00:22:40 -0700
To: oauth@ietf.org
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <56CEABBD.1040602@connect2id.com>
Date: Thu, 25 Feb 2016 09:22:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060608020209070702020105"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 07:22:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms060608020209070702020105
Content-Type: multipart/alternative;
 boundary="------------090900090601000706070103"

This is a multi-part message in MIME format.
--------------090900090601000706070103
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 25/02/16 09:02, Manger, James wrote:
>> I'm concerned that forcing the AS to know about all RS's endpoints tha=
t will accept it's tokens creates a very brittle deployment architecture
> The AS is issuing temporary credentials (access_tokens) to clients but =
doesn=92t know where those credentials will work? That=92s broken.
>
> An AS should absolutely indicate where an access_token can be used. dra=
ft-sakimura-oauth-meta suggests indicating this with 1 or more =93ruri=94=
 (resource URI) values in an HTTP Link header. A better approach would be=
 including a list of web origins in the token response beside the access_=
token field.
+1

This will appear more consistent with the current experience, and OAuth
does allow the token response JSON object to be extended with additional
members (as it's done in OpenID Connect already).

Cheers,
Vladimir

> --
> James Manger
>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletche=
r
> Sent: Thursday, 25 February 2016 6:17 AM
> To: Phil Hunt ; Nat Sakimura =

> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints that=
 will accept it's tokens creates a very brittle deployment architecture. =
What if a RS moves to a new endpoint? All clients would be required to ge=
t new tokens (if I understand correctly). And the RS move would have to c=
oordinate with the AS to make sure all the timing is perfect in the switc=
h over of endpoints.
>
> I suspect a common deployment architecture today is that each RS requir=
es one or more scopes to access it's resources. The client then asks the =
user to authorize a token with a requested list of scopes. The client can=
 then send the token to the appropriate RS endpoint. The RS will not auth=
orize access unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a =
"bad" RS which will then replay the token, then I'd rather use a PoP mech=
anism because the point is that you want to ensure the correct client is =
presenting the token. Trying to ensure the client doesn't send the token =
to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------090900090601000706070103
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    

    

    
On 25/02/16 09:02, Manger, James wrote=
:

    

    

      

        
I'm concerned that forcing the AS to know about al=
l RS's endpoints that will accept it's tokens creates a very brittle depl=
oyment architecture


      

      
The AS is issuing temporary credentials (access_tokens) to clients but do=
esn=92t know where those credentials will work? That=92s broken.

An AS should absolutely indicate where an access_token can be used. draft=
-sakimura-oauth-meta suggests indicating this with 1 or more =93ruri=94 (=
resource URI) values in an HTTP Link header. A better approach would be i=
ncluding a list of web origins in the token response beside the access_to=
ken field.

    

    +1 

    

    This will appear more consistent with the current experience, and
    OAuth does allow the token response JSON object to be extended with
    additional members (as it's done in OpenID Connect already).

    

    Cheers,

    Vladimir

    

    

      
--
James Manger

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Flet=
cher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gma=
il.com>
Cc: <=
;oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that w=
ill accept it's tokens creates a very brittle deployment architecture. Wh=
at if a RS moves to a new endpoint? All clients would be required to get =
new tokens (if I understand correctly). And the RS move would have to coo=
rdinate with the AS to make sure all the timing is perfect in the switch =
over of endpoints.

I suspect a common deployment architecture today is that each RS requires=
 one or more scopes to access it's resources. The client then asks the us=
er to authorize a token with a requested list of scopes. The client can t=
hen send the token to the appropriate RS endpoint. The RS will not author=
ize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "b=
ad" RS which will then replay the token, then I'd rather use a PoP mechan=
ism because the point is that you want to ensure the correct client is pr=
esenting the token. Trying to ensure the client doesn't send the token to=
 the wrong endpoint seems fraught with problems.

Thanks,
George


      

      

      

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


    

    

  


--------------090900090601000706070103--

--------------ms060608020209070702020105
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjUwNzIyMzdaMC8GCSqGSIb3DQEJBDEiBCCEadEwYB2YDceKAYUY9FwdR/xqIUTd
AK/CmgOLR435sTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBxxrRVS1RD
e4YShbuFW2gryarSXPSLoB75dUbk3rwz282WLysnC/tzu5FW2qsbj/4qdpdoYuRUUWCFysQi
N/PLA6mMplYVFJOpTx8/DKtRhLg/U+GUqJXFiWe5sL9pBgqiL2gbNyff81vwe/3nmpTbCIDh
nQMJBVqogt1YtHmA5xrg4Fv7iJdx0651OKfK+0KblcuaxsPlUl7A0O/w9qwY5wSYJXuotsO4
PXoxW9zQWmRdUCTiOznVopNxeAbqtO6yaEJz0d3PPdKjBUekCvRT3fOY08zRgjO0zp68JHsk
3Rut5Kb7rrApP7C/Ad+JdyK0tnAqQ+Svns4HKjiss31KAAAAAAAA
--------------ms060608020209070702020105--


From nobody Wed Feb 24 23:43:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5B1A1A94 for ; Wed, 24 Feb 2016 23:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8GGLYhD4Mgb for ; Wed, 24 Feb 2016 23:43:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65941A1AA3 for ; Wed, 24 Feb 2016 23:43:37 -0800 (PST)
Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lpspj-1a2Whs1P55-00ff6g; Thu, 25 Feb 2016 08:43:35 +0100
To: Vladimir Dzhuvinov , oauth@ietf.org
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56CEB0A6.4050500@gmx.net>
Date: Thu, 25 Feb 2016 08:43:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CC21CB.7070404@connect2id.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Nkc2PnQb0btKwC3IAMLERSX0eVIiK8Baa"
X-Provags-ID: V03:K0:taRuu9P9VbvgwD75J7Qn27GtveEevQyo6SjXGb/DQDUEu2lM5HE H3cARVEyKfuoPJHcl1SLh6+6zZi0d9oiuu+7WCOJ5yOCgYVZN2tRXfxAmQTBMHPQi9OEozX t5Qu7awfA2H+EHJLbwKSj6NAgCIWrE06DeWRrFmY1kLaTiFQtZBZ5Tqd0sbGtt2gLLmzej1 7c6Nf7aOyyC91mxJoMUxA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:eS6kP3t0oUk=:lhYTp6qbNLZrQCz4gA9vQT 087Y8NLo5OrfFjA0BnVjk7BQwSSm8GNcFViYbpP83E4395A3xW3uu1J6iIHb2WOdlrYoZbVVa Xp/0S+25QQAkpBAXGqP+PZwtdzGtcvC5LULWgUAVsspV/IkG4uo+ATEMn8RxZJviyvj5PNXED 9/oDIiXKqXNoryAj9tJCkdWPY3yHhAr1yytLbW0rz2UGxSjnhogBalMSe5scccbhHuRV9x/8z El6wR/hBEt09cuPsvBSMk9hopThtNe4f7So+Z4b/04sJpcAP3I4D8MXH6QZvE6mCblDz0sQgh 4xXF0IHBBQjepgk7Fc17W/znIdzysjonFKjCPx10wIJLcNFVYM/3+YDH2Xvi0qg6qfQwqHVj+ 5Kylf9DVeLc2smdrtvTj94sjbWReVQWKAh77BhF5w0cSvSFACWL0KKg9mWb9NrB5NLHTsj2CR F/dttOw9YsT8LBSy3mIOVSxaSrTcGnHxbgRVQ2DRKDRAEEqPnXFHCDHCWOfHy7MbuNu9K6Ksh WKEz53FxKN+foTdZ8paMp513DgpWIQlRLj9/P0bjHpqED6/H+K/lL9WNTaN7VO6bZH+dAbtSR pPtcz3XgGrSjtEz+DpI6mt+cvro76pGu0wDeEntUag4KSPFN+4m9R6wKsIr0pkcC6f2Vkz+c/ qpQg1JI6cP2hE9R8ih59+qrigZbJuCzV0gnRhFPuB8jqxbtBZOh5bP1uY69QqiMIe8KUoiHMH NHW2ofYA1AsMCWOtYmTKk8TrR0/4B6R3ugtOsdBJKk1SQ2vjHmC8cvEKv3E=
Archived-At: 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 07:43:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Nkc2PnQb0btKwC3IAMLERSX0eVIiK8Baa
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Vladimir,

yes, we could do a formal analysis and it would be a very good idea.
It would even go faster if a few of us work together on it. Anyone
interested?

This would be a good contribution for the workshop in July, btw.

Ciao
Hannes

On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
> Hi Mike,
>=20
> You mention that you spent considerable time in research. I wonder if
> there is existing theory, in communications or information theory, that=

> can be used to formally establish and prove (or disprove) the security
> of the proposed OAuth measures? Perhaps some work that is totally
> unrelated to identity and the web protocols, but could well apply here?=

>=20
> My reasoning is that we have a closed system that is fairly simple, so
> formal analysis must be entirely possible.
>=20
> 1. We have 5 parties (client, AS, RS, user, user agent).
>=20
> 2. The OAuth protocol follows a simple and well-defined pattern of
> messages between the parties.
>=20
> 3. The points and the number of ways by which an adversary may break
> into OAuth must therefore be finite.
>=20
> 4. The security requirement is essentially to guarantee the precedence
> and authenticity of the messages from discovery endpoint to RS, and the=

> preferred way to do that is by establishing a binding between the
> messages, which can be forward or backward binding.
>=20
>=20
> Right now the WG concern is whether all possible attacks have been
> recognised, and then taken care of. If we can have a formal model that
> can reliably reveal and prove that, this will be a huge breakthrough.
>=20
> Cheers,
>=20
> Vladimir
>=20
>=20
>=20
> On 20/02/16 12:41, Mike Jones wrote:
>> Suggesting that they be read is of course, the right long-term approac=
h.  But as someone who spent 20+ years as a researcher before switching t=
o digital identity, I was sensitive to not wanting to upstage their work =
by copying too much of their material into our draft before their publica=
tions were widely known.  I'll of course commit to working the researcher=
s and the working group to create a self-contained concise description of=
 the threats and mitigations in the working group document.
>>
>> 				Cheers,
>> 				-- Mike
>>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20
>> Sent: Saturday, February 20, 2016 2:25 AM
>> To: Mike Jones ; William Denniss ; Phil Hunt (IDM) 
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call f=
or Adoption
>>
>> Hi Mike,
>>
>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>> Have you read both of their publications?  If not, do yourself a favo=
r=20
>>> and do.  They're actually both very readable and quite informative.
>> I have read both documents. In context of this discussion the question=
 is whether we
>>
>> (a) require them to be read (in which case they should be a normative =
reference), or
>> (b) suggest them to be read (since they provide additional background =
information). In this case they are an informative reference.
>>
>> I believe believe we want (b) for the OAuth WG document. While I encou=
rage everyone to read the publications I also believe that there is lots =
of material in there that goes beyond the information our audience typica=
lly reads (such as the text about the formal analysis).
>>
>> There is probably also a middle-ground where we either copy relevant t=
ext from the papers into the draft or reference specific sections that ar=
e "must-read".
>>
>> One other issue: I actually thought that the threat that is outlined i=
n the research paper is sufficiently well described but the second threat=
, which is called 'cut-and-paste attack', requires more work.
>> I noted this in my summary mail to the list, see http://www.ietf.org/m=
ail-archive/web/oauth/current/msg15697.html
>>
>> Ciao
>> Hannes
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Nkc2PnQb0btKwC3IAMLERSX0eVIiK8Baa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJWzrCmAAoJEGhJURNOOiAtnlAIAIv9ZgRdx6EiYdFTu8SkiaQU
6XzGzR4yRL88lY6EfQ5+6Fvviygwl3G5KvP5Vri66Q/+yBCAo704GDpK25OrXuG7
RkQwexHj6uJkyYTxZFtlEcW6o1qCNpSviplsSZn5K0ArMv7D0hKyzggBc538pDU2
xyfwgI2i/V1nNjiqYE3PlwS2pBw9yyIznecdE6lPfQeyjhVEm8JBNuUntJxvjE8r
aCOLZBi/v5+ql4xcA3G3y+3MZJ9hyq+/UtV6/9RcX+QHWgNwOU5Gc8MAtK8yxzi6
HbTGJX17AuHFMeTGrCIN8qZ32vebzfEMfQQKwUygO82glEJR9EjtL0s+gBObal4=
=FKxN
-----END PGP SIGNATURE-----

--Nkc2PnQb0btKwC3IAMLERSX0eVIiK8Baa--


From nobody Thu Feb 25 00:59:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CBB1A871A for ; Thu, 25 Feb 2016 00:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMuqUMjjgBKs for ; Thu, 25 Feb 2016 00:58:56 -0800 (PST)
Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A29A1A86F0 for ; Thu, 25 Feb 2016 00:58:55 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-06.prod.phx3.secureserver.net with  id NYyt1s00215ZTut01YyuaU; Thu, 25 Feb 2016 01:58:55 -0700
To: oauth@ietf.org
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>  
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56CEC24C.8040709@connect2id.com>
Date: Thu, 25 Feb 2016 10:58:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030903000308090603030407"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 08:59:02 -0000

This is a cryptographically signed message in MIME format.

--------------ms030903000308090603030407
Content-Type: multipart/alternative;
 boundary="------------070606030503070905090206"

This is a multi-part message in MIME format.
--------------070606030503070905090206
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In OIDC the discovery doc is of great utility to developers and
integrators. Developers also tend to find it a more accurate and
complete description of how to set up a client for a particular
deployment, compared to traditional online docs, which may be not be up
to date, or even missing. Very much like auto-generated Swagger and
JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-=
known/openid-configuration


With this discovery document in place setup of identity federation can
then be easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create=
_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of
the spec is that it doesn't, and it shouldn't either. By staying neutral
on the topics of RS discovery and registering RPs with RSs. And how one
arrives at the ".well-known/...". I'm not even sure that resource
discovery should be a topic of this WG. Perhaps to this end, and to
prevent confusion that the spec is trying to do something more, a more
specific title would suit it better. E.g. "AS Discovery".

Cheers,

Vladimir




On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> And so does oracle and so does google. Each different.=20
>
> So how can an app dictate it then unless we all go to a common architec=
ture?
>
> Phil
>
>> On Feb 24, 2016, at 16:04, Mike Jones  wr=
ote:
>>
>> Azure defines ways for resource servers to be registered for use with =
a client and for clients to dynamically request an access token for use a=
t a particular resource server.  You can call that custom architecture if=
 you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in t=
he standards realm.  I know that Google has syntax for doing the same, as=
 I=E2=80=99m sure do a lot of other cloud OAuth deployments, such as Orac=
le=E2=80=99s.  For what it=E2=80=99s worth, the working group talked abou=
t possibly producing a standard version of syntax for making these kinds =
of requests during our discussions in Prague (during the Token Exchange d=
iscussion) but nobody has run with this yet.
>> =20
>> In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 discover=
y metadata values that are used in production.  A registry just doesn=E2=80=
=99t yet exist in which it can register those that are of general applica=
bility.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc: 
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Mike
>> =20
>> Take a look at the assumptions you are making.=20
>> =20
>> You seem to be assuming application software dictates oauth infrastruc=
ture architecture by suggesting that apps register in iana. =20
>> =20
>> Would ms azure allow custom arch?
>>
>> Phil
>>
>> On Feb 24, 2016, at 15:28, Mike Jones  wr=
ote:
>>
>> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be discov=
ered.
>> =20
>> I agree that for some OAuth profiles, one or more resource servers wil=
l have to be discovered starting from the authorization server.  Working =
group members have also described wanting to discover authorization serve=
rs starting from resource servers.  There isn=E2=80=99t a standard practi=
ce for any of this, which is why it=E2=80=99s intentionally left out of t=
he current specification.
>> =20
>> Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it w=
ill be easy for subsequent specifications to document existing practice f=
or different OAuth profiles and register discovery metadata values suppor=
ting them.  Some of those values will likely define ways to discover reso=
urce servers, when applicable.
>> =20
>> But first, we need to finish the existing spec, so that the registry e=
nabling these extensions gets established in the first place.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones 
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Yup. And because there many relations the client mist be able to disco=
ver it. The client does not know if the res server is legit.=20
>> =20
>> The userinfo is always fix and so u dont need discovery.=20
>>
>> Phil
>>
>> On Feb 24, 2016, at 14:05, Mike Jones  wr=
ote:
>>
>> In OpenID Connect, there=E2=80=99s a resource server called the UserIn=
fo Endpoint that returns claims about the authenticated user as a JSON da=
ta structure.  Its location is published in OpenID Connect discovery meta=
data as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is =
defined at http://openid.net/specs/openid-connect-discovery-1_0.html#Prov=
iderMetadata.
>> =20
>> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth d=
iscovery spec since in OAuth, there are lots of possible relationships be=
tween authorization servers and resource servers and they needn=E2=80=99t=
 be one-to-one, as is being actively discussed by the working group.  For=
 instance, see George Fletcher=E2=80=99s recent contribution.
>> =20
>> Thanks for the good discussion, Phil.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
>> Sent: Wednesday, February 24, 2016 1:25 PM
>> To: Mike Jones
>> Cc: 
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Where is the profile endpoint (oidc's resource server) published? (For=
 the non OIDC people on the list).=20
>>
>> Phil
>>
>> On Feb 24, 2016, at 13:09, Mike Jones  wr=
ote:
>>
>> To the extent that generic OAuth 2.0 needs to publish some of the same=
 information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly th=
e same syntax, since that syntax is already in widespread use.  That what=
 this draft accomplishes.
>> =20
>> There=E2=80=99s nothing Connect-specific about using metadata response=
 values like:
>> =20
>>    "authorization_endpoint": "https://server.example.com/authorize",
>>    "token_endpoint": "https://server.example.com/token",
>>    "token_endpoint_auth_methods_supported": ["client_secret_basic", "p=
rivate_key_jwt"],
>>    "registration_endpoint": "https://server.example.com/register",
>>    "response_types_supported":  ["code", "token"],
>>    "service_documentation": "http://server.example.com/service_documen=
tation.html",
>> =20
>> Is there a reason that you would like the syntax for any of these or t=
he other generally applicable OAuth 2.0 metadata values to be different? =
 I don=E2=80=99t see any good reason for unnecessary differences to be in=
troduced.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
>> Sent: Wednesday, February 24, 2016 12:45 PM
>> To: Anthony Nadalin 
>> Cc: Mike Jones ;  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Mike
>> =20
>> Publishing on dev pages does not work for software (esp open source) t=
hat is deployed both in enterprises and on PaaS cloud providers.=20
>> =20
>> The current draft is may codify current OIDC practice and be appropria=
te for oidc but it is not ready for generic oauth. There is no generic oa=
uth experience at this time.=20
>>
>> Phil
>>
>> On Feb 24, 2016, at 10:25, Anthony Nadalin  wro=
te:
>>
>> Sure there is, it is as you have now made it far easier and the securi=
ty considerations does not even address this
>> =20
>> From: Mike Jones=20
>> Sent: Wednesday, February 24, 2016 10:22 AM
>> To: Anthony Nadalin 
>> Cc:  
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> As we=E2=80=99d discussed in person, there=E2=80=99s no effective secu=
rity difference between discovery information being published in an ad-ho=
c fashion on developer pages and it being published in a standard format.=
  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security at all.
>> =20
>>                                                           -- Mike
>> =20
>> From: Anthony Nadalin=20
>> Sent: Wednesday, February 24, 2016 10:01 AM
>> To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
>> Cc:  
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>>> The point of the WGLC is to finish standardizing the core discovery f=
unctionality that=E2=80=99s already widely deployed.
>> =20
>> That may be widely deployed for OIDC but not widely deployed for OAuth=
=2E There are some authentication mechanism discovery for endpoint that r=
eally should not be in an OAuth standard since it=E2=80=99s really not de=
alt with. Now that all this information is available it makes poking arou=
nd the endpoint more focused for people that want to disrupt your endpoin=
ts, that is really not addressed in the security considerations  section =
at all
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Phil Hunt (IDM) ; Nat Sakimura 
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> The point of the WGLC is to finish standardizing the core discovery fu=
nctionality that=E2=80=99s already widely deployed.
>> =20
>> None of Nat or John or I are suggesting that additional related functi=
onality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some app=
lications will use WebFinger to locate the discovery metadata.  Some will=
 possibly use link headers.  Some will possibly use application-specific =
=2Ewell-known values.  I=E2=80=99m sure there=E2=80=99s other things I ha=
ven=E2=80=99t even thought about.  All of these depend upon having a disc=
overy metadata document format and none of them change it =E2=80=93 other=
 than possibly to register additional discovery metadata values.
>> =20
>> So by all means, the working group should continue discussing inventin=
g possible new related mechanisms that make sense in some contexts.  At t=
he same time, we can finish standardizing the already widely deployed cor=
e functionality that all of these mechanisms will need.
>> =20
>>                                                           -- Mike
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (ID=
M)
>> Sent: Wednesday, February 24, 2016 8:39 AM
>> To: Nat Sakimura 
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> I am suggesting that part of the discovery solution has to be the clie=
nt indicating what resource endpoint it wants the oauth configuration dat=
a for.=20
>> =20
>> So if res.example.evil.com is not a valid resource endpoint for as.exa=
mple.com the authz discovery should fail in some way (eg return nothing).=
=20
>> =20
>> There may be better ways to do this. Eg combine discovery. Or change t=
he order of discovery.=20
>> =20
>> One of OAuth's strength's and weaknesses is that the target of authori=
zation (the resource) is never specified. It is often bound up in the cli=
ent registration and an often implied 1:1 relationship between resource a=
nd as. Given that in discovery phase registration has not yet occurred it=
 seems important that the client know it has a valid combination of endpo=
ints etc.=20
>> =20
>> This is why I was disappointed about wglc on discovery. We had a start=
ing point for group adoption but we haven't really defined the full requi=
rements IMO.=20
>> =20
>> I am on vacation or I would put some thought into some draft changes o=
r a new draft. I apologize I can't do it now.=20
>>
>> Phil
>>
>> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
>>
>> Hi Phil,=20
>> =20
>> Are you suggesting that the AS metadata should include the RS URIs? Cu=
rrently, it does not, but it can be done, I guess.=20
>> =20
>> The way oauth-meta works is that=20
>> =20
>> 1. RS tells the client where the AS is.=20
>> 2. AS tells the client which RS endpoints the token can be used.=20
>> =20
>> Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will say=
 that is not the place the client may want to send the token to.=20
>>
>> Nat
>> =20
>> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt :
>> Nat,
>> =20
>> I=E2=80=99m not sure that having the resource server tell the client w=
here its authorization server is secure by itself. The relationship betwe=
en the Authorization Server and the Resource server need to be bound toge=
ther in one of the discovery endpoints (the resource and/or the oauth ser=
vice discovery).
>> =20
>> If a client discovers a fake resource server that is proxying for a re=
al resource server the current discovery spec will not lead the client to=
 understand it has the wrong resource server. Rather the fake resource se=
rvice will just have a fake discovery service. The hacker can now interce=
pt resource payload as well as tokens because they were able to convince =
the client to use the legit authorization service but use the token again=
st the hackers proxy.
>> =20
>> The OAuth Discovery service needs to confirm to the client that the se=
rver is able to issue tokens for a stated resource endpoint.
>> =20
>> This not only works in normal OAuth but should add security even to UM=
A situations.
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> =20
>> =20
>> =20
>>
>> =20
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>> =20
>>
>> Hi Thomas,=20
>> =20
>> inline:=20
>> =20
>> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer :
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to de=
fine a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any UR=
L, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basi=
s for other metadata specs (like OpenID Connect).=20
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of W=
WW-Authenticate response header, you have everything you need to proceed =

>> =20
>> Yup. That's one of the requirements to be RESTful, is it not? =20
>> =20
>> In OAuth's case, the resource and the authorization server are usually=
 tightly coupled. (Otherwise, you need another specs like UMA.)=20
>> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as well=
 return the location of the authz server configuration data. In these cas=
es, you do not have to decide on what .well-known uri as you say. This fr=
ees up developers from configuration file location collisions etc. We sho=
uld strive not to pollute the uri space as much as possible.=20
>> =20
>> (well, except if there are several ASs each with different scopes; sou=
nds like an edge-case to me though; maybe RFC6750 should instead be updat=
ed with such a parameter such that an RS could return several WWW-Authent=
icate: Bearer, each with its own "scope" and "duri" value?)
>> =20
>> Yeah, I guess it is an edge case. I would rather like to see these aut=
hz servers to develop a trust framework under which they can agree on a s=
ingle set of common scope parameter values.=20
>> =20
>> Cheers,=20
>> =20
>> Nat
>> =20
>> =20
>>
>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote=
:
>> The newly-trimmed OAuth Discovery document is helpful and moving in th=
e right direction. It does, however, still have too many vestiges of its =
OpenID Connect origins. One issue in particular still really bothers me: =
the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the dis=
covery portion. Is this an OAuth discovery document, or an OpenID Connect=
 one? There is absolutely no compelling reason to tie the URL to the OIDC=
 discovery mechanism.
>>
>> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth endpoi=
nts and functions inside their service-specific discovery document.
>>
>>  =E2=80=94 Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com


--------------070606030503070905090206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    In OIDC the discovery doc is of great utility to developers and
    integrators. Developers also tend to find it a more accurate and
    complete description of how to set up a client for a particular
    deployment, compared to traditional online docs, which may be not be
    up to date, or even missing. Very much like auto-generated Swagger
    and JavaDocs.

    

    Here are some example OIDC discovery docs:

    

    https://accounts.google.com/.well-kno=
wn/openid-configuration

    

    https://www.paypalobjects.com/.well=
-known/openid-configuration

    

ht=
tps://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-kn=
own/openid-configuration

    

    

    With this discovery document in place setup of identity federation
    can then be easily scripted. For example:

    

=
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create=
_oidc_verify-thumbprint.html

    

    

    Now, does that dictate any particular app architecture? My reading
    of the spec is that it doesn't, and it shouldn't either. By staying
    neutral on the topics of RS discovery and registering RPs with RSs.
    And how one arrives at the ".well-known/...". I'm not even sure that
    resource discovery should be a topic of this WG. Perhaps to this
    end, and to prevent confusion that the spec is trying to do
    something more, a more specific title would suit it better. E.g. "AS
    Discovery".

    

    Cheers,

    

    Vladimir

    

    

    

    

    
On 25/02/16 02:25, Phil Hunt (IDM)
      wrote:

    

    

      
And so does oracle and so does google. Each differen=
t.=20

So how can an app dictate it then unless we all go to a common architectu=
re?

Phil



      

        
On Feb 24, 2016, at 16:04, Mike Jones <Mi=
chael.Jones@microsoft.com> wrote:

Azure defines ways for resource servers to be registered for use with a c=
lient and for clients to dynamically request an access token for use at a=
 particular resource server.  You can call that custom architecture if yo=
u want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in the =
standards realm.  I know that Google has syntax for doing the same, as I=E2=
=80=99m sure do a lot of other cloud OAuth deployments, such as Oracle=E2=
=80=99s.  For what it=E2=80=99s worth, the working group talked about pos=
sibly producing a standard version of syntax for making these kinds of re=
quests during our discussions in Prague (during the Token Exchange discus=
sion) but nobody has run with this yet.
=20
In this sense, yes, Azure is an application of the kind we=E2=80=99re tal=
king about.  Azure already does define specific new OAuth 2.0 discovery m=
etadata values that are used in production.  A registry just doesn=E2=80=99=
t yet exist in which it can register those that are of general applicabil=
ity.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <=
;oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Mike
=20
Take a look at the assumptions you are making.=20
=20
You seem to be assuming application software dictates oauth infrastructur=
e architecture by suggesting that apps register in iana. =20
=20
Would ms azure allow custom arch?

Phil

On Feb 24, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.c=
om> wrote:

The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be discovere=
d.
=20
I agree that for some OAuth profiles, one or more resource servers will h=
ave to be discovered starting from the authorization server.  Working gro=
up members have also described wanting to discover authorization servers =
starting from resource servers.  There isn=E2=80=99t a standard practice =
for any of this, which is why it=E2=80=99s intentionally left out of the =
current specification.
=20
Once the IANA OAuth Discovery Metadata Registry has been established, whi=
ch will happen after the current specification has been approved, it will=
 be easy for subsequent specifications to document existing practice for =
different OAuth profiles and register discovery metadata values supportin=
g them.  Some of those values will likely define ways to discover resourc=
e servers, when applicable.
=20
But first, we need to finish the existing spec, so that the registry enab=
ling these extensions gets established in the first place.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: <=
;oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Yup. And because there many relations the client mist be able to discover=
 it. The client does not know if the res server is legit.=20
=20
The userinfo is always fix and so u dont need discovery.=20

Phil

On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.c=
om> wrote:

In OpenID Connect, there=E2=80=99s a resource server called the UserInfo =
Endpoint that returns claims about the authenticated user as a JSON data =
structure.  Its location is published in OpenID Connect discovery metadat=
a as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is def=
ined at http://openid.net/s=
pecs/openid-connect-discovery-1_0.html#ProviderMetadata.
=20
We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth disc=
overy spec since in OAuth, there are lots of possible relationships betwe=
en authorization servers and resource servers and they needn=E2=80=99t be=
 one-to-one, as is being actively discussed by the working group.  For in=
stance, see George Fletcher=E2=80=99s recent contribution.
=20
Thanks for the good discussion, Phil.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <=
;oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Where is the profile endpoint (oidc's resource server) published? (For th=
e non OIDC people on the list).=20

Phil

On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.c=
om> wrote:

To the extent that generic OAuth 2.0 needs to publish some of the same in=
formation as OpenID Connect =E2=80=93 which is built on generic OAuth 2.0=
 =E2=80=93 it makes sense to publish that information using exactly the s=
ame syntax, since that syntax is already in widespread use.  That what th=
is draft accomplishes.
=20
There=E2=80=99s nothing Connect-specific about using metadata response va=
lues like:
=20
   "authorization_endpoint": "https://server.example.com/authoriz=
e",
   "token_endpoint": "https://server.example.com/token",
   "token_endpoint_auth_methods_supported": ["client_secret_basic", "priv=
ate_key_jwt"],
   "registration_endpoint": "https://server.example.com/register"<=
/a>,
   "response_types_supported":  ["code", "token"],
   "service_documentation": "http://server.exampl=
e.com/service_documentation.html",
=20
Is there a reason that you would like the syntax for any of these or the =
other generally applicable OAuth 2.0 metadata values to be different?  I =
don=E2=80=99t see any good reason for unnecessary differences to be intro=
duced.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; <oauth@ietf.org=
> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Mike
=20
Publishing on dev pages does not work for software (esp open source) that=
 is deployed both in enterprises and on PaaS cloud providers.=20
=20
The current draft is may codify current OIDC practice and be appropriate =
for oidc but it is not ready for generic oauth. There is no generic oauth=
 experience at this time.=20

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com><=
/a> wrote:

Sure there is, it is as you have now made it far easier and the security =
considerations does not even address this
=20
From: Mike Jones=20
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: <=
;oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
As we=E2=80=99d discussed in person, there=E2=80=99s no effective securit=
y difference between discovery information being published in an ad-hoc f=
ashion on developer pages and it being published in a standard format.  =E2=
=80=9CSecurity by obscurity=E2=80=9D adds no real security at all.
=20
                                                          -- Mike
=20
From: Anthony Nadalin=20
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt (=
IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>=
;
Cc: <=
;oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
=20


        

          
The point of the WGLC is to finish standardizing=
 the core discovery functionality that=E2=80=99s already widely deployed.=



        

        
=20
That may be widely deployed for OIDC but not widely deployed for OAuth. T=
here are some authentication mechanism discovery for endpoint that really=
 should not be in an OAuth standard since it=E2=80=99s really not dealt w=
ith. Now that all this information is available it makes poking around th=
e endpoint more focused for people that want to disrupt your endpoints, t=
hat is really not addressed in the security considerations  section at al=
l
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimu=
ra@gmail.com>
Cc: <=
;oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
The point of the WGLC is to finish standardizing the core discovery funct=
ionality that=E2=80=99s already widely deployed.
=20
None of Nat or John or I are suggesting that additional related functiona=
lity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applic=
ations will use WebFinger to locate the discovery metadata.  Some will po=
ssibly use link headers.  Some will possibly use application-specific .we=
ll-known values.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=
=80=99t even thought about.  All of these depend upon having a discovery =
metadata document format and none of them change it =E2=80=93 other than =
possibly to register additional discovery metadata values.
=20
So by all means, the working group should continue discussing inventing p=
ossible new related mechanisms that make sense in some contexts.  At the =
same time, we can finish standardizing the already widely deployed core f=
unctionality that all of these mechanisms will need.
=20
                                                          -- Mike
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (=
IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: <=
;oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
I am suggesting that part of the discovery solution has to be the client =
indicating what resource endpoint it wants the oauth configuration data f=
or.=20
=20
So if res.example.evil.com is not a valid resource endpoint for as.exampl=
e.com the authz discovery should fail in some way (eg return nothing).=20
=20
There may be better ways to do this. Eg combine discovery. Or change the =
order of discovery.=20
=20
One of OAuth's strength's and weaknesses is that the target of authorizat=
ion (the resource) is never specified. It is often bound up in the client=
 registration and an often implied 1:1 relationship between resource and =
as. Given that in discovery phase registration has not yet occurred it se=
ems important that the client know it has a valid combination of endpoint=
s etc.=20
=20
This is why I was disappointed about wglc on discovery. We had a starting=
 point for group adoption but we haven't really defined the full requirem=
ents IMO.=20
=20
I am on vacation or I would put some thought into some draft changes or a=
 new draft. I apologize I can't do it now.=20

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote=
:

Hi Phil,=20
=20
Are you suggesting that the AS metadata should include the RS URIs? Curre=
ntly, it does not, but it can be done, I guess.=20
=20
The way oauth-meta works is that=20
=20
1. RS tells the client where the AS is.=20
2. AS tells the client which RS endpoints the token can be used.=20
=20
Even if there is a bad AS with a valid certs that proxies to the good RS,=
 the client will not send the token there as the authz server will say th=
at is not the place the client may want to send the token to.=20

Nat
=20
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hun=
t@oracle.com>:
Nat,
=20
I=E2=80=99m not sure that having the resource server tell the client wher=
e its authorization server is secure by itself. The relationship between =
the Authorization Server and the Resource server need to be bound togethe=
r in one of the discovery endpoints (the resource and/or the oauth servic=
e discovery).
=20
If a client discovers a fake resource server that is proxying for a real =
resource server the current discovery spec will not lead the client to un=
derstand it has the wrong resource server. Rather the fake resource servi=
ce will just have a fake discovery service. The hacker can now intercept =
resource payload as well as tokens because they were able to convince the=
 client to use the legit authorization service but use the token against =
the hackers proxy.
=20
The OAuth Discovery service needs to confirm to the client that the serve=
r is able to issue tokens for a stated resource endpoint.
=20
This not only works in normal OAuth but should add security even to UMA s=
ituations.
=20
Phil
=20
@independentid
www.independentid.com
phil.hunt@oracle.com
=20
=20
=20

=20
On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> wro=
te:
=20

Hi Thomas,=20
=20
inline:=20
=20
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broy=
er@gmail.com>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to =
do discovery, and leave it open to implementers / to other specs to defin=
e a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, =
returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis f=
or other metadata specs (like OpenID Connect).=20
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-=
Authenticate response header, you have everything you need to proceed=20
=20
Yup. That's one of the requirements to be RESTful, is it not? =20
=20
In OAuth's case, the resource and the authorization server are usually ti=
ghtly coupled. (Otherwise, you need another specs like UMA.)=20
So, the resource server should be able to tell either the location of the=
 authz endpoint. In some trusted environment, the resource may as well re=
turn the location of the authz server configuration data. In these cases,=
 you do not have to decide on what .well-known uri as you say. This frees=
 up developers from configuration file location collisions etc. We should=
 strive not to pollute the uri space as much as possible.=20
=20
(well, except if there are several ASs each with different scopes; sounds=
 like an edge-case to me though; maybe RFC6750 should instead be updated =
with such a parameter such that an RS could return several WWW-Authentica=
te: Bearer, each with its own "scope" and "duri" value?)
=20
Yeah, I guess it is an edge case. I would rather like to see these authz =
servers to develop a trust framework under which they can agree on a sing=
le set of common scope parameter values.=20
=20
Cheers,=20
=20
Nat
=20
=20

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrot=
e:
The newly-trimmed OAuth Discovery document is helpful and moving in the r=
ight direction. It does, however, still have too many vestiges of its Ope=
nID Connect origins. One issue in particular still really bothers me: the=
 use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discov=
ery portion. Is this an OAuth discovery document, or an OpenID Connect on=
e? There is absolutely no compelling reason to tie the URL to the OIDC di=
scovery mechanism.

I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document MAY=
 also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D=
 if the server also provides OpenID Connect on the same domain. Other app=
lications SHOULD use the same parameter names to describe OAuth endpoints=
 and functions inside their service-specific discovery document.

 =E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=20
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


      

      

      

      

      

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


    

    

    
--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com

  


--------------070606030503070905090206--

--------------ms030903000308090603030407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjUwODU4NTJaMC8GCSqGSIb3DQEJBDEiBCB41iHn3cdcUnml6uPzzkV+cg5hBFTq
5E/6LBs9oX43YjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQA7J+ReRBEn
2gkzW8+5hFUs6QcbAtUT/27mcm5eQlsQx1JaZuqw/eKGlLbwXJmQkBR+0tf6gx8nTQm+OItG
yhj7CsIGKtI6Zozbl99R8a9eWUqeVKDcM8dzrNBlP4S0rVGIJhRieAL/FkfTId8wr2K8gecD
UKustE0IRXY/SCoQMhpypKm6o5tTrlI+EFM/5P61a9XyOXwRqyubwsYyEsllczUJEbvgneDu
F6krsbMnEcpg7erWdGSi51jvb8wictzQE1ElMyPLXvjKaFTS0kOxX5rAfUFELux1eFKA7T59
mIYlfjMPJDVYJYGfHNqKT4N983GgUM2Gdvipnq3+RrvhAAAAAAAA
--------------ms030903000308090603030407--


From nobody Thu Feb 25 02:35:57 2016
Return-Path: <777ilililililililil@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0B1A047A for ; Thu, 25 Feb 2016 02:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.261
X-Spam-Level: 
X-Spam-Status: No, score=-0.261 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, FROM_STARTS_WITH_NUMS=0.738, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Gv75uZzBjzbv for ; Thu, 25 Feb 2016 02:35:54 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7D11A6F67 for ; Thu, 25 Feb 2016 02:35:54 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id g62so21952376wme.1 for ; Thu, 25 Feb 2016 02:35:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=mAr359jiEkPJHXdUZf3UEW2YkqLoJu5gz7fQJGtX/A8=; b=XB0K7ZWiORrb75y4+u2eeaCvIN1w8ztWl/0KctkObgvDRBXnA0dTCeTVOnWM0GVu4m hdl+YbeKD658BC3k1Zifaw4cYDg51WI6iyTPfn8NArbbYQCMsfqsm2v1jBSS8+UHB6tC op9rMAuAomZkrc2nVqF/LCKirvFKGALqtn9ZiWLazz7w7Oeod/A16cUtaMOxwIFBtfq/ sr7gA1StQ1uqF2v8qusRKrDM9xK4IvDrQ3ZWaE0Qld+Ak6XQd5u9FadYzshdHMbvszLA /3PVA9ZdAst5Hhvc68r5FYDEZmoiJwzyUXx2KKEAqQAkrvCqdHswwThGUjAcjwQRxudr 4xtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mAr359jiEkPJHXdUZf3UEW2YkqLoJu5gz7fQJGtX/A8=; b=fMHXNQQw3u14rSKLNQHQw1Z12E8BmFMxPojFkDN9heGy7z+oAwgOsyA2QvTG13w3b3 Q0xlqVM8CybCVhMmobkmg34TP/JbG4+A/J8EIYImzDU/8lUL+3pEfdPRpoGqwx1nYLnh AV6AcSjRi0iVp2fUxjRKlb5VUSQexgfsGsnOMT1GDZIpG9t0jFirEbo2ssj0+oSN7nSt cJWWhxr4bqIePHxp22z0BbrpYVUoTjYJV1lge2zToxNowsNx8vGSSIQt6UKC3n+rY0Z0 Jcf9qny2VhKZ7K/25FTOAcajBoCZrfZtil4FUUtslf3ALTWpC0rSULT3p9Z632jzGmio +1qQ==
X-Gm-Message-State: AG10YOSJDNJFGv5f8VvOSNP5CfIHSQ5YPzPenmZbLnwxZXHm+VSMVpuESOYcMSEZQk+UCsxoLoWbtbzFlwlWCg==
X-Received: by 10.28.22.74 with SMTP id 71mr2632071wmw.47.1456396552957; Thu, 25 Feb 2016 02:35:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.102.87 with HTTP; Thu, 25 Feb 2016 02:35:23 -0800 (PST)
From: Dred J <777ilililililililil@gmail.com>
Date: Thu, 25 Feb 2016 19:35:23 +0900
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a1146762c30fa4f052c95bfda
Archived-At: 
Subject: [OAUTH-WG] (no subject)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 10:35:55 -0000

--001a1146762c30fa4f052c95bfda
Content-Type: text/plain; charset=UTF-8

 ----------   J Dred from  --------------

--001a1146762c30fa4f052c95bfda
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=C2=A0----------=C2=A0=C2=A0 J Dred from=C2=A0 --------------<=
/div>




--001a1146762c30fa4f052c95bfda--


From nobody Thu Feb 25 06:05:17 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE2D1ACD97 for ; Thu, 25 Feb 2016 06:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 8iemSVgRtmF3 for ; Thu, 25 Feb 2016 06:05:13 -0800 (PST)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id DCAB51ACD8D for ; Thu, 25 Feb 2016 06:05:12 -0800 (PST)
Received: (qmail 21390 invoked by uid 0); 25 Feb 2016 14:05:10 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 25 Feb 2016 14:05:10 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw4 with  id Ne501s00L2is6CS01e531a; Thu, 25 Feb 2016 07:05:10 -0700
X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=rE68L1KyjUoA:10 a=zwqKzj3qmOAA:10 a=jFJIQSaiL_oA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=UGkfVyPCAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8 a=pGLkceISAAAA:8 a=NFueVOWuk3jI_zvwBjoA:9 a=nH-AxX8ehqZ9UqIl:21 a=q-ZBoqf_T34So_gV:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=bWs5RZA5M6ZyPJ5mhQkA:9 a=CX4EYopR1YCGR3Df:21 a=AE06R1NIepf5Sbba:21 a=hkzjEweyeugLRY_W:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=rBlN2L6iEtDBreCVHp3lRj25zKjdVrBsd+xSDRijvQU=;  b=izQOvKU3L148ZaAowwsgI7+bGK59sfVjM5hUPmGshOsu3iXY1yvjn29YOsPcA6jVumwtDahc9iwU1PGflrIT8BalhndjBKjx2W9wfdlNGMwuaNoL4NmK7qy+s2S7pNcv;
Received: from [162.206.229.38] (port=2072 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1aYwXL-0003P9-Ub; Thu, 25 Feb 2016 07:05:00 -0700
From: "Donald F. Coffin" 
To: "'Vladimir Dzhuvinov'" , 
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com>
In-Reply-To: <56CEABBD.1040602@connect2id.com>
Date: Thu, 25 Feb 2016 09:02:48 -0500
Organization: REMI Networks
Message-ID: <005801d16fd5$37557680$a6006380$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01D16FAB.4E807FF0"
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQErEGUxIthpCNQAgVnbL+9JTvjuPAKQYZUXAMzfEkkBvAxTnwHmAZgaAtiXPCUBaONgB6AvgYbg
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 162.206.229.38 authed with donald.coffin@reminetworks.com}
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 14:05:16 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0059_01D16FAB.4E807FF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In fact, this is the method being used by utilities implementing the Green
Button Connect My Data interface (North American Energy Standards Boards'
(NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider
Interface - ESPI).  The Green Button Alliance is in the processing of
updating the specification to use OAuth 2.0.  The industry OpenADE Task
Force, which is the technical WG of the UCAIug, defined additional
information be returned with the OAuth 2.0  Token Response that includes the
URI of the resource to which the AT can be used.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:      (949) 636-8571

Email:        
donald.coffin@reminetworks.com

 

From: Vladimir Dzhuvinov [mailto:vladimir@connect2id.com] 
Sent: Thursday, February 25, 2016 2:23 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

 

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will
accept it's tokens creates a very brittle deployment architecture

 
The AS is issuing temporary credentials (access_tokens) to clients but
doesn't know where those credentials will work? That's broken.
 
An AS should absolutely indicate where an access_token can be used.
draft-sakimura-oauth-meta suggests indicating this with 1 or more "ruri"
(resource URI) values in an HTTP Link header. A better approach would be
including a list of web origins in the token response beside the
access_token field.

+1 

This will appear more consistent with the current experience, and OAuth does
allow the token response JSON object to be extended with additional members
(as it's done in OpenID Connect already).

Cheers,
Vladimir




--
James Manger
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt   ; Nat
Sakimura   
Cc:     

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
 
I'm concerned that forcing the AS to know about all RS's endpoints that will
accept it's tokens creates a very brittle deployment architecture. What if a
RS moves to a new endpoint? All clients would be required to get new tokens
(if I understand correctly). And the RS move would have to coordinate with
the AS to make sure all the timing is perfect in the switch over of
endpoints.
 
I suspect a common deployment architecture today is that each RS requires
one or more scopes to access it's resources. The client then asks the user
to authorize a token with a requested list of scopes. The client can then
send the token to the appropriate RS endpoint. The RS will not authorize
access unless the token has the required scopes.
 
If the concern is that the client may accidentally send the token to a "bad"
RS which will then replay the token, then I'd rather use a PoP mechanism
because the point is that you want to ensure the correct client is
presenting the token. Trying to ensure the client doesn't send the token to
the wrong endpoint seems fraught with problems.
 
Thanks,
George






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

 


------=_NextPart_000_0059_01D16FAB.4E807FF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


In fact, this is =
the method being used by utilities implementing the Green Button Connect =
My Data interface (North American Energy Standards Boards’ (NAESB) =
Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider =
Interface – ESPI).  The Green Button Alliance is in the =
processing of updating the specification to use OAuth 2.0.  The =
industry OpenADE Task Force, which is the technical WG of the UCAIug, =
defined additional information be returned with the OAuth 2.0 =
 Token Response that includes the URI of the resource to which the =
AT can be used.
 <=
/span>
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
2335 =
Dunwoody Xing #E
Dunwoody, GA =
30338-8221
 
Phone: &=
nbsp;    (949) 636-8571
Email: &=
nbsp;     donald.coffin@reminetworks.com
 <=
/span>
From: Vladimir Dzhuvinov [mailto:vladimir@connect2id.com] =

Sent: Thursday, February 25, 2016 2:23 AM
To: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
 
On 25/02/16 09:02, Manger, James =
wrote:
I'm concerned that =
forcing the AS to know about all RS's endpoints that will accept it's =
tokens creates a very brittle deployment =
architecture
 
The AS is issuing temporary credentials (access_tokens) to clients but =
doesn’t know where those credentials will work? That’s =
broken.
 
An AS should =
absolutely indicate where an access_token can be used. =
draft-sakimura-oauth-meta suggests indicating this with 1 or more =
“ruri” (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.
+1 

This will appear more consistent with the =
current experience, and OAuth does allow the token response JSON object =
to be extended with additional members (as it's done in OpenID Connect =
already).

Cheers,
Vladimir


--
James Manger
 
From: =
OAuth [mailto:oauth-bounces@ietf.org]=
 On Behalf Of George Fletcher
Sent: Thursday, 25 =
February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; =
Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
I'm concerned =
that forcing the AS to know about all RS's endpoints that will accept =
it's tokens creates a very brittle deployment architecture. What if a RS =
moves to a new endpoint? All clients would be required to get new tokens =
(if I understand correctly). And the RS move would have to coordinate =
with the AS to make sure all the timing is perfect in the switch over of =
endpoints.
 
I suspect a =
common deployment architecture today is that each RS requires one or =
more scopes to access it's resources. The client then asks the user to =
authorize a token with a requested list of scopes. The client can then =
send the token to the appropriate RS endpoint. The RS will not authorize =
access unless the token has the required =
scopes.
 
If the concern =
is that the client may accidentally send the token to a "bad" =
RS which will then replay the token, then I'd rather use a PoP mechanism =
because the point is that you want to ensure the correct client is =
presenting the token. Trying to ensure the client doesn't send the token =
to the wrong endpoint seems fraught with =
problems.
 
Thanks,
George



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

------=_NextPart_000_0059_01D16FAB.4E807FF0--


From nobody Thu Feb 25 07:14:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A181B2A12 for ; Thu, 25 Feb 2016 07:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4cc2dxiiYEI for ; Thu, 25 Feb 2016 07:14:07 -0800 (PST)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC121B2A1A for ; Thu, 25 Feb 2016 07:14:07 -0800 (PST)
Received: from mtaout-aad02.mx.aol.com (mtaout-aad02.mx.aol.com [172.26.127.226]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 4BFA63800336; Thu, 25 Feb 2016 10:14:06 -0500 (EST)
Received: from [10.172.228.63] (unknown [10.172.228.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aad02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2E15E3800008D; Thu, 25 Feb 2016 10:14:03 -0500 (EST)
To: "Manger, James" , "" 
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56CF1A45.6040708@aol.com>
Date: Thu, 25 Feb 2016 10:14:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
Content-Type: multipart/alternative; boundary="------------030206080706040602040701"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456413246; bh=HdJRpY++Nmhhx8/T0j14Ef/fR78R7dfyh1ByQzBSJ4Q=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=IMf072lqd6enRJ+/9HRB/WTww77vS54c7Hbo2ICGsMEBaI3i4qzr/6KuhVZhdp6Nx 9xkY6cWWZ3gVIYOFkGUcqQqm/vUC6iBeJ0+0BpUgMmj71t7tIrHMeBCm6XisoSbfG+ H6RXeZXlJymx7Rs54RAj4rvnGOkPq6T2RUZlgNFk=
x-aol-sid: 3039ac1a7fe256cf1a3b047d
X-AOL-IP: 10.172.228.63
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 15:14:14 -0000

This is a multi-part message in MIME format.
--------------030206080706040602040701
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The AS knows the RS's that will consume it's tokens because it knows the 
scopes that it can allow the user to authorize. I don't think the AS 
MUST know the endpoints of the RS (which is what the current drafts 
require).

It is not often that the entity/group responsible for the Authorization 
Service is also responsible for the actual resource server. Take for 
example a Mail API run by one team and the Authorization server managed 
by the Identity team.

Requiring the Mail Team to notify and coordinate the change of endpoints 
for a new deployment is brittle.

Also, I believe the main reason for wanting to bind a token to an 
endpoint is to protect the token from being sent to a malicious RS and 
then having that RS replay the token. If possible replay of a token is 
the main concern, then why not use PoP which ensures that only the 
appropriate client and present the token. This seems a much cleaner way 
to protect against this threat.

Thanks,
George

On 2/25/16 2:02 AM, Manger, James wrote:
>
> > I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture
>
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
>
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more 
> “ruri†(resource URI) values in an HTTP Link header. A better approach 
> would be including a list of web origins in the token response beside 
> the access_token field.
>
> --
>
> James Manger
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George 
> Fletcher
> *Sent:* Thursday, 25 February 2016 6:17 AM
> *To:* Phil Hunt ; Nat Sakimura 
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture. What if a RS moves to a new endpoint? All clients would 
> be required to get new tokens (if I understand correctly). And the RS 
> move would have to coordinate with the AS to make sure all the timing 
> is perfect in the switch over of endpoints.
>
> I suspect a common deployment architecture today is that each RS 
> requires one or more scopes to access it's resources. The client then 
> asks the user to authorize a token with a requested list of scopes. 
> The client can then send the token to the appropriate RS endpoint. The 
> RS will not authorize access unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a 
> "bad" RS which will then replay the token, then I'd rather use a PoP 
> mechanism because the point is that you want to ensure the correct 
> client is presenting the token. Trying to ensure the client doesn't 
> send the token to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>


--------------030206080706040602040701
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    The AS knows the RS's that
      will consume it's tokens because it knows the scopes that it can
      allow the user to authorize. I don't think the AS MUST know the
      endpoints of the RS (which is what the current drafts require).

      

      It is not often that the entity/group responsible for the
      Authorization Service is also responsible for the actual resource
      server. Take for example a Mail API run by one team and the
      Authorization server managed by the Identity team.

      

      Requiring the Mail Team to notify and coordinate the change of
      endpoints for a new deployment is brittle.

      

      Also, I believe the main reason for wanting to bind a token to an
      endpoint is to protect the token from being sent to a malicious RS
      and then having that RS replay the token. If possible replay of a
      token is the main concern, then why not use PoP which ensures that
      only the appropriate client and present the token. This seems a
      much cleaner way to protect against this threat.

      

      Thanks,

      George

    

    
On 2/25/16 2:02 AM, Manger, James
      wrote:

    

    

      
      
      
      

        
>
          I'm
            concerned that forcing the AS to know about all RS's
            endpoints that will accept it's tokens creates a very
            brittle deployment architecture

        
 

        
The
            AS is issuing temporary credentials (access_tokens) to
            clients but doesn’t know where those credentials will work?
            That’s broken.

        
 

        
An
            AS should absolutely indicate where an access_token can be
            used. draft-sakimura-oauth-meta suggests indicating this
            with 1 or more “ruri†(resource URI) values in an HTTP Link
            header. A better approach would be including a list of web
            origins in the token response beside the access_token field.

        
 

        
--

        
James
            Manger

        
 

        

          

            
From: OAuth [mailto:oauth-bounces@ietf.org] On
                  Behalf Of George Fletcher

                Sent: Thursday, 25 February 2016 6:17 AM

                To: Phil Hunt <phil.hunt@oracle.com>; Nat
                Sakimura <sakimura@gmail.com>

                Cc: <oauth@ietf.org> <oauth@ietf.org>

                Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery
                Location

          

        

        
 

        
I'm
            concerned that forcing the AS to know about all RS's
            endpoints that will accept it's tokens creates a very
            brittle deployment architecture. What if a RS moves to a new
            endpoint? All clients would be required to get new tokens
            (if I understand correctly). And the RS move would have to
            coordinate with the AS to make sure all the timing is
            perfect in the switch over of endpoints.

            

            I suspect a common deployment architecture today is that
            each RS requires one or more scopes to access it's
            resources. The client then asks the user to authorize a
            token with a requested list of scopes. The client can then
            send the token to the appropriate RS endpoint. The RS will
            not authorize access unless the token has the required
            scopes.

            

            If the concern is that the client may accidentally send the
            token to a "bad" RS which will then replay the token, then
            I'd rather use a PoP mechanism because the point is that you
            want to ensure the correct client is presenting the token.
            Trying to ensure the client doesn't send the token to the
            wrong endpoint seems fraught with problems.

            

            Thanks,

            George

      

    

    

  


--------------030206080706040602040701--


From nobody Thu Feb 25 07:16:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02E81B2A2C for ; Thu, 25 Feb 2016 07:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNHhvIXD9NoX for ; Thu, 25 Feb 2016 07:16:49 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0403C1B2A2A for ; Thu, 25 Feb 2016 07:16:49 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id s5so20511503qkd.0 for ; Thu, 25 Feb 2016 07:16:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=x1CWDjwAi95I/8OO3Qy4ouCZ8mYlMBDyonTazf6CgKg=; b=aAS47PnzJid8fV5WpGoIPzb3Fg/p00VFbhXHjpZbU2YKrlKmQmNkQITRm9ITaD3Xdu a370KVMBdMYG5lbnXOnf1BvdeNNPi8Zvl1wVmUvRiJVH41svGMbAjjaYFDH2CS6DPBnA 9wkyvVugWU5T6eEv1HMYipFf92KQcgJlUouraOfSYEnDNZt9SFdlW23P0PN2g5xOglcl QzZNpBqnZd+2gRGzjTSrI+704MeUYUjpGcQwl2ufnpQCOJ0g38NrYgsehzTzwptUZPs3 8uHDWcgQPP5Dwmhk9CjNGaIIRCf1iMAS/Jso1cn5BWVgZbrXIDqpYJS6CvZ0PPR7qoSu Nmtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=x1CWDjwAi95I/8OO3Qy4ouCZ8mYlMBDyonTazf6CgKg=; b=Bd+rCd9OqdkNKKei2cCAn6vkRfuUa2oO8pLbtTJ9+Z/iOYBer/f4/gBbkhaVPC/jXb Rw+Ka5gV6bJ1oDCGxYa9cxfNNzFyyG+1ZvR+ZHSfHkWGY+Xi0BXt7/L7gPrMhx0efKnF fMd5QuHLpOAhNOxfskMziPVkklNKLtz8UX5toS3ERfZazCB/AEe0D3+OTKAk5fo2iqIC bNRh5ET4ZDQaRRFh0HG0XeUWw2qZAS5y5aHKx7b8dUrKPTq3EupRLgH1QmzZBriEdfuw U0sqm1Q0kOPAep5KReIpkqiNNjEMEm3hTECuqemKqn3fqGmaHvE6nz+DD886uD5csvJp zpjA==
X-Gm-Message-State: AG10YOTeywmlS3AHgFoInw38EPhN3LWEiey5V3uTE/hZMX+mBwNvYr5uQ0T/N9nWfZaxjVSOKBOieNMV+AMufw==
X-Received: by 10.55.200.215 with SMTP id t84mr41463558qkl.55.1456413407997; Thu, 25 Feb 2016 07:16:47 -0800 (PST)
MIME-Version: 1.0
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <005801d16fd5$37557680$a6006380$@reminetworks.com>
In-Reply-To: <005801d16fd5$37557680$a6006380$@reminetworks.com>
From: Nat Sakimura 
Date: Thu, 25 Feb 2016 15:16:37 +0000
Message-ID: 
To: "Donald F. Coffin" ,  Vladimir Dzhuvinov , oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a113c259ad476dd052c99ab3c
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 15:16:56 -0000

--001a113c259ad476dd052c99ab3c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Interesting. Is there a link that I can download your spec etc. ?

I have not much preference over the actual endpoint link or the web origin.
As long as the semantics is clear, either is fine.
I was even considering using URI template. It will be extremely flexible,
but I am not sure about the current status of the library availability and
its qualities.

Re: RFC5988 header or JSON - If you go back to earlier drafts, I was using
JSON. This will make it independent of HTTPS.
Also, developers can just process the JSON and store it in JSON. This is a
overall win.
Downside is that there is no standard for doing JSON metadata. Since
Swagger is using JSON Schema way of expressing it, perhaps that's the way
we should go, though, HAL seems to be a bit more efficient and nice.

In either way, though, IMHO, it is important to define the link relation in
the RFC5988 IANA registry.
Converting RFC5988 link header to either JSON schema metadata or HAL is
trivial.

Nat


2016=E5=B9=B42=E6=9C=8825=E6=97=A5(=E6=9C=A8) 23:05 Donald F. Coffin :

> In fact, this is the method being used by utilities implementing the Gree=
n
> Button Connect My Data interface (North American Energy Standards Boards=
=E2=80=99
> (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service
> Provider Interface =E2=80=93 ESPI).  The Green Button Alliance is in the =
processing
> of updating the specification to use OAuth 2.0.  The industry OpenADE Tas=
k
> Force, which is the technical WG of the UCAIug, defined additional
> information be returned with the OAuth 2.0  Token Response that includes
> the URI of the resource to which the AT can be used.
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Xing #E
>
> Dunwoody, GA 30338-8221
>
>
>
> Phone:      (949) 636-8571
>
> Email:       donald.coffin@reminetworks.com
>
>
>
> *From:* Vladimir Dzhuvinov [mailto:vladimir@connect2id.com]
> *Sent:* Thursday, February 25, 2016 2:23 AM
> *To:* oauth@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that w=
ill accept it's tokens creates a very brittle deployment architecture
>
>
>
> The AS is issuing temporary credentials (access_tokens) to clients but do=
esn=E2=80=99t know where those credentials will work? That=E2=80=99s broken=
.
>
>
>
> An AS should absolutely indicate where an access_token can be used. draft=
-sakimura-oauth-meta suggests indicating this with 1 or more =E2=80=9Cruri=
=E2=80=9D (resource URI) values in an HTTP Link header. A better approach w=
ould be including a list of web origins in the token response beside the ac=
cess_token field.
>
> +1
>
> This will appear more consistent with the current experience, and OAuth
> does allow the token response JSON object to be extended with additional
> members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
> --
>
> James Manger
>
>
>
> From: OAuth [mailto:oauth-bounces@ietf.org ] On B=
ehalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt  ; Nat Sakimura=
  
>
> Cc:    
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I'm concerned that forcing the AS to know about all RS's endpoints that w=
ill accept it's tokens creates a very brittle deployment architecture. What=
 if a RS moves to a new endpoint? All clients would be required to get new =
tokens (if I understand correctly). And the RS move would have to coordinat=
e with the AS to make sure all the timing is perfect in the switch over of =
endpoints.
>
>
>
> I suspect a common deployment architecture today is that each RS requires=
 one or more scopes to access it's resources. The client then asks the user=
 to authorize a token with a requested list of scopes. The client can then =
send the token to the appropriate RS endpoint. The RS will not authorize ac=
cess unless the token has the required scopes.
>
>
>
> If the concern is that the client may accidentally send the token to a "b=
ad" RS which will then replay the token, then I'd rather use a PoP mechanis=
m because the point is that you want to ensure the correct client is presen=
ting the token. Trying to ensure the client doesn't send the token to the w=
rong endpoint seems fraught with problems.
>
>
>
> Thanks,
>
> George
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a113c259ad476dd052c99ab3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Interesting. Is there a link that I can download your spec=
 etc. ?=C2=A0

I have not much preference over the actual=
 endpoint link or the web origin. As long as the semantics is clear, either=
 is fine.=C2=A0
I was even considering using URI template. It wil=
l be extremely flexible, but I am not sure about the current status of the =
library availability and its qualities.=C2=A0

Re: =
RFC5988 header or JSON - If you go back to earlier drafts, I was using JSON=
. This will make it independent of HTTPS.=C2=A0
Also, developers =
can just process the JSON and store it in JSON. This is a overall win.=C2=
=A0
Downside is that there is no standard for doing JSON metadata=
. Since Swagger is using JSON Schema way of expressing it, perhaps that'=
;s the way we should go, though, HAL seems to be a bit more efficient and n=
ice.=C2=A0

In either way, though, IMHO, it is impo=
rtant to define the link relation in the RFC5988 IANA registry.=C2=A0
=

Converting RFC5988 link header to either JSON schema metadata or HAL i=
s trivial.=C2=A0

Nat

2016=E5=B9=B42=E6=9C=8825=E6=
=97=A5(=E6=9C=A8) 23:05 Donald F. Coffin <donald.coffin@reminetworks.com>:
In fact, this is the method bein=
g used by utilities implementing the Green Button Connect My Data interface=
 (North American Energy Standards Boards=E2=80=99 (NAESB) Retail Energy Qua=
drant 21 (REQ.21) Standard (Energy Service Provider Interface =E2=80=93 ESP=
I).=C2=A0 The Green Button Alliance is in the processing of updating the sp=
ecification to use OAuth 2.0.=C2=A0 The industry OpenADE Task Force, which =
is the technical WG of the UCAIug, defined additional information be return=
ed with the OAuth 2.0 =C2=A0Token Response that includes the URI of the res=
ource to which the AT can be used.
=C2=A0
Best regar=
ds,
Don
Donald F. Coffin
Founder/CTO
=C2=A0
RE=
MI Networks
2335 Dunwoody X=
ing #E
Dunwoody, GA 30338-8=
221
=C2=A0
Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) =
636-8571
Email:=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.=
com
=C2=
=A0
From: Vladimir Dzhuvinov [mailto:vladimir@connect2id.c=
om] 
Sent: Thursday, February 25, 2016 2:23 AM
To: =
oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location=

=C2=A0
=C2=A0
On 25/02/16 09:02, Manger=
, James wrote:
I'm concerned that forcing the AS to know about all RS's=
 endpoints that will accept it's tokens creates a very brittle deployme=
nt architecture
=C2=A0
The AS is issuing temporary credentials (access_tokens) to clients=
 but doesn=E2=80=99t know where those credentials will work? That=E2=80=99s=
 broken.
=C2=A0
An AS shoul=
d absolutely indicate where an access_token can be used. draft-sakimura-oau=
th-meta suggests indicating this with 1 or more =E2=80=9Cruri=E2=80=9D (res=
ource URI) values in an HTTP Link header. A better approach would be includ=
ing a list of web origins in the token response beside the access_token fie=
ld.
+1 

This =
will appear more consistent with the current experience, and OAuth does all=
ow the token response JSON object to be extended with additional members (a=
s it's done in OpenID Connect already).

Cheers,
Vladimir
<=
br>
--
James Manger
=C2=A0
From: OAuth [mailto:oauth-bounces@ietf.org] On Behal=
f Of George Fletcher
Sent: Thursday, 25 February 20=
16 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakim=
ura <sakimura@gm=
ail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location=C2=A0
I'm concerned that forcing the AS to =
know about all RS's endpoints that will accept it's tokens creates =
a very brittle deployment architecture. What if a RS moves to a new endpoin=
t? All clients would be required to get new tokens (if I understand correct=
ly). And the RS move would have to coordinate with the AS to make sure all =
the timing is perfect in the switch over of endpoints.
<=
pre>=C2=A0
I suspect a common deployment architectu=
re today is that each RS requires one or more scopes to access it's res=
ources. The client then asks the user to authorize a token with a requested=
 list of scopes. The client can then send the token to the appropriate RS e=
ndpoint. The RS will not authorize access unless the token has the required=
 scopes.
=C2=A0
If the conc=
ern is that the client may accidentally send the token to a "bad"=
 RS which will then replay the token, then I'd rather use a PoP mechani=
sm because the point is that you want to ensure the correct client is prese=
nting the token. Trying to ensure the client doesn't send the token to =
the wrong endpoint seems fraught with problems.
=
=C2=A0
Thanks,
George



______=
_________________________________________
OAuth mai=
ling list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth
=C2=A0
________________________________=
_______________

OAuth mailing list

OAuth@ietf.org

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




--001a113c259ad476dd052c99ab3c--


From nobody Thu Feb 25 07:25:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053F61B2A47 for ; Thu, 25 Feb 2016 07:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp1L_Bgo48d2 for ; Thu, 25 Feb 2016 07:25:28 -0800 (PST)
Received: from omr-a002e.mx.aol.com (omr-a002e.mx.aol.com [204.29.186.56]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB361B2A48 for ; Thu, 25 Feb 2016 07:25:24 -0800 (PST)
Received: from mtaout-aaj02.mx.aol.com (mtaout-aaj02.mx.aol.com [172.27.3.206]) by omr-a002e.mx.aol.com (Outbound Mail Relay) with ESMTP id 710C238000A3; Thu, 25 Feb 2016 10:25:23 -0500 (EST)
Received: from [10.172.228.63] (unknown [10.172.228.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2403738000095; Thu, 25 Feb 2016 10:25:21 -0500 (EST)
To: Vladimir Dzhuvinov , oauth@ietf.org
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56CF1CEB.8030603@aol.com>
Date: Thu, 25 Feb 2016 10:25:31 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56CEABBD.1040602@connect2id.com>
Content-Type: multipart/alternative; boundary="------------020209010607070507080606"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456413923; bh=0C7LGN4e+OmKwWO4ZqNJSBL77xXmyOYNZhbCdBniQ2c=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=W+W82pKpCzmbhTgqUh0impRhwxwHJL7rFZ7IKBWKX1tXBs2RhEHny18uqXNwuKrRl bidZYlqqvSWuj/Ws5uh27Wo4iAyg3/J0lLn0vbrExNKU5z1DsqfMgrFaZ8x+oo84uS GQ5d9wcBVQcPXN/juJHTLR98HEoYHXjkF5PQGDxo=
x-aol-sid: 3039ac1b03ce56cf1ce1088e
X-AOL-IP: 10.172.228.63
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 15:25:31 -0000

This is a multi-part message in MIME format.
--------------020209010607070507080606
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Interesting... this is not at all my current experience:) If a RS goes 
from v2 of it's API to v3 and that RS uses the current standard of 
putting a "v2" or"v3" in it's API path... then a token issued for v2 of 
the API can not be sent to v3 of the API, because v3 wasn't wasn't 
registered/deployed when the token was issued.

The constant management of scopes to URI endpoints seems like a 
complexity that will quickly get out of hand.

Thanks,
George

On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>
>
> On 25/02/16 09:02, Manger, James wrote:
>>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>
>> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri†(resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
> +1
>
> This will appear more consistent with the current experience, and 
> OAuth does allow the token response JSON object to be extended with 
> additional members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>> --
>> James Manger
>>
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
>> Sent: Thursday, 25 February 2016 6:17 AM
>> To: Phil Hunt; Nat Sakimura
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>
>> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>
>> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>
>> Thanks,
>> George
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------020209010607070507080606
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Interesting... this is not
      at all my current experience:) If a RS goes from v2 of it's API to
      v3 and that RS uses the current standard of putting a "v2" or"v3"
      in it's API path... then a token issued for v2 of the API can not
      be sent to v3 of the API, because v3 wasn't wasn't registered/deployed
      when the token was issued. 

      

      The constant management of scopes to URI endpoints seems like a
      complexity that will quickly get out of hand.

      

      Thanks,

      George

    

    
On 2/25/16 2:22 AM, Vladimir Dzhuvinov
      wrote:

    

    

      
      

      

      
On 25/02/16 09:02, Manger, James
        wrote:

      

      

        

          
I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture


        

        
The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri†(resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.

      

      +1 

      

      This will appear more consistent with the current experience, and
      OAuth does allow the token response JSON object to be extended
      with additional members (as it's done in OpenID Connect already).

      

      Cheers,

      Vladimir

      

      

        
--
James Manger

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.

Thanks,
George


        

        

        

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


      

      

      

      

      

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


    

    

    

  


--------------020209010607070507080606--


From nobody Thu Feb 25 07:27:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4E1B2A75 for ; Thu, 25 Feb 2016 07:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMH5nW_tm7aQ for ; Thu, 25 Feb 2016 07:27:45 -0800 (PST)
Received: from omr-m007e.mx.aol.com (omr-m007e.mx.aol.com [204.29.186.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE051B2A6A for ; Thu, 25 Feb 2016 07:27:45 -0800 (PST)
Received: from mtaout-mba01.mx.aol.com (mtaout-mba01.mx.aol.com [172.26.133.109]) by omr-m007e.mx.aol.com (Outbound Mail Relay) with ESMTP id 976A6380011C; Thu, 25 Feb 2016 10:27:44 -0500 (EST)
Received: from [10.172.228.63] (unknown [10.172.228.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mba01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8C509380000B6; Thu, 25 Feb 2016 10:27:43 -0500 (EST)
To: Vladimir Dzhuvinov , oauth@ietf.org
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56CF1D79.1070507@aol.com>
Date: Thu, 25 Feb 2016 10:27:53 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56CF1CEB.8030603@aol.com>
Content-Type: multipart/alternative; boundary="------------010405060500030709010907"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456414064; bh=RorTabBP+YbjZkJ6oLzt75T/4fQdnd6ko5COmBGDksI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=cGrjW4pWqDWGohndX/+Uaf4BUQQRH9L4zNbyBJk64RkaIyuxlgcE3XjYn08UZV9sP Uj3twYK3v/KBa+VDk1HvFaIcKki471IX0DxfyM1IWCQJOWXOb51XdQQG3MDnIZJZxA 6Qc/8Um91BbLZLBJxOkuh56WtfnZz/3SwPtNUtlc=
x-aol-sid: 3039ac1a856d56cf1d6f516e
X-AOL-IP: 10.172.228.63
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 15:27:47 -0000

This is a multi-part message in MIME format.
--------------010405060500030709010907
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

That said, I'm not against the AS informing the client that the token 
can be used at the MailResource, ContactResource and MessagingResource 
to help the client know not to send the token to a BlogResource. 
However, identifying the actual endpoint seems overly complex when what 
is really trying to be protected is a token from being used where it 
shouldn't be (which is solved by Pop)

Thanks,
George

On 2/25/16 10:25 AM, George Fletcher wrote:
> Interesting... this is not at all my current experience:) If a RS goes 
> from v2 of it's API to v3 and that RS uses the current standard of 
> putting a "v2" or"v3" in it's API path... then a token issued for v2 
> of the API can not be sent to v3 of the API, because v3 wasn't wasn't 
> registered/deployed when the token was issued.
>
> The constant management of scopes to URI endpoints seems like a 
> complexity that will quickly get out of hand.
>
> Thanks,
> George
>
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>
>>
>> On 25/02/16 09:02, Manger, James wrote:
>>>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>>> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>>
>>> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri†(resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>> +1
>>
>> This will appear more consistent with the current experience, and 
>> OAuth does allow the token response JSON object to be extended with 
>> additional members (as it's done in OpenID Connect already).
>>
>> Cheers,
>> Vladimir
>>
>>> --
>>> James Manger
>>>
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
>>> Sent: Thursday, 25 February 2016 6:17 AM
>>> To: Phil Hunt; Nat Sakimura
>>> Cc:  
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>>
>>> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>>
>>> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>>
>>> Thanks,
>>> George
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------010405060500030709010907
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    That said, I'm not against the AS informing the client that the
    token can be used at the MailResource, ContactResource and
    MessagingResource to help the client know not to send the token to a
    BlogResource. However, identifying the actual endpoint seems overly
    complex when what is really trying to be protected is a token from
    being used where it shouldn't be (which is solved by Pop)

    

    Thanks,

    George

    

    
On 2/25/16 10:25 AM, George Fletcher
      wrote:

    

    

      
      Interesting... this is
        not at all my current experience:) If a RS goes from v2 of it's
        API to v3 and that RS uses the current standard of putting a
        "v2" or"v3" in it's API path... then a token issued for v2 of
        the API can not be sent to v3 of the API, because v3 wasn't
        wasn't registered/deployed when the token was issued. 

        

        The constant management of scopes to URI endpoints seems like a
        complexity that will quickly get out of hand.

        

        Thanks,

        George

      

      
On 2/25/16 2:22 AM, Vladimir
        Dzhuvinov wrote:

      

      

        
        

        

        
On 25/02/16 09:02, Manger, James
          wrote:

        

        

          

            
I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture


          

          
The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri†(resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.

        

        +1 

        

        This will appear more consistent with the current experience,
        and OAuth does allow the token response JSON object to be
        extended with additional members (as it's done in OpenID Connect
        already).

        

        Cheers,

        Vladimir

        

        

          
--
James Manger

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.

Thanks,
George


          

          

          

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


        

        

        

        

        

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


      

      

      

      

      

      

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


    

    

  


--------------010405060500030709010907--


From nobody Thu Feb 25 07:52:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CFD1B2B3B for ; Thu, 25 Feb 2016 07:52:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7v_D5A7lvQf for ; Thu, 25 Feb 2016 07:52:11 -0800 (PST)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578581B2B07 for ; Thu, 25 Feb 2016 07:52:11 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-04.prod.phx3.secureserver.net with  id Nfs91s00215ZTut01fsAhD; Thu, 25 Feb 2016 08:52:10 -0700
To: oauth@ietf.org
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com>
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56CF2328.5030500@connect2id.com>
Date: Thu, 25 Feb 2016 17:52:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CF1D79.1070507@aol.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050505000803010908040903"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 15:52:13 -0000

This is a cryptographically signed message in MIME format.

--------------ms050505000803010908040903
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I made a mistake in my response (good to never rush things :)

My +1 was for moving the suggested metadata params from the "Link"
header to the JSON object that represents the token response. Because in
there we already have the token itself and associated metadata
(expiration and scope).

I still haven't made up my mind about the spec as a whole though.

On 25/02/16 17:27, George Fletcher wrote:
> That said, I'm not against the AS informing the client that the token
> can be used at the MailResource, ContactResource and MessagingResource
> to help the client know not to send the token to a BlogResource.
> However, identifying the actual endpoint seems overly complex when
> what is really trying to be protected is a token from being used where
> it shouldn't be (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>> Interesting... this is not at all my current experience:) If a RS
>> goes from v2 of it's API to v3 and that RS uses the current standard
>> of putting a "v2" or"v3" in it's API path... then a token issued for
>> v2 of the API can not be sent to v3 of the API, because v3 wasn't
>> wasn't registered/deployed when the token was issued.
>>
>> The constant management of scopes to URI endpoints seems like a
>> complexity that will quickly get out of hand.
>>
>> Thanks,
>> George
>>
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>>
>>>
>>> On 25/02/16 09:02, Manger, James wrote:
>>>>> I'm concerned that forcing the AS to know about all RS's endpoints
>>>>> that will accept it's tokens creates a very brittle deployment
>>>>> architecture
>>>> The AS is issuing temporary credentials (access_tokens) to clients
>>>> but doesn=E2=80=99t know where those credentials will work? That=E2=80=
=99s broken.
>>>>
>>>> An AS should absolutely indicate where an access_token can be used.
>>>> draft-sakimura-oauth-meta suggests indicating this with 1 or more
>>>> =E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header.=
 A better
>>>> approach would be including a list of web origins in the token
>>>> response beside the access_token field.
>>> +1
>>>
>>> This will appear more consistent with the current experience, and
>>> OAuth does allow the token response JSON object to be extended with
>>> additional members (as it's done in OpenID Connect already).
>>>
>>> Cheers,
>>> Vladimir
>>>
>>>> --=20
>>>> James Manger
>>>>
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George
>>>> Fletcher
>>>> Sent: Thursday, 25 February 2016 6:17 AM
>>>> To: Phil Hunt; Nat Sakimura
>>>> Cc:  
>>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>>
>>>> I'm concerned that forcing the AS to know about all RS's endpoints
>>>> that will accept it's tokens creates a very brittle deployment
>>>> architecture. What if a RS moves to a new endpoint? All clients
>>>> would be required to get new tokens (if I understand correctly).
>>>> And the RS move would have to coordinate with the AS to make sure
>>>> all the timing is perfect in the switch over of endpoints.
>>>>
>>>> I suspect a common deployment architecture today is that each RS
>>>> requires one or more scopes to access it's resources. The client
>>>> then asks the user to authorize a token with a requested list of
>>>> scopes. The client can then send the token to the appropriate RS
>>>> endpoint. The RS will not authorize access unless the token has the
>>>> required scopes.
>>>>
>>>> If the concern is that the client may accidentally send the token
>>>> to a "bad" RS which will then replay the token, then I'd rather use
>>>> a PoP mechanism because the point is that you want to ensure the
>>>> correct client is presenting the token. Trying to ensure the client
>>>> doesn't send the token to the wrong endpoint seems fraught with
>>>> problems.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>



--------------ms050505000803010908040903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjUxNTUyMDhaMC8GCSqGSIb3DQEJBDEiBCC1DwZAHNq2NwpTKrO8YUDyiCbJ0At6
g6O7FYdoQWxhITBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQB8KpCyhH+H
+AgTAEyQryOfTBvyZ6q97Uz1i1pOzl6a2NTQXr+0Qt50h75qd7/UT0NoclnAqtrtE/OiEV28
IQ8X8u1Un2kPa2IkLIsA6x8O+mouFEAoIW1V2prAHREnXthzgaKVfrH6BfBuzl2f+qAeqPGb
xGsjLuPwCls3U7hL7qDf3QvDOQO+QYZfGSlbS0o6iyglRV3nEHdWHkssKglhG7NwmFibdYE8
9HW4qVF3zwPkEGdXhP8wGgh33tEyadnkfV0KGedINia9+R1rRrxgn7cDldywCTTdpWXnhd2r
GhZSJmJxgG70HPiJs1OtuirjMFOw/byW8KVruVwFtWhNAAAAAAAA
--------------ms050505000803010908040903--


From nobody Thu Feb 25 08:00:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37871B2BD1 for ; Thu, 25 Feb 2016 08:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level: 
X-Spam-Status: No, score=-1.656 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 WG3M-gtbFgaW for ; Thu, 25 Feb 2016 08:00:25 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id D6FE21B2B8B for ; Thu, 25 Feb 2016 08:00:17 -0800 (PST)
Received: (qmail 8323 invoked by uid 0); 25 Feb 2016 16:00:17 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 25 Feb 2016 16:00:17 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with  id Ng081s01A2is6CS01g0Bdd; Thu, 25 Feb 2016 09:00:15 -0700
X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=rE68L1KyjUoA:10 a=zwqKzj3qmOAA:10 a=jFJIQSaiL_oA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=ltxWCLULAAAA:8 a=lMGwIrbWAAAA:8 a=ZeOuHos7AAAA:8 a=UGkfVyPCAAAA:8 a=pGLkceISAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8 a=zDRtsbTxj6EWpDovZnQA:9 a=VXlICBlxRRo6oTjr:21 a=cxPuIWkRSe62yl-k:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=0y4QJ6oqqkIA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Kk4do6bY5ODKTUgZ8doA:9 a=wBXmA1PrY2QCadme:21 a=zvOkkUvulv5JAng0:21 a=bgFutV5mEhZ3lm_W:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=gtB9T/7LNlMsMr7K/eatLUDoOx7UiJL0ZHfycTP1Jio=;  b=bM3M9YyuMWsioNeNTScBHOM0DsfWqHkqoH5ivHNhspAklEmyOmJQchybvG22evSgpHmMp3hc+SdZ2dcEdeuC22vzgT2sRryOTE0pQh4f2jhAOcfrZE/BV7VNQlvEwZig;
Received: from [162.206.229.38] (port=3634 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1aYyKo-00020J-23; Thu, 25 Feb 2016 09:00:10 -0700
From: "Donald F. Coffin" 
To: "'Nat Sakimura'" , "'Vladimir Dzhuvinov'" , 
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <005801d16fd5$37557680$a6006380$@reminetworks.com> 
In-Reply-To: 
Date: Thu, 25 Feb 2016 10:57:58 -0500
Organization: REMI Networks
Message-ID: <00ac01d16fe5$4e1555b0$ea400110$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01D16FBB.65412270"
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQErEGUxIthpCNQAgVnbL+9JTvjuPAKQYZUXAMzfEkkBvAxTnwHmAZgaAtiXPCUBaONgBwGrEpF8AmD4XBKgD0EfIA==
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 162.206.229.38 authed with donald.coffin@reminetworks.com}
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 16:00:28 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00AD_01D16FBB.65412270
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nat,

=20

The information that will be used to update the NAESB REQ.21 Standard =
can be found at http://greenbuttondata.org.  The document that defines =
the Authorization requirements is referenced as the =E2=80=9CGreenButton =
Implementation Agreement =
 =E2=80=9D.   The current NAESB REQ.21 Standard is =
available on the NAESB Website, but is a copyrighted standard and cost =
$250.00.  However, NAESB does provide the standard for evaluation =
purposes, by contacting the NAESB office at naesb@naesb.org =
 .

=20

The Green Button website is the technical repository for the Green =
Button initiative.  Therefore, there are several technical documents and =
videos available.  Let me know if you need help finding anything.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Nat Sakimura [mailto:sakimura@gmail.com]=20
Sent: Thursday, February 25, 2016 10:17 AM
To: Donald F. Coffin ; Vladimir =
Dzhuvinov ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

=20

Interesting. Is there a link that I can download your spec etc. ?=20

=20

I have not much preference over the actual endpoint link or the web =
origin. As long as the semantics is clear, either is fine.=20

I was even considering using URI template. It will be extremely =
flexible, but I am not sure about the current status of the library =
availability and its qualities.=20

=20

Re: RFC5988 header or JSON - If you go back to earlier drafts, I was =
using JSON. This will make it independent of HTTPS.=20

Also, developers can just process the JSON and store it in JSON. This is =
a overall win.=20

Downside is that there is no standard for doing JSON metadata. Since =
Swagger is using JSON Schema way of expressing it, perhaps that's the =
way we should go, though, HAL seems to be a bit more efficient and nice. =


=20

In either way, though, IMHO, it is important to define the link relation =
in the RFC5988 IANA registry.=20

Converting RFC5988 link header to either JSON schema metadata or HAL is =
trivial.=20

=20

Nat

=20

=20

2016=E5=B9=B42=E6=9C=8825=E6=97=A5(=E6=9C=A8) 23:05 Donald F. Coffin =
 =
>:

In fact, this is the method being used by utilities implementing the =
Green Button Connect My Data interface (North American Energy Standards =
Boards=E2=80=99 (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard =
(Energy Service Provider Interface =E2=80=93 ESPI).  The Green Button =
Alliance is in the processing of updating the specification to use OAuth =
2.0.  The industry OpenADE Task Force, which is the technical WG of the =
UCAIug, defined additional information be returned with the OAuth 2.0  =
Token Response that includes the URI of the resource to which the AT can =
be used.

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Vladimir Dzhuvinov [mailto:vladimir@connect2id.com =
 ]=20
Sent: Thursday, February 25, 2016 2:23 AM
To: oauth@ietf.org =20


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

=20

=20

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that =
will accept it's tokens creates a very brittle deployment architecture

=20
The AS is issuing temporary credentials (access_tokens) to clients but =
doesn=E2=80=99t know where those credentials will work? That=E2=80=99s =
broken.
=20
An AS should absolutely indicate where an access_token can be used. =
draft-sakimura-oauth-meta suggests indicating this with 1 or more =
=E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.

+1=20

This will appear more consistent with the current experience, and OAuth =
does allow the token response JSON object to be extended with additional =
members (as it's done in OpenID Connect already).

Cheers,
Vladimir



--
James Manger
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt   ; Nat =
Sakimura   
Cc:      =

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
I'm concerned that forcing the AS to know about all RS's endpoints that =
will accept it's tokens creates a very brittle deployment architecture. =
What if a RS moves to a new endpoint? All clients would be required to =
get new tokens (if I understand correctly). And the RS move would have =
to coordinate with the AS to make sure all the timing is perfect in the =
switch over of endpoints.
=20
I suspect a common deployment architecture today is that each RS =
requires one or more scopes to access it's resources. The client then =
asks the user to authorize a token with a requested list of scopes. The =
client can then send the token to the appropriate RS endpoint. The RS =
will not authorize access unless the token has the required scopes.
=20
If the concern is that the client may accidentally send the token to a =
"bad" RS which will then replay the token, then I'd rather use a PoP =
mechanism because the point is that you want to ensure the correct =
client is presenting the token. Trying to ensure the client doesn't send =
the token to the wrong endpoint seems fraught with problems.
=20
Thanks,
George





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

=20

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


------=_NextPart_000_00AD_01D16FBB.65412270
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nat,
 
The =
information that will be used to update the NAESB REQ.21 Standard can be =
found at http://greenbuttondata.org. =
=C2=A0The document that defines the Authorization requirements is =
referenced as the =E2=80=9CGreenButton Implementation Agreement=E2=80=9D. =
=C2=A0=C2=A0The current NAESB REQ.21 Standard is available on the NAESB =
Website, but is a copyrighted standard and cost $250.00.=C2=A0 However, =
NAESB does provide the standard for evaluation purposes, by contacting =
the NAESB office at naesb@naesb.org.
 
The Green =
Button website is the technical repository for the Green Button =
initiative.=C2=A0 Therefore, there are several technical documents and =
videos available.=C2=A0 Let me know if you need help finding =
anything.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO<=
/p>
 
REMI =
Networks
2335 Dunwoody Xing =
#E
Dunwoody, GA =
30338-8221
 
Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com
 
From:<=
/b> =
Nat Sakimura [mailto:sakimura@gmail.com] 
Sent: Thursday, =
February 25, 2016 10:17 AM
To: Donald F. Coffin =
<donald.coffin@reminetworks.com>; Vladimir Dzhuvinov =
<vladimir@connect2id.com>; oauth@ietf.org
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Interesting. Is there a link that I can download your =
spec etc. ? 
 
I =
have not much preference over the actual endpoint link or the web =
origin. As long as the semantics is clear, either is =
fine. 
I was even =
considering using URI template. It will be extremely flexible, but I am =
not sure about the current status of the library availability and its =
qualities. 
 
Re: RFC5988 header or JSON - If you go back to earlier =
drafts, I was using JSON. This will make it independent of =
HTTPS. 
Also, =
developers can just process the JSON and store it in JSON. This is a =
overall win. 
Downside is that there is no standard for doing JSON =
metadata. Since Swagger is using JSON Schema way of expressing it, =
perhaps that's the way we should go, though, HAL seems to be a bit more =
efficient and nice. 
 
In either way, though, IMHO, it is important to define =
the link relation in the RFC5988 IANA =
registry. 
Converting =
RFC5988 link header to either JSON schema metadata or HAL is =
trivial. 
 
Nat
 
 
2016=E5=B9=B42=E6=9C=8825=E6=97=A5(=E6=9C=A8) 23:05 =
Donald F. Coffin <donald.coffin@reminetworks=
.com>:
In fact, this is the method being =
used by utilities implementing the Green Button Connect My Data =
interface (North American Energy Standards Boards=E2=80=99 (NAESB) =
Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider =
Interface =E2=80=93 ESPI).  The Green Button Alliance is in the =
processing of updating the specification to use OAuth 2.0.  The =
industry OpenADE Task Force, which is the technical WG of the UCAIug, =
defined additional information be returned with the OAuth 2.0 =
 Token Response that includes the URI of the resource to which the =
AT can be used.
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO<=
/p>
 
REMI =
Networks
2335 Dunwoody Xing =
#E
Dunwoody, GA =
30338-8221
 
Phone:    =
  (949) 636-8571
Email:    =
   donald.coffin@reminetworks.com<=
o:p>
 
From:<=
/b> =
Vladimir Dzhuvinov [mailto:vladimir@connect2id.com] 
Sent: =
Thursday, February 25, 2016 2:23 AM
To: oauth@ietf.org

Subjec=
t: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 <=
/o:p>
 <=
/p>
On 25/02/16 =
09:02, Manger, James wrote:
I'm concerned that =
forcing the AS to know about all RS's endpoints that will accept it's =
tokens creates a very brittle deployment =
architecture
 
The AS is issuing temporary credentials (access_tokens) to clients but =
doesn=E2=80=99t know where those credentials will work? That=E2=80=99s =
broken.
 
An AS should =
absolutely indicate where an access_token can be used. =
draft-sakimura-oauth-meta suggests indicating this with 1 or more =
=E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.
+1 

This =
will appear more consistent with the current experience, and OAuth does =
allow the token response JSON object to be extended with additional =
members (as it's done in OpenID Connect =
already).

Cheers,
Vladimir

--
James Manger
 
From: =
OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George =
Fletcher
Sent: Thursday, 25 February 2016 6:17 =
AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>
Cc:=
 <oauth@ietf.org> <oauth@ietf.org>
Subject=
: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
I'm concerned =
that forcing the AS to know about all RS's endpoints that will accept =
it's tokens creates a very brittle deployment architecture. What if a RS =
moves to a new endpoint? All clients would be required to get new tokens =
(if I understand correctly). And the RS move would have to coordinate =
with the AS to make sure all the timing is perfect in the switch over of =
endpoints.
 
I suspect a =
common deployment architecture today is that each RS requires one or =
more scopes to access it's resources. The client then asks the user to =
authorize a token with a requested list of scopes. The client can then =
send the token to the appropriate RS endpoint. The RS will not authorize =
access unless the token has the required =
scopes.
 
If the concern =
is that the client may accidentally send the token to a "bad" =
RS which will then replay the token, then I'd rather use a PoP mechanism =
because the point is that you want to ensure the correct client is =
presenting the token. Trying to ensure the client doesn't send the token =
to the wrong endpoint seems fraught with =
problems.
 
Thanks,
George


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

------=_NextPart_000_00AD_01D16FBB.65412270--


From nobody Thu Feb 25 09:08:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51DE1B2E2F for ; Thu, 25 Feb 2016 09:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0AOjBxh2GzH for ; Thu, 25 Feb 2016 09:08:51 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 296541B2E32 for ; Thu, 25 Feb 2016 09:08:49 -0800 (PST)
Received: by mail-lb0-x236.google.com with SMTP id bc4so32649407lbc.2 for ; Thu, 25 Feb 2016 09:08:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=4DbO5UuNjNSamPRzMyPGj+zG+P83TPGsHwq7lBVX3co=; b=iTtM88Z/0kryaXNWMnq9ZK2JAmllEavBJTNC0InL71yKGLflDcR257OQYEwT7oly5X tVejY7qR8luCleBnzakk4HVrwkrPG7ZVxYmh1pjK743qMkvaOWhArL+ZvQHsclOegSVe ENOsMkTEACeCcUhnEqTaGuMFkZtuEwgYDU18cjAvV6PbUdWoVhfwavddvzaEXhwVEPUJ EBolif0WzWbxdXvBuGhD+3oTeVXuVWjEgWlYiinwGlPN+8e5lqQMFGkGf2YLwMirSHC8 ydkHz7z0+1R/rFNpPDvLdEoIh6vEhRwG3Cat+H8IdzwzapH0V1J91Or86/MaAWsTFRFc VUuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=4DbO5UuNjNSamPRzMyPGj+zG+P83TPGsHwq7lBVX3co=; b=geFXe7xQGAl/R2O7fJGBTLnayh5G5GQs82ds1P+S9ykqm5toQp204YwHsAeYjE6ERQ LavCaXDWvaLtiiIdOcZmzpRCGrlR9M24au4HyWtTST6qXifwZTVMDsOAA7prsq89AaUK U615i4nWlzS+vxCUZSzlQR/eW27C5KodOvy1Y3cLwajkIRiCYj/O2oCyq5nCEOp2id1b 4Wx6KyQOI4QowIbE1v5cFfb1WWTRNkhVHbRaopFIgX/sLe1+q9NZhUHJw69kxkkD+cSH OgHzTaKWjElB60urN8Lt2gL3T8X4mHWpKSlpRVwqFbWDSKZL+NiB6fnW4QcA6bJTxkhL Ap9w==
X-Gm-Message-State: AG10YORh8UVpGy5s+b8ITjbn5He9T69jaiL+Qs/CaKXCdECfhwd5ufJ6ZOZXB0GTkJ5XYJlv1Wx7XufQ27r8dA==
X-Received: by 10.112.211.168 with SMTP id nd8mr17029282lbc.116.1456420126996;  Thu, 25 Feb 2016 09:08:46 -0800 (PST)
MIME-Version: 1.0
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com>
In-Reply-To: <56CF1CEB.8030603@aol.com>
From: Thomas Broyer 
Date: Thu, 25 Feb 2016 17:08:36 +0000
Message-ID: 
To: George Fletcher , Vladimir Dzhuvinov , oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a11c3bc4e503e2c052c9b3c73
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 17:08:57 -0000

--001a11c3bc4e503e2c052c9b3c73
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher  wrote:

> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of puttin=
g
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API c=
an
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deploye=
d
> when the token was issued.
>

Add to that:

   - "restful" APIs have a lot of "endpoints" related to a single scope
   - I know at least one AS that doesn't require RSs to register (I wonder
   how it all works, and whether it's really secure =E2=80=93I hope so, giv=
en the
   known RSs=E2=80=93, but that's how it is): documentation can be found (i=
n French)
   at https://doc.integ01.dev-franceconnect.fr/ (or
   https://integ01.dev-franceconnect.fr/ if the previous URL doesn't work
   for you, they have DNS configuration issues)
   - even UMA doesn't register "resources" themselves, but only "resource
   sets", and it doesn't even require a) an URI for the resource set, or b)
   any "relationship" between the resource set URI (if any) and the URIs of
   the resources "in" the resource set:
   https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.htm=
l



> The constant management of scopes to URI endpoints seems like a complexit=
y
> that will quickly get out of hand.
>

+1

--001a11c3bc4e503e2c052c9b3c73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu=
, Feb 25, 2016 at 4:25 PM George Fletcher <gffletch@aol.com> wrote:

 =20
   =20
 =20
  

    Interesting... this is not
      at all my current experience:) If a RS goes from v2 of it's API t=
o
      v3 and that RS uses the current standard of putting a "v2" =
or"v3"
      in it's API path... then a token issued for v2 of the API can not
      be sent to v3 of the API, because v3 wasn't wasn't registered=
/deployed
      when the token was issued. 

Add to that:
  • "restful" APIs have a lot =
of "endpoints" related to a single scope
  • I know at least =
one AS that doesn't require RSs to register (I wonder how it all works,=
 and whether it's really secure =E2=80=93I hope so, given the known RSs=
=E2=80=93, but that's how it is): documentation can be found (in French=
) at https://doc.inte=
g01.dev-franceconnect.fr/=C2=A0(or=C2=A0https://integ01.dev-franceconnect.fr/=C2=A0if the pr=
evious URL doesn't work for you, they have DNS configuration issues)
  • even UMA doesn't register "resources" themselves, but o=
nly "resource sets", and it doesn't even require a) an URI fo=
r the resource set, or b) any "relationship" between the resource=
 set URI (if any) and the URIs of the resources "in" the resource=
 set: https://docs.kantarainitiative.org/uma/rec-oauth-resource-=
reg-v1_0_1.html
=C2=A0

      The constant management of scopes to URI endpoints seems like a
      complexity that will quickly get out of hand.

+1


--001a11c3bc4e503e2c052c9b3c73--


From nobody Thu Feb 25 11:10:27 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF501B31BE for ; Thu, 25 Feb 2016 11:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UchgN1MMBJjO for ; Thu, 25 Feb 2016 11:10:19 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE69C1B31CA for ; Thu, 25 Feb 2016 11:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4cZKPd/6WnWSJWSZ2WtL9ueMtkhNt44PL/Xr6feSlgk=; b=KG1y9EJ0qFKv7r1YXaqyTgzwhh+BUKH+OetbhqWLIznFam7QbrU++NljvLro+60C8gAddGhvzIIOXPyk1DRS5bOPcIh2ViVMK3/VjZS3OjUxU7jmUrdFPgy6nOVzy41t9tq8PgFzCy2RshDuCfAGTGrnkWxfAUrGZHAZSNbFTZ0=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 25 Feb 2016 19:10:16 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Thu, 25 Feb 2016 19:10:16 +0000
From: Mike Jones 
To: Vladimir Dzhuvinov , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKwgAAD14CAABMcsIAACLCAgAAAzOCAAAh3AIAAj3QAgACntWA=
Date: Thu, 25 Feb 2016 19:10:16 +0000
Message-ID: 
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>
In-Reply-To: <56CEC24C.8040709@connect2id.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: connect2id.com; dkim=none (message not signed) header.d=none;connect2id.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: cdbd4263-0952-4518-524a-08d33e174bac
x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:yVZkQNSDCVEdVE05ZZZvux7Ii7JnFn/TRSeVhVYgBZ1ZIV54KfTzacAlNYuIyeuOLmQXI9d5/NGTKu4eKGElHE8PnW+GqNqfRG8zIBny6WGcqIJN5D4UwCMWVQDppYgDtTN0TyEvqX7p/KMgiTKYIQ==; 24:HirJ83Z0rYWTkuOq0E1+U/jHIDNLoxAWqYp9ELwlVqr/7Zgx3BeiUXZCt/xNKHbcqIIfmLB3pfMsNw62LfClsgHeNZGZg5HJC4jsLkKCoMU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(169139582196971);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; 
x-forefront-prvs: 08635C03D4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(24454002)(377454003)(87936001)(76576001)(93886004)(122556002)(10090500001)(86612001)(50986999)(3660700001)(54356999)(76176999)(40100003)(189998001)(86362001)(11100500001)(106116001)(99286002)(8990500004)(10400500002)(19617315012)(10290500002)(66066001)(74316001)(5004730100002)(5008740100001)(102836003)(16236675004)(586003)(15395725005)(92566002)(1220700001)(19625215002)(33656002)(3846002)(1096002)(790700001)(3280700002)(1680700002)(107886002)(19580395003)(5001770100001)(77096005)(15975445007)(2501003)(16601075003)(5002640100001)(2900100001)(2950100001)(19300405004)(2906002)(5001960100002)(19580405001)(3900700001)(5005710100001)(184035003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4425461F4C68FAAABC422BDF5A60BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2016 19:10:16.2251 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 19:10:26 -0000

--_000_BY2PR03MB4425461F4C68FAAABC422BDF5A60BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIGZvciB5b3VyIHRob3VnaHRzLCBWbGFkaW1pci4gIEnigJltIGluY3JlYXNpbmdseSBp
bmNsaW5lZCB0byBhY2NlcHQgeW91ciBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgdGl0bGUgZnJv
bSDigJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9u
IFNlcnZlciBEaXNjb3ZlcnnigJ0uICBXaGlsZSB0aGUgYWJzdHJhY3QgYWxyZWFkeSBtYWtlcyBp
dCBjbGVhciB0aGF0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgQVMgZGlzY292ZXJ5LCBk
b2luZyBzbyBpbiB0aGUgdGl0bGUgc2VlbXMgbGlrZSBpdCBjb3VsZCBoZWxwIGNsYXJpZnkgdGhp
bmdzLCBnaXZlbiB0aGF0IGEgbG90IG9mIHRoZSBkaXNjdXNzaW9uIHNlZW1zIHRvIGJlIGFib3V0
IHJlc291cmNlIGRpc2NvdmVyeSwgd2hpY2ggaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBkb2N1bWVu
dC4NCg0KSeKAmW0gbm90IHNheWluZyB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBpc27igJl0IGlt
cG9ydGFudCDigJMgaXQgaXMg4oCTIGJ1dCB1bmxpa2UgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlz
Y292ZXJ5LCB3aGVyZSB0aGVyZeKAmXMgbG90cyBvZiBleGlzdGluZyBwcmFjdGljZSwgaW5jbHVk
aW5nIHVzaW5nIHRoZSBleGlzdGluZyBkYXRhIGZvcm1hdCBmb3IgZGVzY3JpYmluZyBPQXV0aCBp
bXBsZW1lbnRhdGlvbnMgdGhhdCBhcmVu4oCZdCBiZWluZyB1c2VkIHdpdGggT3BlbklEIENvbm5l
Y3QsIHRoZXJl4oCZcyBubyBleGlzdGluZyBwcmFjdGljZSB0byBzdGFuZGFyZGl6ZSBmb3IgcmVz
b3VyY2UgZGlzY292ZXJ5LiAgVGhlIHRpbWUgdG8gY3JlYXRlIGEgc3RhbmRhcmQgZm9yIHRoYXQg
c2VlbXMgdG8gYmUgYWZ0ZXIgZXhpc3RpbmcgcHJhY3RpY2UgaGFzIGVtZXJnZWQuICBJdCAqbWln
aHQqIG9yIG1pZ2h0IG5vdCB1c2UgbmV3IG1ldGFkYXRhIHZhbHVlcyBpbiB0aGUgQVMgZGlzY292
ZXJ5IGRvY3VtZW50LCBidXQgdGhhdOKAmXMgc3RpbGwgdG8gYmUgZGV0ZXJtaW5lZC4gIFRoZSBv
bmUgcmVhc29uIHRvIGxlYXZlIHRoZSB0aXRsZSBhcy1pcyBpcyB0aGF0IHJlc291cmNlIGRpc2Nv
dmVyeSBtaWdodCBlbmQgdXAgaW52b2x2aW5nIGV4dGVuc2lvbnMgdG8gdGhpcyBtZXRhZGF0YSBm
b3JtYXQgaW4gc29tZSBjYXNlcy4NCg0KSSB0aGluayBhbiBhbmFsb2d5IHRvIHRoZSBjb3JlIE9B
dXRoIGRvY3VtZW50cyBSRkMgNjc0OSBhbmQgUkZDIDY3NTAgYXBwbGllcy4gIDY3NDkgaXMgYWJv
dXQgdGhlIEFTLiAgNjc1MCBpcyBhYm91dCB0aGUgUlMuICBUaGUgZGlzY292ZXJ5IGRvY3VtZW50
IGlzIGFib3V0IHRoZSBBUy4gIFdlIGRvbuKAmXQgeWV0IGhhdmUgYSBzcGVjaWZpY2F0aW9uIG9y
IGV4aXN0aW5nIHByYWN0aWNlIGZvciBSUyBkaXNjb3ZlcnksIHdoaWNoIHdvdWxkIGJlIHRoZSA2
NzUwIGFuYWxvZ3kuDQoNCkluIHN1bW1hcnksIHdoaWNoIHRpdGxlIGRvIHBlb3BsZSBwcmVmZXI/
DQoNCsK3ICAgICAgIOKAnE9BdXRoIDIuMCBEaXNjb3ZlcnnigJ0NCg0KwrcgICAgICAg4oCcT0F1
dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeeKAnQ0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG
cm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBW
bGFkaW1pciBEemh1dmlub3YNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNSwgMjAxNiAxMjo1
OSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAy
LjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCkluIE9JREMgdGhlIGRpc2NvdmVyeSBkb2MgaXMgb2Yg
Z3JlYXQgdXRpbGl0eSB0byBkZXZlbG9wZXJzIGFuZCBpbnRlZ3JhdG9ycy4gRGV2ZWxvcGVycyBh
bHNvIHRlbmQgdG8gZmluZCBpdCBhIG1vcmUgYWNjdXJhdGUgYW5kIGNvbXBsZXRlIGRlc2NyaXB0
aW9uIG9mIGhvdyB0byBzZXQgdXAgYSBjbGllbnQgZm9yIGEgcGFydGljdWxhciBkZXBsb3ltZW50
LCBjb21wYXJlZCB0byB0cmFkaXRpb25hbCBvbmxpbmUgZG9jcywgd2hpY2ggbWF5IGJlIG5vdCBi
ZSB1cCB0byBkYXRlLCBvciBldmVuIG1pc3NpbmcuIFZlcnkgbXVjaCBsaWtlIGF1dG8tZ2VuZXJh
dGVkIFN3YWdnZXIgYW5kIEphdmFEb2NzLg0KDQpIZXJlIGFyZSBzb21lIGV4YW1wbGUgT0lEQyBk
aXNjb3ZlcnkgZG9jczoNCg0KaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxsLWtub3du
L29wZW5pZC1jb25maWd1cmF0aW9uDQoNCmh0dHBzOi8vd3d3LnBheXBhbG9iamVjdHMuY29tLy53
ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uDQoNCmh0dHBzOi8vbG9naW4ubWljcm9zb2Z0
b25saW5lLmNvbS9mYWJyaWthbWIyYy5vbm1pY3Jvc29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9v
cGVuaWQtY29uZmlndXJhdGlvbg0KDQoNCldpdGggdGhpcyBkaXNjb3ZlcnkgZG9jdW1lbnQgaW4g
cGxhY2Ugc2V0dXAgb2YgaWRlbnRpdHkgZmVkZXJhdGlvbiBjYW4gdGhlbiBiZSBlYXNpbHkgc2Ny
aXB0ZWQuIEZvciBleGFtcGxlOg0KDQpodHRwOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9JQU0vbGF0
ZXN0L1VzZXJHdWlkZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5LXRodW1i
cHJpbnQuaHRtbA0KDQoNCk5vdywgZG9lcyB0aGF0IGRpY3RhdGUgYW55IHBhcnRpY3VsYXIgYXBw
IGFyY2hpdGVjdHVyZT8gTXkgcmVhZGluZyBvZiB0aGUgc3BlYyBpcyB0aGF0IGl0IGRvZXNuJ3Qs
IGFuZCBpdCBzaG91bGRuJ3QgZWl0aGVyLiBCeSBzdGF5aW5nIG5ldXRyYWwgb24gdGhlIHRvcGlj
cyBvZiBSUyBkaXNjb3ZlcnkgYW5kIHJlZ2lzdGVyaW5nIFJQcyB3aXRoIFJTcy4gQW5kIGhvdyBv
bmUgYXJyaXZlcyBhdCB0aGUgIi53ZWxsLWtub3duLy4uLiIuIEknbSBub3QgZXZlbiBzdXJlIHRo
YXQgcmVzb3VyY2UgZGlzY292ZXJ5IHNob3VsZCBiZSBhIHRvcGljIG9mIHRoaXMgV0cuIFBlcmhh
cHMgdG8gdGhpcyBlbmQsIGFuZCB0byBwcmV2ZW50IGNvbmZ1c2lvbiB0aGF0IHRoZSBzcGVjIGlz
IHRyeWluZyB0byBkbyBzb21ldGhpbmcgbW9yZSwgYSBtb3JlIHNwZWNpZmljIHRpdGxlIHdvdWxk
IHN1aXQgaXQgYmV0dGVyLiBFLmcuICJBUyBEaXNjb3ZlcnkiLg0KDQpDaGVlcnMsDQoNClZsYWRp
bWlyDQoNCg0KDQpPbiAyNS8wMi8xNiAwMjoyNSwgUGhpbCBIdW50IChJRE0pIHdyb3RlOg0KDQpB
bmQgc28gZG9lcyBvcmFjbGUgYW5kIHNvIGRvZXMgZ29vZ2xlLiBFYWNoIGRpZmZlcmVudC4NCg0K
DQoNClNvIGhvdyBjYW4gYW4gYXBwIGRpY3RhdGUgaXQgdGhlbiB1bmxlc3Mgd2UgYWxsIGdvIHRv
IGEgY29tbW9uIGFyY2hpdGVjdHVyZT8NCg0KDQoNClBoaWwNCg0KDQoNCk9uIEZlYiAyNCwgMjAx
NiwgYXQgMTY6MDQsIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFp
bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCg0KDQpBenVyZSBkZWZp
bmVzIHdheXMgZm9yIHJlc291cmNlIHNlcnZlcnMgdG8gYmUgcmVnaXN0ZXJlZCBmb3IgdXNlIHdp
dGggYSBjbGllbnQgYW5kIGZvciBjbGllbnRzIHRvIGR5bmFtaWNhbGx5IHJlcXVlc3QgYW4gYWNj
ZXNzIHRva2VuIGZvciB1c2UgYXQgYSBwYXJ0aWN1bGFyIHJlc291cmNlIHNlcnZlci4gIFlvdSBj
YW4gY2FsbCB0aGF0IGN1c3RvbSBhcmNoaXRlY3R1cmUgaWYgeW91IHdhbnQuICBJdOKAmXMgd2Vs
bC1kZWZpbmVkIGJ1dCBpdOKAmXMgbm90IGN1cnJlbnRseSBpbiB0aGUgc3RhbmRhcmRzIHJlYWxt
LiAgSSBrbm93IHRoYXQgR29vZ2xlIGhhcyBzeW50YXggZm9yIGRvaW5nIHRoZSBzYW1lLCBhcyBJ
4oCZbSBzdXJlIGRvIGEgbG90IG9mIG90aGVyIGNsb3VkIE9BdXRoIGRlcGxveW1lbnRzLCBzdWNo
IGFzIE9yYWNsZeKAmXMuICBGb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSB3b3JraW5nIGdyb3Vw
IHRhbGtlZCBhYm91dCBwb3NzaWJseSBwcm9kdWNpbmcgYSBzdGFuZGFyZCB2ZXJzaW9uIG9mIHN5
bnRheCBmb3IgbWFraW5nIHRoZXNlIGtpbmRzIG9mIHJlcXVlc3RzIGR1cmluZyBvdXIgZGlzY3Vz
c2lvbnMgaW4gUHJhZ3VlIChkdXJpbmcgdGhlIFRva2VuIEV4Y2hhbmdlIGRpc2N1c3Npb24pIGJ1
dCBub2JvZHkgaGFzIHJ1biB3aXRoIHRoaXMgeWV0Lg0KDQoNCg0KSW4gdGhpcyBzZW5zZSwgeWVz
LCBBenVyZSBpcyBhbiBhcHBsaWNhdGlvbiBvZiB0aGUga2luZCB3ZeKAmXJlIHRhbGtpbmcgYWJv
dXQuICBBenVyZSBhbHJlYWR5IGRvZXMgZGVmaW5lIHNwZWNpZmljIG5ldyBPQXV0aCAyLjAgZGlz
Y292ZXJ5IG1ldGFkYXRhIHZhbHVlcyB0aGF0IGFyZSB1c2VkIGluIHByb2R1Y3Rpb24uICBBIHJl
Z2lzdHJ5IGp1c3QgZG9lc27igJl0IHlldCBleGlzdCBpbiB3aGljaCBpdCBjYW4gcmVnaXN0ZXIg
dGhvc2UgdGhhdCBhcmUgb2YgZ2VuZXJhbCBhcHBsaWNhYmlsaXR5Lg0KDQoNCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t
IE1pa2UNCg0KDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFj
bGUuY29tXQ0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDM6NTIgUE0NCg0K
VG86IE1pa2UgSm9uZXMNCg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYu
b3JnPg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0
aW9uDQoNCg0KDQpNaWtlDQoNCg0KDQpUYWtlIGEgbG9vayBhdCB0aGUgYXNzdW1wdGlvbnMgeW91
IGFyZSBtYWtpbmcuDQoNCg0KDQpZb3Ugc2VlbSB0byBiZSBhc3N1bWluZyBhcHBsaWNhdGlvbiBz
b2Z0d2FyZSBkaWN0YXRlcyBvYXV0aCBpbmZyYXN0cnVjdHVyZSBhcmNoaXRlY3R1cmUgYnkgc3Vn
Z2VzdGluZyB0aGF0IGFwcHMgcmVnaXN0ZXIgaW4gaWFuYS4NCg0KDQoNCldvdWxkIG1zIGF6dXJl
IGFsbG93IGN1c3RvbSBhcmNoPw0KDQoNCg0KUGhpbA0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBh
dCAxNToyOCwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KDQoNClRoZSBVc2VySW5mbyBF
bmRwb2ludCBwYXRoIGlzbuKAmXQgZml4ZWQgYW5kIHNvIGhhcyB0byBiZSBkaXNjb3ZlcmVkLg0K
DQoNCg0KSSBhZ3JlZSB0aGF0IGZvciBzb21lIE9BdXRoIHByb2ZpbGVzLCBvbmUgb3IgbW9yZSBy
ZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSBkaXNjb3ZlcmVkIHN0YXJ0aW5nIGZyb20g
dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgV29ya2luZyBncm91cCBtZW1iZXJzIGhhdmUgYWxz
byBkZXNjcmliZWQgd2FudGluZyB0byBkaXNjb3ZlciBhdXRob3JpemF0aW9uIHNlcnZlcnMgc3Rh
cnRpbmcgZnJvbSByZXNvdXJjZSBzZXJ2ZXJzLiAgVGhlcmUgaXNu4oCZdCBhIHN0YW5kYXJkIHBy
YWN0aWNlIGZvciBhbnkgb2YgdGhpcywgd2hpY2ggaXMgd2h5IGl04oCZcyBpbnRlbnRpb25hbGx5
IGxlZnQgb3V0IG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24uDQoNCg0KDQpPbmNlIHRoZSBJ
QU5BIE9BdXRoIERpc2NvdmVyeSBNZXRhZGF0YSBSZWdpc3RyeSBoYXMgYmVlbiBlc3RhYmxpc2hl
ZCwgd2hpY2ggd2lsbCBoYXBwZW4gYWZ0ZXIgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBoYXMg
YmVlbiBhcHByb3ZlZCwgaXQgd2lsbCBiZSBlYXN5IGZvciBzdWJzZXF1ZW50IHNwZWNpZmljYXRp
b25zIHRvIGRvY3VtZW50IGV4aXN0aW5nIHByYWN0aWNlIGZvciBkaWZmZXJlbnQgT0F1dGggcHJv
ZmlsZXMgYW5kIHJlZ2lzdGVyIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMgc3VwcG9ydGluZyB0
aGVtLiAgU29tZSBvZiB0aG9zZSB2YWx1ZXMgd2lsbCBsaWtlbHkgZGVmaW5lIHdheXMgdG8gZGlz
Y292ZXIgcmVzb3VyY2Ugc2VydmVycywgd2hlbiBhcHBsaWNhYmxlLg0KDQoNCg0KQnV0IGZpcnN0
LCB3ZSBuZWVkIHRvIGZpbmlzaCB0aGUgZXhpc3Rpbmcgc3BlYywgc28gdGhhdCB0aGUgcmVnaXN0
cnkgZW5hYmxpbmcgdGhlc2UgZXh0ZW5zaW9ucyBnZXRzIGVzdGFibGlzaGVkIGluIHRoZSBmaXJz
dCBwbGFjZS4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQpGcm9tOiBQaGlsIEh1bnQgKElE
TSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAyNCwgMjAxNiAyOjEzIFBNDQoNClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQoNCkNjOiA8
b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPjxt
YWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIu
MCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KDQoNCll1cC4gQW5kIGJlY2F1c2UgdGhlcmUgbWFueSBy
ZWxhdGlvbnMgdGhlIGNsaWVudCBtaXN0IGJlIGFibGUgdG8gZGlzY292ZXIgaXQuIFRoZSBjbGll
bnQgZG9lcyBub3Qga25vdyBpZiB0aGUgcmVzIHNlcnZlciBpcyBsZWdpdC4NCg0KDQoNClRoZSB1
c2VyaW5mbyBpcyBhbHdheXMgZml4IGFuZCBzbyB1IGRvbnQgbmVlZCBkaXNjb3ZlcnkuDQoNCg0K
DQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDE0OjA1LCBNaWtlIEpvbmVzIDxNaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20+IHdyb3RlOg0KDQoNCg0KSW4gT3BlbklEIENvbm5lY3QsIHRoZXJl4oCZcyBhIHJlc291cmNl
IHNlcnZlciBjYWxsZWQgdGhlIFVzZXJJbmZvIEVuZHBvaW50IHRoYXQgcmV0dXJucyBjbGFpbXMg
YWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlciBhcyBhIEpTT04gZGF0YSBzdHJ1Y3R1cmUuICBJ
dHMgbG9jYXRpb24gaXMgcHVibGlzaGVkIGluIE9wZW5JRCBDb25uZWN0IGRpc2NvdmVyeSBtZXRh
ZGF0YSBhcyB0aGUg4oCcdXNlcmluZm9fZW5kcG9pbnTigJ0gbWV0YWRhdGEgdmFsdWUsIHdoaWNo
IGlzIGRlZmluZWQgYXQgaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlz
Y292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0YWRhdGEuDQoNCg0KDQpXZSBkaWRu4oCZdCBpbmNs
dWRlIHRoZSBVc2VySW5mbyBFbmRwb2ludCBpbiB0aGUgZ2VuZXJpYyBPQXV0aCBkaXNjb3Zlcnkg
c3BlYyBzaW5jZSBpbiBPQXV0aCwgdGhlcmUgYXJlIGxvdHMgb2YgcG9zc2libGUgcmVsYXRpb25z
aGlwcyBiZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgcmVzb3VyY2Ugc2VydmVycyBh
bmQgdGhleSBuZWVkbuKAmXQgYmUgb25lLXRvLW9uZSwgYXMgaXMgYmVpbmcgYWN0aXZlbHkgZGlz
Y3Vzc2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAgRm9yIGluc3RhbmNlLCBzZWUgR2VvcmdlIEZs
ZXRjaGVy4oCZcyByZWNlbnQgY29udHJpYnV0aW9uLg0KDQoNCg0KVGhhbmtzIGZvciB0aGUgZ29v
ZCBkaXNjdXNzaW9uLCBQaGlsLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCkZyb206IFBo
aWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KDQpTZW50OiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDE6MjUgUE0NCg0KVG86IE1pa2UgSm9uZXMNCg0KQ2M6
IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpXaGVyZSBpcyB0
aGUgcHJvZmlsZSBlbmRwb2ludCAob2lkYydzIHJlc291cmNlIHNlcnZlcikgcHVibGlzaGVkPyAo
Rm9yIHRoZSBub24gT0lEQyBwZW9wbGUgb24gdGhlIGxpc3QpLg0KDQoNCg0KUGhpbA0KDQoNCg0K
T24gRmViIDI0LCAyMDE2LCBhdCAxMzowOSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0K
DQoNClRvIHRoZSBleHRlbnQgdGhhdCBnZW5lcmljIE9BdXRoIDIuMCBuZWVkcyB0byBwdWJsaXNo
IHNvbWUgb2YgdGhlIHNhbWUgaW5mb3JtYXRpb24gYXMgT3BlbklEIENvbm5lY3Qg4oCTIHdoaWNo
IGlzIGJ1aWx0IG9uIGdlbmVyaWMgT0F1dGggMi4wIOKAkyBpdCBtYWtlcyBzZW5zZSB0byBwdWJs
aXNoIHRoYXQgaW5mb3JtYXRpb24gdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBzeW50YXgsIHNpbmNl
IHRoYXQgc3ludGF4IGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UuICBUaGF0IHdoYXQgdGhp
cyBkcmFmdCBhY2NvbXBsaXNoZXMuDQoNCg0KDQpUaGVyZeKAmXMgbm90aGluZyBDb25uZWN0LXNw
ZWNpZmljIGFib3V0IHVzaW5nIG1ldGFkYXRhIHJlc3BvbnNlIHZhbHVlcyBsaWtlOg0KDQoNCg0K
ICAgImF1dGhvcml6YXRpb25fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20v
YXV0aG9yaXplIjxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRob3JpemU+LA0KDQogICAi
dG9rZW5fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iPGh0dHBz
Oi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuPiwNCg0KICAgInRva2VuX2VuZHBvaW50X2F1dGhf
bWV0aG9kc19zdXBwb3J0ZWQiOiBbImNsaWVudF9zZWNyZXRfYmFzaWMiLCAicHJpdmF0ZV9rZXlf
and0Il0sDQoNCiAgICJyZWdpc3RyYXRpb25fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhh
bXBsZS5jb20vcmVnaXN0ZXIiPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyPiwN
Cg0KICAgInJlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCI6ICBbImNvZGUiLCAidG9rZW4iXSwNCg0K
ICAgInNlcnZpY2VfZG9jdW1lbnRhdGlvbiI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3Nl
cnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sIjxodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZp
Y2VfZG9jdW1lbnRhdGlvbi5odG1sPiwNCg0KDQoNCklzIHRoZXJlIGEgcmVhc29uIHRoYXQgeW91
IHdvdWxkIGxpa2UgdGhlIHN5bnRheCBmb3IgYW55IG9mIHRoZXNlIG9yIHRoZSBvdGhlciBnZW5l
cmFsbHkgYXBwbGljYWJsZSBPQXV0aCAyLjAgbWV0YWRhdGEgdmFsdWVzIHRvIGJlIGRpZmZlcmVu
dD8gIEkgZG9u4oCZdCBzZWUgYW55IGdvb2QgcmVhc29uIGZvciB1bm5lY2Vzc2FyeSBkaWZmZXJl
bmNlcyB0byBiZSBpbnRyb2R1Y2VkLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCkZyb206
IFBoaWwgSHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KDQpTZW50OiBX
ZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEyOjQ1IFBNDQoNClRvOiBBbnRob255IE5hZGFs
aW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT48bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4N
Cg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRo
QGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3Vi
amVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0K
TWlrZQ0KDQoNCg0KUHVibGlzaGluZyBvbiBkZXYgcGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29m
dHdhcmUgKGVzcCBvcGVuIHNvdXJjZSkgdGhhdCBpcyBkZXBsb3llZCBib3RoIGluIGVudGVycHJp
c2VzIGFuZCBvbiBQYWFTIGNsb3VkIHByb3ZpZGVycy4NCg0KDQoNClRoZSBjdXJyZW50IGRyYWZ0
IGlzIG1heSBjb2RpZnkgY3VycmVudCBPSURDIHByYWN0aWNlIGFuZCBiZSBhcHByb3ByaWF0ZSBm
b3Igb2lkYyBidXQgaXQgaXMgbm90IHJlYWR5IGZvciBnZW5lcmljIG9hdXRoLiBUaGVyZSBpcyBu
byBnZW5lcmljIG9hdXRoIGV4cGVyaWVuY2UgYXQgdGhpcyB0aW1lLg0KDQoNCg0KUGhpbA0KDQoN
Cg0KT24gRmViIDI0LCAyMDE2LCBhdCAxMDoyNSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1p
Y3Jvc29mdC5jb20+PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQoNCg0K
U3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91IGhhdmUgbm93IG1hZGUgaXQgZmFyIGVhc2llciBh
bmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvZXMgbm90IGV2ZW4gYWRkcmVzcyB0aGlz
DQoNCg0KDQpGcm9tOiBNaWtlIEpvbmVzDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQs
IDIwMTYgMTA6MjIgQU0NCg0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQu
Y29tPjxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3Jn
PjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGll
dGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExv
Y2F0aW9uDQoNCg0KDQpBcyB3ZeKAmWQgZGlzY3Vzc2VkIGluIHBlcnNvbiwgdGhlcmXigJlzIG5v
IGVmZmVjdGl2ZSBzZWN1cml0eSBkaWZmZXJlbmNlIGJldHdlZW4gZGlzY292ZXJ5IGluZm9ybWF0
aW9uIGJlaW5nIHB1Ymxpc2hlZCBpbiBhbiBhZC1ob2MgZmFzaGlvbiBvbiBkZXZlbG9wZXIgcGFn
ZXMgYW5kIGl0IGJlaW5nIHB1Ymxpc2hlZCBpbiBhIHN0YW5kYXJkIGZvcm1hdC4gIOKAnFNlY3Vy
aXR5IGJ5IG9ic2N1cml0eeKAnSBhZGRzIG5vIHJlYWwgc2VjdXJpdHkgYXQgYWxsLg0KDQoNCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0tIE1pa2UNCg0KDQoNCkZyb206IEFudGhvbnkgTmFkYWxpbg0KDQpTZW50OiBXZWRuZXNkYXks
IEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjAxIEFNDQoNClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBQ
aGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+OyBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2lt
dXJhQGdtYWlsLmNvbT4NCg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYu
b3JnPiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDog
UkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KVGhlIHBv
aW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2Nv
dmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLg0KDQoN
Cg0KVGhhdCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRl
cGxveWVkIGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt
IGRpc2NvdmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBP
QXV0aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhh
dCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3Vu
ZCB0aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1
cHQgeW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNl
Y3VyaXR5IGNvbnNpZGVyYXRpb25zICBzZWN0aW9uIGF0IGFsbA0KDQoNCg0KRnJvbTogT0F1dGgg
W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0K
DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDk6NTQgQU0NCg0KVG86IFBoaWwg
SHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbT47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11cmFA
Z21haWwuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTog
W09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpUaGUgcG9pbnQg
b2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5
IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuDQoNCg0KDQpO
b25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJl
bGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0ZWQuICBJ4oCZbSBzdXJlIGl0IHdp
bGwgYmUuICBTb21lIGFwcGxpY2F0aW9ucyB3aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRo
ZSBkaXNjb3ZlcnkgbWV0YWRhdGEuICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVy
cy4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgYXBwbGljYXRpb24tc3BlY2lmaWMgLndlbGwta25v
d24gdmFsdWVzLiAgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0
IGV2ZW4gdGhvdWdodCBhYm91dC4gIEFsbCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBk
aXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgZm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdl
IGl0IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292
ZXJ5IG1ldGFkYXRhIHZhbHVlcy4NCg0KDQoNClNvIGJ5IGFsbCBtZWFucywgdGhlIHdvcmtpbmcg
Z3JvdXAgc2hvdWxkIGNvbnRpbnVlIGRpc2N1c3NpbmcgaW52ZW50aW5nIHBvc3NpYmxlIG5ldyBy
ZWxhdGVkIG1lY2hhbmlzbXMgdGhhdCBtYWtlIHNlbnNlIGluIHNvbWUgY29udGV4dHMuICBBdCB0
aGUgc2FtZSB0aW1lLCB3ZSBjYW4gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGFscmVhZHkgd2lk
ZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0aGF0IGFsbCBvZiB0aGVzZSBtZWNoYW5p
c21zIHdpbGwgbmVlZC4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElETSkNCg0K
U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFNDQoNClRvOiBOYXQgU2Fr
aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4NCg0K
Q2M6IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5v
cmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1
dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KSSBhbSBzdWdnZXN0aW5nIHRoYXQgcGFy
dCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGluZGljYXRp
bmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmlndXJhdGlv
biBkYXRhIGZvci4NCg0KDQoNClNvIGlmIHJlcy5leGFtcGxlLmV2aWwuY29tIGlzIG5vdCBhIHZh
bGlkIHJlc291cmNlIGVuZHBvaW50IGZvciBhcy5leGFtcGxlLmNvbSB0aGUgYXV0aHogZGlzY292
ZXJ5IHNob3VsZCBmYWlsIGluIHNvbWUgd2F5IChlZyByZXR1cm4gbm90aGluZykuDQoNCg0KDQpU
aGVyZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8gZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3Zlcnku
IE9yIGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlzY292ZXJ5Lg0KDQoNCg0KT25lIG9mIE9BdXRoJ3Mg
c3RyZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXph
dGlvbiAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5k
IHVwIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSBy
ZWxhdGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292
ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBv
cnRhbnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2Yg
ZW5kcG9pbnRzIGV0Yy4NCg0KDQoNClRoaXMgaXMgd2h5IEkgd2FzIGRpc2FwcG9pbnRlZCBhYm91
dCB3Z2xjIG9uIGRpc2NvdmVyeS4gV2UgaGFkIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGdyb3VwIGFk
b3B0aW9uIGJ1dCB3ZSBoYXZlbid0IHJlYWxseSBkZWZpbmVkIHRoZSBmdWxsIHJlcXVpcmVtZW50
cyBJTU8uDQoNCg0KDQpJIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0IHNvbWUgdGhvdWdo
dCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBhcG9sb2dpemUgSSBj
YW4ndCBkbyBpdCBub3cuDQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4
OjEyLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdt
YWlsLmNvbT4gd3JvdGU6DQoNCg0KDQpIaSBQaGlsLA0KDQoNCg0KQXJlIHlvdSBzdWdnZXN0aW5n
IHRoYXQgdGhlIEFTIG1ldGFkYXRhIHNob3VsZCBpbmNsdWRlIHRoZSBSUyBVUklzPyBDdXJyZW50
bHksIGl0IGRvZXMgbm90LCBidXQgaXQgY2FuIGJlIGRvbmUsIEkgZ3Vlc3MuDQoNCg0KDQpUaGUg
d2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdA0KDQoNCg0KMS4gUlMgdGVsbHMgdGhlIGNsaWVu
dCB3aGVyZSB0aGUgQVMgaXMuDQoNCjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5k
cG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4NCg0KDQoNCkV2ZW4gaWYgdGhlcmUgaXMgYSBi
YWQgQVMgd2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBSUywgdGhl
IGNsaWVudCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHogc2VydmVy
IHdpbGwgc2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50IHRvIHNl
bmQgdGhlIHRva2VuIHRvLg0KDQoNCg0KTmF0DQoNCg0KDQoyMDE25bm0MuaciDI05pelKOawtCkg
MjM6NTkgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBv
cmFjbGUuY29tPjoNCg0KTmF0LA0KDQoNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhl
IHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24g
c2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUg
QXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBi
b3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNv
dXJjZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KDQoNCklmIGEgY2xp
ZW50IGRpc2NvdmVycyBhIGZha2UgcmVzb3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9y
IGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIgdGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBu
b3QgbGVhZCB0aGUgY2xpZW50IHRvIHVuZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJj
ZSBzZXJ2ZXIuIFJhdGhlciB0aGUgZmFrZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZl
IGEgZmFrZSBkaXNjb3Zlcnkgc2VydmljZS4gVGhlIGhhY2tlciBjYW4gbm93IGludGVyY2VwdCBy
ZXNvdXJjZSBwYXlsb2FkIGFzIHdlbGwgYXMgdG9rZW5zIGJlY2F1c2UgdGhleSB3ZXJlIGFibGUg
dG8gY29udmluY2UgdGhlIGNsaWVudCB0byB1c2UgdGhlIGxlZ2l0IGF1dGhvcml6YXRpb24gc2Vy
dmljZSBidXQgdXNlIHRoZSB0b2tlbiBhZ2FpbnN0IHRoZSBoYWNrZXJzIHByb3h5Lg0KDQoNCg0K
VGhlIE9BdXRoIERpc2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVu
dCB0aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJl
c291cmNlIGVuZHBvaW50Lg0KDQoNCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1
dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KDQoN
ClBoaWwNCg0KDQoNCkBpbmRlcGVuZGVudGlkDQoNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRw
Oi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KDQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86
cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gRmViIDI0LCAy
MDE2LCBhdCAzOjU0IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRv
OnNha2ltdXJhQGdtYWlsLmNvbT4gd3JvdGU6DQoNCg0KDQoNCg0KSGkgVGhvbWFzLA0KDQoNCg0K
aW5saW5lOg0KDQoNCg0KMjAxNuW5tDLmnIgyMuaXpSjmnIgpIDE4OjQ0IFRob21hcyBCcm95ZXIg
PHQuYnJveWVyQGdtYWlsLmNvbT48bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT46DQoNCkNvdWxk
bid0IHRoZSBkb2N1bWVudCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT8NCg0KSSBxdWl0ZSBs
aWtlIHRoZSBpZGVhIG9mIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3
YW50IHRvIGRvIGRpc2NvdmVyeSwgYW5kIGxlYXZlIGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8g
dG8gb3RoZXIgc3BlY3MgdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJMIGZvciAiYXV0by1jb25m
aWd1cmF0aW9uIi4NCg0KVGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0
aGVyIGJlIHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJh
LW9hdXRoLW1ldGEgbWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBt
ZXRhZGF0YSBzcGVjcyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuDQoNCldpdGggZHJhZnQtc2FraW11
cmEtb2F1dGgtbWV0YSdzICJkdXJpIiBhbmQgdGhlICJzY29wZSIgYXR0cmlidXRlIG9mIFdXVy1B
dXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBuZWVk
IHRvIHByb2NlZWQNCg0KDQoNCll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRv
IGJlIFJFU1RmdWwsIGlzIGl0IG5vdD8NCg0KDQoNCkluIE9BdXRoJ3MgY2FzZSwgdGhlIHJlc291
cmNlIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIHVzdWFsbHkgdGlnaHRseSBjb3Vw
bGVkLiAoT3RoZXJ3aXNlLCB5b3UgbmVlZCBhbm90aGVyIHNwZWNzIGxpa2UgVU1BLikNCg0KU28s
IHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxv
Y2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50
LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0
aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3Qg
aGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBm
cmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxp
c2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2Ug
YXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KDQoNCih3ZWxsLCBleGNlcHQgaWYgdGhlcmUgYXJlIHNl
dmVyYWwgQVNzIGVhY2ggd2l0aCBkaWZmZXJlbnQgc2NvcGVzOyBzb3VuZHMgbGlrZSBhbiBlZGdl
LWNhc2UgdG8gbWUgdGhvdWdoOyBtYXliZSBSRkM2NzUwIHNob3VsZCBpbnN0ZWFkIGJlIHVwZGF0
ZWQgd2l0aCBzdWNoIGEgcGFyYW1ldGVyIHN1Y2ggdGhhdCBhbiBSUyBjb3VsZCByZXR1cm4gc2V2
ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBpdHMgb3duICJzY29wZSIg
YW5kICJkdXJpIiB2YWx1ZT8pDQoNCg0KDQpZZWFoLCBJIGd1ZXNzIGl0IGlzIGFuIGVkZ2UgY2Fz
ZS4gSSB3b3VsZCByYXRoZXIgbGlrZSB0byBzZWUgdGhlc2UgYXV0aHogc2VydmVycyB0byBkZXZl
bG9wIGEgdHJ1c3QgZnJhbWV3b3JrIHVuZGVyIHdoaWNoIHRoZXkgY2FuIGFncmVlIG9uIGEgc2lu
Z2xlIHNldCBvZiBjb21tb24gc2NvcGUgcGFyYW1ldGVyIHZhbHVlcy4NCg0KDQoNCkNoZWVycywN
Cg0KDQoNCk5hdA0KDQoNCg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQ
TSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+
IHdyb3RlOg0KDQpUaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMg
aGVscGZ1bCBhbmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2
ZXIsIHN0aWxsIGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9y
aWdpbnMuIE9uZSBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0
aGUgdXNlIG9mIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUg
ZGlzY292ZXJ5IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBv
ciBhbiBPcGVuSUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGlu
ZyByZWFzb24gdG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlzbS4N
Cg0KDQoNCkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24vb2F1dGgtYXV0aG9y
aXphdGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxvY2F0aW9uLCBhbmQg
c3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxlIGZyb20g4oCcLy53
ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2ZXIgYWxzbyBwcm92
aWRlcyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVyIGFwcGxpY2F0aW9u
cyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBPQXV0aCBl
bmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZpYyBkaXNj
b3ZlcnkgZG9jdW1lbnQuDQoNCg0KDQog4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1
dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9y
ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP
QXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
DQoNCg0KLS0NCg0KVmxhZGltaXIgRHpodXZpbm92IDo6IHZsYWRpbWlyQGNvbm5lY3QyaWQuY29t
PG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4NCg==

--_000_BY2PR03MB4425461F4C68FAAABC422BDF5A60BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290
aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN
Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdy
YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt
YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2
Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w
LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9y
bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM
aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjg3NTYzNTM3Ow0K
CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDcwMDgxNDI0
IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3
Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp
bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF
Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PlRoYW5rcyBmb3IgeW91ciB0aG91Z2h0cywgVmxhZGltaXIuJm5ic3A7IEnigJltIGluY3JlYXNp
bmdseSBpbmNsaW5lZCB0byBhY2NlcHQgeW91ciBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgdGl0
bGUgZnJvbSDigJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdIHRvIOKAnE9BdXRoIDIuMCBBdXRob3Jp
emF0aW9uDQogU2VydmVyIERpc2NvdmVyeeKAnS4mbmJzcDsgV2hpbGUgdGhlIGFic3RyYWN0IGFs
cmVhZHkgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGlzIEFT
IGRpc2NvdmVyeSwgZG9pbmcgc28gaW4gdGhlIHRpdGxlIHNlZW1zIGxpa2UgaXQgY291bGQgaGVs
cCBjbGFyaWZ5IHRoaW5ncywgZ2l2ZW4gdGhhdCBhIGxvdCBvZiB0aGUgZGlzY3Vzc2lvbiBzZWVt
cyB0byBiZSBhYm91dCByZXNvdXJjZSBkaXNjb3ZlcnksIHdoaWNoIGlzIG91dA0KIG9mIHNjb3Bl
IG9mIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw
NjAiPknigJltIG5vdCBzYXlpbmcgdGhhdCByZXNvdXJjZSBkaXNjb3ZlcnkgaXNu4oCZdCBpbXBv
cnRhbnQg4oCTIGl0IGlzIOKAkyBidXQgdW5saWtlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpc2Nv
dmVyeSwgd2hlcmUgdGhlcmXigJlzIGxvdHMgb2YgZXhpc3RpbmcgcHJhY3RpY2UsIGluY2x1ZGlu
Zw0KIHVzaW5nIHRoZSBleGlzdGluZyBkYXRhIGZvcm1hdCBmb3IgZGVzY3JpYmluZyBPQXV0aCBp
bXBsZW1lbnRhdGlvbnMgdGhhdCBhcmVu4oCZdCBiZWluZyB1c2VkIHdpdGggT3BlbklEIENvbm5l
Y3QsIHRoZXJl4oCZcyBubyBleGlzdGluZyBwcmFjdGljZSB0byBzdGFuZGFyZGl6ZSBmb3IgcmVz
b3VyY2UgZGlzY292ZXJ5LiZuYnNwOyBUaGUgdGltZSB0byBjcmVhdGUgYSBzdGFuZGFyZCBmb3Ig
dGhhdCBzZWVtcyB0byBiZSBhZnRlciBleGlzdGluZyBwcmFjdGljZQ0KIGhhcyBlbWVyZ2VkLiZu
YnNwOyBJdCAqPGI+bWlnaHQ8L2I+KiBvciBtaWdodCBub3QgdXNlIG5ldyBtZXRhZGF0YSB2YWx1
ZXMgaW4gdGhlIEFTIGRpc2NvdmVyeSBkb2N1bWVudCwgYnV0IHRoYXTigJlzIHN0aWxsIHRvIGJl
IGRldGVybWluZWQuJm5ic3A7IFRoZSBvbmUgcmVhc29uIHRvIGxlYXZlIHRoZSB0aXRsZSBhcy1p
cyBpcyB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBtaWdodCBlbmQgdXAgaW52b2x2aW5nIGV4dGVu
c2lvbnMgdG8gdGhpcyBtZXRhZGF0YSBmb3JtYXQNCiBpbiBzb21lIGNhc2VzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB0aGluayBhbiBhbmFsb2d5IHRvIHRo
ZSBjb3JlIE9BdXRoIGRvY3VtZW50cyBSRkMgNjc0OSBhbmQgUkZDIDY3NTAgYXBwbGllcy4mbmJz
cDsgNjc0OSBpcyBhYm91dCB0aGUgQVMuJm5ic3A7IDY3NTAgaXMgYWJvdXQgdGhlIFJTLiZuYnNw
OyBUaGUgZGlzY292ZXJ5IGRvY3VtZW50IGlzIGFib3V0IHRoZQ0KIEFTLiZuYnNwOyBXZSBkb27i
gJl0IHlldCBoYXZlIGEgc3BlY2lmaWNhdGlvbiBvciBleGlzdGluZyBwcmFjdGljZSBmb3IgUlMg
ZGlzY292ZXJ5LCB3aGljaCB3b3VsZCBiZSB0aGUgNjc1MCBhbmFsb2d5LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy
MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SW4gc3VtbWFyeSwgd2hpY2ggdGl0bGUgZG8g
cGVvcGxlIHByZWZlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh
cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv
MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v
cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z
cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+4oCcT0F1dGggMi4w
IERpc2NvdmVyeeKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy
YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x
Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y
ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj7igJxPQXV0aCAyLjAg
QXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ54oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOndpbmRvd3RleHQiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8
Yj5PbiBCZWhhbGYgT2YgPC9iPlZsYWRpbWlyIER6aHV2aW5vdjxicj4NCjxiPlNlbnQ6PC9iPiBU
aHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgMTI6NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRo
QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBE
aXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkluIE9JREMgdGhlIGRpc2NvdmVy
eSBkb2MgaXMgb2YgZ3JlYXQgdXRpbGl0eSB0byBkZXZlbG9wZXJzIGFuZCBpbnRlZ3JhdG9ycy4g
RGV2ZWxvcGVycyBhbHNvIHRlbmQgdG8gZmluZCBpdCBhIG1vcmUgYWNjdXJhdGUgYW5kIGNvbXBs
ZXRlIGRlc2NyaXB0aW9uIG9mIGhvdyB0byBzZXQgdXAgYSBjbGllbnQgZm9yIGEgcGFydGljdWxh
ciBkZXBsb3ltZW50LCBjb21wYXJlZA0KIHRvIHRyYWRpdGlvbmFsIG9ubGluZSBkb2NzLCB3aGlj
aCBtYXkgYmUgbm90IGJlIHVwIHRvIGRhdGUsIG9yIGV2ZW4gbWlzc2luZy4gVmVyeSBtdWNoIGxp
a2UgYXV0by1nZW5lcmF0ZWQgU3dhZ2dlciBhbmQgSmF2YURvY3MuPGJyPg0KPGJyPg0KSGVyZSBh
cmUgc29tZSBleGFtcGxlIE9JREMgZGlzY292ZXJ5IGRvY3M6PGJyPg0KPGJyPg0KPGEgaHJlZj0i
aHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0
aW9uIj5odHRwczovL2FjY291bnRzLmdvb2dsZS5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZp
Z3VyYXRpb248L2E+PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cucGF5cGFsb2JqZWN0
cy5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24iPmh0dHBzOi8vd3d3LnBheXBh
bG9iamVjdHMuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPC9hPjxicj4NCjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbS9mYWJyaWthbWIy
Yy5vbm1pY3Jvc29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiI+
aHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2ZhYnJpa2FtYjJjLm9ubWljcm9zb2Z0
LmNvbS92Mi4wLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPC9hPjxicj4NCjxicj4N
Cjxicj4NCldpdGggdGhpcyBkaXNjb3ZlcnkgZG9jdW1lbnQgaW4gcGxhY2Ugc2V0dXAgb2YgaWRl
bnRpdHkgZmVkZXJhdGlvbiBjYW4gdGhlbiBiZSBlYXNpbHkgc2NyaXB0ZWQuIEZvciBleGFtcGxl
Ojxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9kb2NzLmF3cy5hbWF6b24uY29tL0lBTS9sYXRl
c3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVyc19jcmVhdGVfb2lkY192ZXJpZnktdGh1bWJw
cmludC5odG1sIj5odHRwOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9JQU0vbGF0ZXN0L1VzZXJHdWlk
ZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5LXRodW1icHJpbnQuaHRtbDwv
YT48YnI+DQo8YnI+DQo8YnI+DQpOb3csIGRvZXMgdGhhdCBkaWN0YXRlIGFueSBwYXJ0aWN1bGFy
IGFwcCBhcmNoaXRlY3R1cmU/IE15IHJlYWRpbmcgb2YgdGhlIHNwZWMgaXMgdGhhdCBpdCBkb2Vz
bid0LCBhbmQgaXQgc2hvdWxkbid0IGVpdGhlci4gQnkgc3RheWluZyBuZXV0cmFsIG9uIHRoZSB0
b3BpY3Mgb2YgUlMgZGlzY292ZXJ5IGFuZCByZWdpc3RlcmluZyBSUHMgd2l0aCBSU3MuIEFuZCBo
b3cgb25lIGFycml2ZXMgYXQgdGhlICZxdW90Oy53ZWxsLWtub3duLy4uLiZxdW90Oy4gSSdtIG5v
dA0KIGV2ZW4gc3VyZSB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBzaG91bGQgYmUgYSB0b3BpYyBv
ZiB0aGlzIFdHLiBQZXJoYXBzIHRvIHRoaXMgZW5kLCBhbmQgdG8gcHJldmVudCBjb25mdXNpb24g
dGhhdCB0aGUgc3BlYyBpcyB0cnlpbmcgdG8gZG8gc29tZXRoaW5nIG1vcmUsIGEgbW9yZSBzcGVj
aWZpYyB0aXRsZSB3b3VsZCBzdWl0IGl0IGJldHRlci4gRS5nLiAmcXVvdDtBUyBEaXNjb3Zlcnkm
cXVvdDsuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NClZsYWRpbWlyPGJyPg0KPGJyPg0K
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gMjUvMDIvMTYgMDI6MjUsIFBoaWwgSHVudCAoSURNKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPkFuZCBzbyBkb2VzIG9yYWNsZSBhbmQgc28gZG9lcyBnb29nbGUuIEVh
Y2ggZGlmZmVyZW50LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5TbyBob3cgY2FuIGFuIGFwcCBkaWN0YXRlIGl0IHRoZW4gdW5sZXNzIHdlIGFs
bCBnbyB0byBhIGNvbW1vbiBhcmNoaXRlY3R1cmU/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGhpbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAxNjowNCwg
TWlrZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj4m
bHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT4gd3JvdGU6PG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QXp1cmUgZGVmaW5lcyB3
YXlzIGZvciByZXNvdXJjZSBzZXJ2ZXJzIHRvIGJlIHJlZ2lzdGVyZWQgZm9yIHVzZSB3aXRoIGEg
Y2xpZW50IGFuZCBmb3IgY2xpZW50cyB0byBkeW5hbWljYWxseSByZXF1ZXN0IGFuIGFjY2VzcyB0
b2tlbiBmb3IgdXNlIGF0IGEgcGFydGljdWxhciByZXNvdXJjZSBzZXJ2ZXIuJm5ic3A7IFlvdSBj
YW4gY2FsbCB0aGF0IGN1c3RvbSBhcmNoaXRlY3R1cmUgaWYgeW91IHdhbnQuJm5ic3A7IEl04oCZ
cyB3ZWxsLWRlZmluZWQgYnV0IGl04oCZcyBub3QgY3VycmVudGx5IGluIHRoZSBzdGFuZGFyZHMg
cmVhbG0uJm5ic3A7IEkga25vdyB0aGF0IEdvb2dsZSBoYXMgc3ludGF4IGZvciBkb2luZyB0aGUg
c2FtZSwgYXMgSeKAmW0gc3VyZSBkbyBhIGxvdCBvZiBvdGhlciBjbG91ZCBPQXV0aCBkZXBsb3lt
ZW50cywgc3VjaCBhcyBPcmFjbGXigJlzLiZuYnNwOyBGb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRo
ZSB3b3JraW5nIGdyb3VwIHRhbGtlZCBhYm91dCBwb3NzaWJseSBwcm9kdWNpbmcgYSBzdGFuZGFy
ZCB2ZXJzaW9uIG9mIHN5bnRheCBmb3IgbWFraW5nIHRoZXNlIGtpbmRzIG9mIHJlcXVlc3RzIGR1
cmluZyBvdXIgZGlzY3Vzc2lvbnMgaW4gUHJhZ3VlIChkdXJpbmcgdGhlIFRva2VuIEV4Y2hhbmdl
IGRpc2N1c3Npb24pIGJ1dCBub2JvZHkgaGFzIHJ1biB3aXRoIHRoaXMgeWV0LjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JbiB0aGlzIHNlbnNlLCB5ZXMs
IEF6dXJlIGlzIGFuIGFwcGxpY2F0aW9uIG9mIHRoZSBraW5kIHdl4oCZcmUgdGFsa2luZyBhYm91
dC4mbmJzcDsgQXp1cmUgYWxyZWFkeSBkb2VzIGRlZmluZSBzcGVjaWZpYyBuZXcgT0F1dGggMi4w
IGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMgdGhhdCBhcmUgdXNlZCBpbiBwcm9kdWN0aW9uLiZu
YnNwOyBBIHJlZ2lzdHJ5IGp1c3QgZG9lc27igJl0IHlldCBleGlzdCBpbiB3aGljaCBpdCBjYW4g
cmVnaXN0ZXIgdGhvc2UgdGhhdCBhcmUgb2YgZ2VuZXJhbCBhcHBsaWNhYmlsaXR5LjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtlPG86cD48L286cD48L3ByZT4NCjxwcmU+
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0i
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208
L2E+XSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0
LCAyMDE2IDM6NTIgUE08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogTWlrZSBKb25lczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZs
dDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDog
UmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NaWtlPG86cD48L286cD48L3ByZT4N
CjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRha2UgYSBsb29rIGF0IHRoZSBhc3N1bXB0
aW9ucyB5b3UgYXJlIG1ha2luZy4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+WW91IHNlZW0gdG8gYmUgYXNzdW1pbmcgYXBwbGljYXRpb24gc29m
dHdhcmUgZGljdGF0ZXMgb2F1dGggaW5mcmFzdHJ1Y3R1cmUgYXJjaGl0ZWN0dXJlIGJ5IHN1Z2dl
c3RpbmcgdGhhdCBhcHBzIHJlZ2lzdGVyIGluIGlhbmEuJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldvdWxkIG1zIGF6dXJlIGFsbG93
IGN1c3RvbSBhcmNoPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5PbiBGZWIgMjQsIDIwMTYsIGF0IDE1OjI4LCBNaWtlIEpvbmVzIDxhIGhyZWY9
Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPiZsdDtNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgVXNlckluZm8gRW5kcG9pbnQgcGF0aCBpc27igJl0
IGZpeGVkIGFuZCBzbyBoYXMgdG8gYmUgZGlzY292ZXJlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+SSBhZ3JlZSB0aGF0IGZvciBzb21lIE9BdXRoIHBy
b2ZpbGVzLCBvbmUgb3IgbW9yZSByZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSBkaXNj
b3ZlcmVkIHN0YXJ0aW5nIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiZuYnNwOyBXb3Jr
aW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSBhbHNvIGRlc2NyaWJlZCB3YW50aW5nIHRvIGRpc2NvdmVy
IGF1dGhvcml6YXRpb24gc2VydmVycyBzdGFydGluZyBmcm9tIHJlc291cmNlIHNlcnZlcnMuJm5i
c3A7IFRoZXJlIGlzbuKAmXQgYSBzdGFuZGFyZCBwcmFjdGljZSBmb3IgYW55IG9mIHRoaXMsIHdo
aWNoIGlzIHdoeSBpdOKAmXMgaW50ZW50aW9uYWxseSBsZWZ0IG91dCBvZiB0aGUgY3VycmVudCBz
cGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5PbmNlIHRoZSBJQU5BIE9BdXRoIERpc2NvdmVyeSBNZXRhZGF0YSBSZWdpc3RyeSBoYXMg
YmVlbiBlc3RhYmxpc2hlZCwgd2hpY2ggd2lsbCBoYXBwZW4gYWZ0ZXIgdGhlIGN1cnJlbnQgc3Bl
Y2lmaWNhdGlvbiBoYXMgYmVlbiBhcHByb3ZlZCwgaXQgd2lsbCBiZSBlYXN5IGZvciBzdWJzZXF1
ZW50IHNwZWNpZmljYXRpb25zIHRvIGRvY3VtZW50IGV4aXN0aW5nIHByYWN0aWNlIGZvciBkaWZm
ZXJlbnQgT0F1dGggcHJvZmlsZXMgYW5kIHJlZ2lzdGVyIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1
ZXMgc3VwcG9ydGluZyB0aGVtLiZuYnNwOyBTb21lIG9mIHRob3NlIHZhbHVlcyB3aWxsIGxpa2Vs
eSBkZWZpbmUgd2F5cyB0byBkaXNjb3ZlciByZXNvdXJjZSBzZXJ2ZXJzLCB3aGVuIGFwcGxpY2Fi
bGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJ1dCBm
aXJzdCwgd2UgbmVlZCB0byBmaW5pc2ggdGhlIGV4aXN0aW5nIHNwZWMsIHNvIHRoYXQgdGhlIHJl
Z2lzdHJ5IGVuYWJsaW5nIHRoZXNlIGV4dGVuc2lvbnMgZ2V0cyBlc3RhYmxpc2hlZCBpbiB0aGUg
Zmlyc3QgcGxhY2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tIE1pa2U8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogUGhpbCBI
dW50IChJRE0pIFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPm1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbTwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMjoxMyBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlRvOiBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20iPiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBp
ZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O29hdXRo
QGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW09B
VVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxw
cmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPll1cC4gQW5kIGJlY2F1c2UgdGhlcmUgbWFueSBy
ZWxhdGlvbnMgdGhlIGNsaWVudCBtaXN0IGJlIGFibGUgdG8gZGlzY292ZXIgaXQuIFRoZSBjbGll
bnQgZG9lcyBub3Qga25vdyBpZiB0aGUgcmVzIHNlcnZlciBpcyBsZWdpdC4gPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIHVzZXJpbmZvIGlz
IGFsd2F5cyBmaXggYW5kIHNvIHUgZG9udCBuZWVkIGRpc2NvdmVyeS4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGhpbDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9uIEZlYiAyNCwgMjAxNiwg
YXQgMTQ6MDUsIE1pa2UgSm9uZXMgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbSI+Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+IHdyb3RlOjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkluIE9w
ZW5JRCBDb25uZWN0LCB0aGVyZeKAmXMgYSByZXNvdXJjZSBzZXJ2ZXIgY2FsbGVkIHRoZSBVc2Vy
SW5mbyBFbmRwb2ludCB0aGF0IHJldHVybnMgY2xhaW1zIGFib3V0IHRoZSBhdXRoZW50aWNhdGVk
IHVzZXIgYXMgYSBKU09OIGRhdGEgc3RydWN0dXJlLiZuYnNwOyBJdHMgbG9jYXRpb24gaXMgcHVi
bGlzaGVkIGluIE9wZW5JRCBDb25uZWN0IGRpc2NvdmVyeSBtZXRhZGF0YSBhcyB0aGUg4oCcdXNl
cmluZm9fZW5kcG9pbnTigJ0gbWV0YWRhdGEgdmFsdWUsIHdoaWNoIGlzIGRlZmluZWQgYXQgPGEg
aHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFf
MC5odG1sI1Byb3ZpZGVyTWV0YWRhdGEiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1j
b25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCNQcm92aWRlck1ldGFkYXRhPC9hPi48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+V2UgZGlkbuKAmXQgaW5jbHVk
ZSB0aGUgVXNlckluZm8gRW5kcG9pbnQgaW4gdGhlIGdlbmVyaWMgT0F1dGggZGlzY292ZXJ5IHNw
ZWMgc2luY2UgaW4gT0F1dGgsIHRoZXJlIGFyZSBsb3RzIG9mIHBvc3NpYmxlIHJlbGF0aW9uc2hp
cHMgYmV0d2VlbiBhdXRob3JpemF0aW9uIHNlcnZlcnMgYW5kIHJlc291cmNlIHNlcnZlcnMgYW5k
IHRoZXkgbmVlZG7igJl0IGJlIG9uZS10by1vbmUsIGFzIGlzIGJlaW5nIGFjdGl2ZWx5IGRpc2N1
c3NlZCBieSB0aGUgd29ya2luZyBncm91cC4mbmJzcDsgRm9yIGluc3RhbmNlLCBzZWUgR2Vvcmdl
IEZsZXRjaGVy4oCZcyByZWNlbnQgY29udHJpYnV0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFua3MgZm9yIHRoZSBnb29kIGRpc2N1c3Npb24s
IFBoaWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tIE1pa2U8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogUGhpbCBIdW50IChJ
RE0pIFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPm1haWx0bzpwaGlsLmh1
bnRAb3JhY2xlLmNvbTwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2Rh
eSwgRmVicnVhcnkgMjQsIDIwMTYgMToyNSBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBN
aWtlIEpvbmVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0
aEBpZXRmLm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9u
PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldoZXJlIGlz
IHRoZSBwcm9maWxlIGVuZHBvaW50IChvaWRjJ3MgcmVzb3VyY2Ugc2VydmVyKSBwdWJsaXNoZWQ/
IChGb3IgdGhlIG5vbiBPSURDIHBlb3BsZSBvbiB0aGUgbGlzdCkuIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiBGZWIgMjQsIDIwMTYsIGF0
IDEzOjA5LCBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20iPiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UbyB0aGUg
ZXh0ZW50IHRoYXQgZ2VuZXJpYyBPQXV0aCAyLjAgbmVlZHMgdG8gcHVibGlzaCBzb21lIG9mIHRo
ZSBzYW1lIGluZm9ybWF0aW9uIGFzIE9wZW5JRCBDb25uZWN0IOKAkyB3aGljaCBpcyBidWlsdCBv
biBnZW5lcmljIE9BdXRoIDIuMCDigJMgaXQgbWFrZXMgc2Vuc2UgdG8gcHVibGlzaCB0aGF0IGlu
Zm9ybWF0aW9uIHVzaW5nIGV4YWN0bHkgdGhlIHNhbWUgc3ludGF4LCBzaW5jZSB0aGF0IHN5bnRh
eCBpcyBhbHJlYWR5IGluIHdpZGVzcHJlYWQgdXNlLiZuYnNwOyBUaGF0IHdoYXQgdGhpcyBkcmFm
dCBhY2NvbXBsaXNoZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPlRoZXJl4oCZcyBub3RoaW5nIENvbm5lY3Qtc3BlY2lmaWMgYWJvdXQgdXNpbmcgbWV0
YWRhdGEgcmVzcG9uc2UgdmFsdWVzIGxpa2U6PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2F1dGhvcml6YXRpb25f
ZW5kcG9pbnQmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGhv
cml6ZSI+JnF1b3Q7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplJnF1b3Q7PC9h
Piw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9p
bnQmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIj4mcXVv
dDtodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiZxdW90OzwvYT4sPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZxdW90O3Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9k
c19zdXBwb3J0ZWQmcXVvdDs6IFsmcXVvdDtjbGllbnRfc2VjcmV0X2Jhc2ljJnF1b3Q7LCAmcXVv
dDtwcml2YXRlX2tleV9qd3QmcXVvdDtdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyAmcXVvdDtyZWdpc3RyYXRpb25fZW5kcG9pbnQmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8v
c2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyIj4mcXVvdDtodHRwczovL3NlcnZlci5leGFtcGxl
LmNvbS9yZWdpc3RlciZxdW90OzwvYT4sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7ICZxdW90O3Jlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCZxdW90OzombmJzcDsgWyZxdW90O2Nv
ZGUmcXVvdDssICZxdW90O3Rva2VuJnF1b3Q7XSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsgJm5ic3A7JnF1b3Q7c2VydmljZV9kb2N1bWVudGF0aW9uJnF1b3Q7OiA8YSBocmVmPSJodHRw
Oi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sIj4mcXVvdDto
dHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sJnF1b3Q7
PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+SXMg
dGhlcmUgYSByZWFzb24gdGhhdCB5b3Ugd291bGQgbGlrZSB0aGUgc3ludGF4IGZvciBhbnkgb2Yg
dGhlc2Ugb3IgdGhlIG90aGVyIGdlbmVyYWxseSBhcHBsaWNhYmxlIE9BdXRoIDIuMCBtZXRhZGF0
YSB2YWx1ZXMgdG8gYmUgZGlmZmVyZW50PyZuYnNwOyBJIGRvbuKAmXQgc2VlIGFueSBnb29kIHJl
YXNvbiBmb3IgdW5uZWNlc3NhcnkgZGlmZmVyZW5jZXMgdG8gYmUgaW50cm9kdWNlZC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBQaGlsIEh1bnQgKElETSkgWzxhIGhyZWY9
Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t
PC9hPl0gPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAy
NCwgMjAxNiAxMjo0NSBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBBbnRob255IE5hZGFs
aW4gPGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+Jmx0O3RvbnluYWRAbWlj
cm9zb2Z0LmNvbSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IE1pa2UgSm9uZXMg
PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+Jmx0O01pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v
cmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5T
dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48
L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1pa2U8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+UHVibGlzaGluZyBvbiBkZXYg
cGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29mdHdhcmUgKGVzcCBvcGVuIHNvdXJjZSkgdGhhdCBp
cyBkZXBsb3llZCBib3RoIGluIGVudGVycHJpc2VzIGFuZCBvbiBQYWFTIGNsb3VkIHByb3ZpZGVy
cy4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
VGhlIGN1cnJlbnQgZHJhZnQgaXMgbWF5IGNvZGlmeSBjdXJyZW50IE9JREMgcHJhY3RpY2UgYW5k
IGJlIGFwcHJvcHJpYXRlIGZvciBvaWRjIGJ1dCBpdCBpcyBub3QgcmVhZHkgZm9yIGdlbmVyaWMg
b2F1dGguIFRoZXJlIGlzIG5vIGdlbmVyaWMgb2F1dGggZXhwZXJpZW5jZSBhdCB0aGlzIHRpbWUu
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlBo
aWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5P
biBGZWIgMjQsIDIwMTYsIGF0IDEwOjI1LCBBbnRob255IE5hZGFsaW4gPGEgaHJlZj0ibWFpbHRv
OnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+Jmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDs8L2E+
IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPlN1cmUgdGhlcmUgaXMsIGl0IGlzIGFzIHlvdSBoYXZlIG5vdyBtYWRlIGl0IGZhciBlYXNp
ZXIgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBldmVuIGFkZHJlc3Mg
dGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9t
OiBNaWtlIEpvbmVzIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVi
cnVhcnkgMjQsIDIwMTYgMTA6MjIgQU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogQW50aG9u
eSBOYWRhbGluIDxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPiZsdDt0b255
bmFkQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8YSBo
cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxh
IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAg
RGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkFzIHdl4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZm
ZWN0aXZlIHNlY3VyaXR5IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24g
YmVpbmcgcHVibGlzaGVkIGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBh
bmQgaXQgYmVpbmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiAmbmJzcDvigJxTZWN1
cml0eSBieSBvYnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBBbnRo
b255IE5hZGFsaW4gPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAyNCwgMjAxNiAxMDowMSBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBNaWtlIEpv
bmVzIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPiZsdDtNaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjsgUGhpbCBIdW50IChJRE0pIDxhIGhyZWY9
Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+Jmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0
OzwvYT47IE5hdCBTYWtpbXVyYSA8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj4m
bHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzog
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9h
PiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8
L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGgg
Mi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpw
PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPlRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRh
cmRpemluZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5
IHdpZGVseSBkZXBsb3llZC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4g
PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhdCBtYXkgYmUgd2lkZWx5IGRlcGxveWVkIGZvciBP
SURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVkIGZvciBPQXV0aC4gVGhlcmUgYXJlIHNvbWUgYXV0
aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2NvdmVyeSBmb3IgZW5kcG9pbnQgdGhhdCByZWFsbHkg
c2hvdWxkIG5vdCBiZSBpbiBhbiBPQXV0aCBzdGFuZGFyZCBzaW5jZSBpdOKAmXMgcmVhbGx5IG5v
dCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUg
aXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0aGUgZW5kcG9pbnQgbW9yZSBmb2N1c2VkIGZvciBwZW9w
bGUgdGhhdCB3YW50IHRvIGRpc3J1cHQgeW91ciBlbmRwb2ludHMsIHRoYXQgaXMgcmVhbGx5IG5v
dCBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zJm5ic3A7IHNlY3Rpb24g
YXQgYWxsPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZy
b206IE9BdXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1
NCBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBQaGlsIEh1bnQgKElETSkgPGEgaHJlZj0i
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj4mbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7
PC9hPjsgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPiZs
dDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8
YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+
IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0Ozwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAy
LjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPlRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRp
emluZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdp
ZGVseSBkZXBsb3llZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4N
CjxwcmU+Tm9uZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0aW5nIHRoYXQgYWRkaXRp
b25hbCByZWxhdGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVhdGVkLiZuYnNwOyBJ4oCZ
bSBzdXJlIGl0IHdpbGwgYmUuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25zIHdpbGwgdXNlIFdlYkZp
bmdlciB0byBsb2NhdGUgdGhlIGRpc2NvdmVyeSBtZXRhZGF0YS4mbmJzcDsgU29tZSB3aWxsIHBv
c3NpYmx5IHVzZSBsaW5rIGhlYWRlcnMuJm5ic3A7IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgYXBw
bGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24gdmFsdWVzLiZuYnNwOyBJ4oCZbSBzdXJlIHRo
ZXJl4oCZcyBvdGhlciB0aGluZ3MgSSBoYXZlbuKAmXQgZXZlbiB0aG91Z2h0IGFib3V0LiZuYnNw
OyBBbGwgb2YgdGhlc2UgZGVwZW5kIHVwb24gaGF2aW5nIGEgZGlzY292ZXJ5IG1ldGFkYXRhIGRv
Y3VtZW50IGZvcm1hdCBhbmQgbm9uZSBvZiB0aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBw
b3NzaWJseSB0byByZWdpc3RlciBhZGRpdGlvbmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMu
PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvIGJ5IGFs
bCBtZWFucywgdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGNvbnRpbnVlIGRpc2N1c3NpbmcgaW52
ZW50aW5nIHBvc3NpYmxlIG5ldyByZWxhdGVkIG1lY2hhbmlzbXMgdGhhdCBtYWtlIHNlbnNlIGlu
IHNvbWUgY29udGV4dHMuJm5ic3A7IEF0IHRoZSBzYW1lIHRpbWUsIHdlIGNhbiBmaW5pc2ggc3Rh
bmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5
IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2lsbCBuZWVkLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtlPG86cD48L286cD48
L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IE9BdXRoIFs8YSBocmVm
PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50IChJRE0pPG86cD48L286cD48L3ByZT4N
CjxwcmU+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFNPG86cD48L286
cD48L3ByZT4NCjxwcmU+VG86IE5hdCBTYWtpbXVyYSA8YSBocmVmPSJtYWlsdG86c2FraW11cmFA
Z21haWwuY29tIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5DYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4mbHQ7b2F1dGhAaWV0
Zi5vcmcmZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBp
ZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtPQVVU
SC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRo
ZSBkaXNjb3Zlcnkgc29sdXRpb24gaGFzIHRvIGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0
IHJlc291cmNlIGVuZHBvaW50IGl0IHdhbnRzIHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEg
Zm9yLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5TbyBpZiByZXMuZXhhbXBsZS5ldmlsLmNvbSBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRw
b2ludCBmb3IgYXMuZXhhbXBsZS5jb20gdGhlIGF1dGh6IGRpc2NvdmVyeSBzaG91bGQgZmFpbCBp
biBzb21lIHdheSAoZWcgcmV0dXJuIG5vdGhpbmcpLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGVyZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8g
ZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3ZlcnkuIE9yIGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlz
Y292ZXJ5LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5PbmUgb2YgT0F1dGgncyBzdHJlbmd0aCdzIGFuZCB3ZWFrbmVzc2VzIGlzIHRoYXQgdGhl
IHRhcmdldCBvZiBhdXRob3JpemF0aW9uICh0aGUgcmVzb3VyY2UpIGlzIG5ldmVyIHNwZWNpZmll
ZC4gSXQgaXMgb2Z0ZW4gYm91bmQgdXAgaW4gdGhlIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIGFu
IG9mdGVuIGltcGxpZWQgMToxIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHJlc291cmNlIGFuZCBhcy4g
R2l2ZW4gdGhhdCBpbiBkaXNjb3ZlcnkgcGhhc2UgcmVnaXN0cmF0aW9uIGhhcyBub3QgeWV0IG9j
Y3VycmVkIGl0IHNlZW1zIGltcG9ydGFudCB0aGF0IHRoZSBjbGllbnQga25vdyBpdCBoYXMgYSB2
YWxpZCBjb21iaW5hdGlvbiBvZiBlbmRwb2ludHMgZXRjLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIHdoeSBJIHdhcyBkaXNhcHBv
aW50ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0YXJ0aW5nIHBvaW50IGZv
ciBncm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVmaW5lZCB0aGUgZnVsbCBy
ZXF1aXJlbWVudHMgSU1PLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5JIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0IHNvbWUgdGhvdWdo
dCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBhcG9sb2dpemUgSSBj
YW4ndCBkbyBpdCBub3cuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5PbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2FraW11cmEgPGEg
aHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+Jmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZn
dDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPkhpIFBoaWwsIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRoZSBBUyBtZXRhZGF0YSBz
aG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBpdCBkb2VzIG5vdCwgYnV0IGl0
IGNhbiBiZSBkb25lLCBJIGd1ZXNzLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgd2F5IG9hdXRoLW1ldGEgd29ya3MgaXMgdGhhdCA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4xLiBSUyB0
ZWxscyB0aGUgY2xpZW50IHdoZXJlIHRoZSBBUyBpcy4gPG86cD48L286cD48L3ByZT4NCjxwcmU+
Mi4gQVMgdGVsbHMgdGhlIGNsaWVudCB3aGljaCBSUyBlbmRwb2ludHMgdGhlIHRva2VuIGNhbiBi
ZSB1c2VkLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5FdmVuIGlmIHRoZXJlIGlzIGEgYmFkIEFTIHdpdGggYSB2YWxpZCBjZXJ0cyB0aGF0IHBy
b3hpZXMgdG8gdGhlIGdvb2QgUlMsIHRoZSBjbGllbnQgd2lsbCBub3Qgc2VuZCB0aGUgdG9rZW4g
dGhlcmUgYXMgdGhlIGF1dGh6IHNlcnZlciB3aWxsIHNheSB0aGF0IGlzIG5vdCB0aGUgcGxhY2Ug
dGhlIGNsaWVudCBtYXkgd2FudCB0byBzZW5kIHRoZSB0b2tlbiB0by4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TmF0PG86cD48L286cD48L3By
ZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjIwMTY8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7lubQ8L3NwYW4+Mjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2Vy
aWYiPuaciDwvc3Bhbj4yNDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290
aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5rC0PC9zcGFuPikgMjM6NTkg
UGhpbCBIdW50IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+Jmx0O3BoaWwu
aHVudEBvcmFjbGUuY29tJmd0OzwvYT46PG86cD48L286cD48L3ByZT4NCjxwcmU+TmF0LDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5J4oCZbSBub3Qgc3Vy
ZSB0aGF0IGhhdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVyZSBp
dHMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0aW9u
c2hpcCBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNlIHNl
cnZlciBuZWVkIHRvIGJlIGJvdW5kIHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5IGVu
ZHBvaW50cyAodGhlIHJlc291cmNlIGFuZC9vciB0aGUgb2F1dGggc2VydmljZSBkaXNjb3Zlcnkp
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiBhIGNs
aWVudCBkaXNjb3ZlcnMgYSBmYWtlIHJlc291cmNlIHNlcnZlciB0aGF0IGlzIHByb3h5aW5nIGZv
ciBhIHJlYWwgcmVzb3VyY2Ugc2VydmVyIHRoZSBjdXJyZW50IGRpc2NvdmVyeSBzcGVjIHdpbGwg
bm90IGxlYWQgdGhlIGNsaWVudCB0byB1bmRlcnN0YW5kIGl0IGhhcyB0aGUgd3JvbmcgcmVzb3Vy
Y2Ugc2VydmVyLiBSYXRoZXIgdGhlIGZha2UgcmVzb3VyY2Ugc2VydmljZSB3aWxsIGp1c3QgaGF2
ZSBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRlcmNlcHQg
cmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2VyZSBhYmxl
IHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0aW9uIHNl
cnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIE9BdXRoIERpc2Nv
dmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0aGF0IHRoZSBzZXJ2
ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291cmNlIGVuZHBvaW50
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG5v
dCBvbmx5IHdvcmtzIGluIG5vcm1hbCBPQXV0aCBidXQgc2hvdWxkIGFkZCBzZWN1cml0eSBldmVu
IHRvIFVNQSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5QaGlsPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0
cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+
cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5PbiBGZWIgMjQsIDIwMTYsIGF0IDM6NTQgQU0sIE5hdCBTYWtpbXVy
YSA8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj4mbHQ7c2FraW11cmFAZ21haWwu
Y29tJmd0OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkhpIFRob21hcywgPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+aW5saW5lOiA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4yMDE2
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1z
ZXJpZiI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdv
dGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjI8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYi
PuaciDwvc3Bhbj4pIDE4OjQ0IFRob21hcyBCcm95ZXIgPGEgaHJlZj0ibWFpbHRvOnQuYnJveWVy
QGdtYWlsLmNvbSI+Jmx0O3QuYnJveWVyQGdtYWlsLmNvbSZndDs8L2E+OjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkNvdWxkbid0IHRoZSBkb2N1bWVudCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0
YT88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIHF1aXRlIGxpa2UgdGhlIGlkZWEgb2YgZHJhZnQt
c2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZG8gZGlzY292ZXJ5LCBh
bmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0byBvdGhlciBzcGVjcyB0byBkZWZp
bmUgYSAud2VsbC1rbm93biBVUkwgZm9yICZxdW90O2F1dG8tY29uZmlndXJhdGlvbiZxdW90Oy48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291bGQg
dGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMgZHJhZnQt
c2FraW11cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMgZm9y
IG90aGVyIG1ldGFkYXRhIHNwZWNzIChsaWtlIE9wZW5JRCBDb25uZWN0KS4gPG86cD48L286cD48
L3ByZT4NCjxwcmU+V2l0aCBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJ3MgJnF1b3Q7ZHVyaSZx
dW90OyBhbmQgdGhlICZxdW90O3Njb3BlJnF1b3Q7IGF0dHJpYnV0ZSBvZiBXV1ctQXV0aGVudGlj
YXRlIHJlc3BvbnNlIGhlYWRlciwgeW91IGhhdmUgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBwcm9j
ZWVkIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWwsIGlzIGl0
IG5vdD8mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+SW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlvdSBu
ZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Tbywg
dGhlIHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIGVpdGhlciB0aGUgbG9j
YXRpb24gb2YgdGhlIGF1dGh6IGVuZHBvaW50LiBJbiBzb21lIHRydXN0ZWQgZW52aXJvbm1lbnQs
IHRoZSByZXNvdXJjZSBtYXkgYXMgd2VsbCByZXR1cm4gdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRo
eiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5vdCBo
YXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlzIGZy
ZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29sbGlz
aW9ucyBldGMuIFdlIHNob3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFjZSBh
cyBtdWNoIGFzIHBvc3NpYmxlLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4od2VsbCwgZXhjZXB0IGlmIHRoZXJlIGFyZSBzZXZlcmFsIEFTcyBl
YWNoIHdpdGggZGlmZmVyZW50IHNjb3Blczsgc291bmRzIGxpa2UgYW4gZWRnZS1jYXNlIHRvIG1l
IHRob3VnaDsgbWF5YmUgUkZDNjc1MCBzaG91bGQgaW5zdGVhZCBiZSB1cGRhdGVkIHdpdGggc3Vj
aCBhIHBhcmFtZXRlciBzdWNoIHRoYXQgYW4gUlMgY291bGQgcmV0dXJuIHNldmVyYWwgV1dXLUF1
dGhlbnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRzIG93biAmcXVvdDtzY29wZSZxdW90OyBh
bmQgJnF1b3Q7ZHVyaSZxdW90OyB2YWx1ZT8pPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlllYWgsIEkgZ3Vlc3MgaXQgaXMgYW4gZWRnZSBjYXNlLiBJIHdv
dWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2ZXJzIHRvIGRldmVsb3AgYSB0
cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdyZWUgb24gYSBzaW5nbGUgc2V0
IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DaGVlcnMsIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5hdDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiBGcmksIEZlYiAxOSwgMjAxNiBh
dCAxMDo1OSBQTSBKdXN0aW4gUmljaGVyIDxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUi
PiZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5UaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBh
bmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxs
IGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9u
ZSBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNlIG9m
IOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292ZXJ5
IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBPcGVu
SUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFzb24g
dG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlzbS48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHByb3Bvc2UgdGhh
dCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIGFz
IHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5kIHN0YXRlIHRoYXQgdGhlIGRvY3Vt
ZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29u
ZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28gcHJvdmlkZXMgT3BlbklEIENvbm5lY3Qg
b24gdGhlIHNhbWUgZG9tYWluLiBPdGhlciBhcHBsaWNhdGlvbnMgU0hPVUxEIHVzZSB0aGUgc2Ft
ZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5kcG9pbnRzIGFuZCBmdW5jdGlv
bnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292ZXJ5IGRvY3VtZW50LjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiDigJQgSnVz
dGluPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxp
c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci
Pk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo
cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B
dXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBp
ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWls
aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0
Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+
PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1pciBEemh1dmlub3Yg
OjogPGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIj52bGFkaW1pckBjb25u
ZWN0MmlkLmNvbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_BY2PR03MB4425461F4C68FAAABC422BDF5A60BY2PR03MB442namprd_--


From nobody Thu Feb 25 11:20:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECB1B325E for ; Thu, 25 Feb 2016 11:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S022JDJoT5c for ; Thu, 25 Feb 2016 11:20:04 -0800 (PST)
Received: from omr-m017e.mx.aol.com (omr-m017e.mx.aol.com [204.29.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCCD1B325D for ; Thu, 25 Feb 2016 11:20:04 -0800 (PST)
Received: from mtaout-mcb01.mx.aol.com (mtaout-mcb01.mx.aol.com [172.26.50.173]) by omr-m017e.mx.aol.com (Outbound Mail Relay) with ESMTP id 1F9083800085; Thu, 25 Feb 2016 14:20:03 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mcb01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3A43538000098; Thu, 25 Feb 2016 14:20:02 -0500 (EST)
To: Mike Jones , Vladimir Dzhuvinov , "oauth@ietf.org" 
References:     <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56CF53ED.2050609@aol.com>
Date: Thu, 25 Feb 2016 14:20:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030302010702030105050304"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456428003; bh=3KMokQvytB3Hhj9wS7Huz+LTCCKIf3uTtlIRF/rTkRU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=4swLjsfIsOex+HcuJA86xP0Wcz1Z1XrgnvBIMNiL6S+mwYCkaQKp2NleZrKKuNhfo ga4SSYl77BU4U1PqXtY3jc2tBPb17oXwbNpLn80pGtqUWk9QcaHO4iIMZC7Pk2PQ8l CP5k4922PPtL8aPne/eSQCX3ZFNSVpd8L21v2j4Q=
x-aol-sid: 3039ac1a32ad56cf53e22016
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 19:20:11 -0000

This is a multi-part message in MIME format.
--------------030302010702030105050304
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

+1 for “OAuth 2.0 Authorization Server Discoveryâ€

On 2/25/16 2:10 PM, Mike Jones wrote:
>
> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to 
> accept your suggestion to change the title from “OAuth 2.0 Discovery†
> to “OAuth 2.0 Authorization Server Discoveryâ€. While the abstract 
> already makes it clear that the scope of the document is AS discovery, 
> doing so in the title seems like it could help clarify things, given 
> that a lot of the discussion seems to be about resource discovery, 
> which is out of scope of the document.
>
> I’m not saying that resource discovery isn’t important – it is – but 
> unlike authorization server discovery, where there’s lots of existing 
> practice, including using the existing data format for describing 
> OAuth implementations that aren’t being used with OpenID Connect, 
> there’s no existing practice to standardize for resource discovery.  
> The time to create a standard for that seems to be after existing 
> practice has emerged.  It **might** or might not use new metadata 
> values in the AS discovery document, but that’s still to be 
> determined.  The one reason to leave the title as-is is that resource 
> discovery might end up involving extensions to this metadata format in 
> some cases.
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 
> applies.  6749 is about the AS.  6750 is about the RS.  The discovery 
> document is about the AS.  We don’t yet have a specification or 
> existing practice for RS discovery, which would be the 6750 analogy.
>
> In summary, which title do people prefer?
>
> ·“OAuth 2.0 Discoveryâ€
>
> ·“OAuth 2.0 Authorization Server Discoveryâ€
>
> -- Mike
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vladimir 
> Dzhuvinov
> *Sent:* Thursday, February 25, 2016 12:59 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> In OIDC the discovery doc is of great utility to developers and 
> integrators. Developers also tend to find it a more accurate and 
> complete description of how to set up a client for a particular 
> deployment, compared to traditional online docs, which may be not be 
> up to date, or even missing. Very much like auto-generated Swagger and 
> JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration
>
> https://www.paypalobjects.com/.well-known/openid-configuration
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>
>
> With this discovery document in place setup of identity federation can 
> then be easily scripted. For example:
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>
>
> Now, does that dictate any particular app architecture? My reading of 
> the spec is that it doesn't, and it shouldn't either. By staying 
> neutral on the topics of RS discovery and registering RPs with RSs. 
> And how one arrives at the ".well-known/...". I'm not even sure that 
> resource discovery should be a topic of this WG. Perhaps to this end, 
> and to prevent confusion that the spec is trying to do something more, 
> a more specific title would suit it better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
>     And so does oracle and so does google. Each different.
>
>     So how can an app dictate it then unless we all go to a common architecture?
>
>     Phil
>
>         On Feb 24, 2016, at 16:04, Mike Jones   wrote:
>
>         Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server.  You can call that custom architecture if you want.  It’s well-defined but it’s not currently in the standards realm.  I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
>           
>
>         In this sense, yes, Azure is an application of the kind we’re talking about.  Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production.  A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
>           
>
>                                                                          -- Mike
>
>           
>
>         From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
>
>         Sent: Wednesday, February 24, 2016 3:52 PM
>
>         To: Mike Jones
>
>         Cc: 
>
>         Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         Mike
>
>           
>
>         Take a look at the assumptions you are making.
>
>           
>
>         You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
>           
>
>         Would ms azure allow custom arch?
>
>         Phil
>
>         On Feb 24, 2016, at 15:28, Mike Jones   wrote:
>
>         The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
>           
>
>         I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server.  Working group members have also described wanting to discover authorization servers starting from resource servers.  There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
>           
>
>         Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them.  Some of those values will likely define ways to discover resource servers, when applicable.
>
>           
>
>         But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
>           
>
>                                                                          -- Mike
>
>           
>
>         From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
>
>         Sent: Wednesday, February 24, 2016 2:13 PM
>
>         To: Mike Jones 
>
>         Cc:    
>
>         Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
>           
>
>         The userinfo is always fix and so u dont need discovery.
>
>         Phil
>
>         On Feb 24, 2016, at 14:05, Mike Jones   wrote:
>
>         In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure.  Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint†metadata value, which is defined athttp://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>
>           
>
>         We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group.  For instance, see George Fletcher’s recent contribution.
>
>           
>
>         Thanks for the good discussion, Phil.
>
>           
>
>                                                                          -- Mike
>
>           
>
>         From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
>
>         Sent: Wednesday, February 24, 2016 1:25 PM
>
>         To: Mike Jones
>
>         Cc: 
>
>         Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
>         Phil
>
>         On Feb 24, 2016, at 13:09, Mike Jones   wrote:
>
>         To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use.  That what this draft accomplishes.
>
>           
>
>         There’s nothing Connect-specific about using metadata response values like:
>
>           
>
>             "authorization_endpoint":"https://server.example.com/authorize"
>         ,
>
>             "token_endpoint":"https://server.example.com/token"
>         ,
>
>             "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
>
>             "registration_endpoint":"https://server.example.com/register"
>         ,
>
>             "response_types_supported":  ["code", "token"],
>
>             "service_documentation":"http://server.example.com/service_documentation.html"
>         ,
>
>           
>
>         Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different?  I don’t see any good reason for unnecessary differences to be introduced.
>
>           
>
>                                                                          -- Mike
>
>           
>
>         From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]
>
>         Sent: Wednesday, February 24, 2016 12:45 PM
>
>         To: Anthony Nadalin 
>
>         Cc: Mike Jones ;    
>
>         Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         Mike
>
>           
>
>         Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
>           
>
>         The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
>         Phil
>
>         On Feb 24, 2016, at 10:25, Anthony Nadalin   wrote:
>
>         Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
>           
>
>         From: Mike Jones
>
>         Sent: Wednesday, February 24, 2016 10:22 AM
>
>         To: Anthony Nadalin 
>
>         Cc:    
>
>         Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format.  “Security by obscurity†adds no real security at all.
>
>           
>
>                                                                    -- Mike
>
>           
>
>         From: Anthony Nadalin
>
>         Sent: Wednesday, February 24, 2016 10:01 AM
>
>         To: Mike Jones ; Phil Hunt (IDM) ; Nat Sakimura 
>
>         Cc:    
>
>         Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>             The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
>           
>
>         That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations  section at all
>
>           
>
>         From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>
>         Sent: Wednesday, February 24, 2016 9:54 AM
>
>         To: Phil Hunt (IDM) ; Nat Sakimura 
>
>         Cc:    
>
>         Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
>           
>
>         None of Nat or John or I are suggesting that additional related functionality won’t be created.  I’m sure it will be.  Some applications will use WebFinger to locate the discovery metadata.  Some will possibly use link headers.  Some will possibly use application-specific .well-known values.  I’m sure there’s other things I haven’t even thought about.  All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
>           
>
>         So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts.  At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
>           
>
>                                                                    -- Mike
>
>           
>
>         From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
>
>         Sent: Wednesday, February 24, 2016 8:39 AM
>
>         To: Nat Sakimura 
>
>         Cc:    
>
>         Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>           
>
>         I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
>           
>
>         So if res.example.evil.com is not a valid resource endpoint for as.example.com the authz discovery should fail in some way (eg return nothing).
>
>           
>
>         There may be better ways to do this. Eg combine discovery. Or change the order of discovery.
>
>           
>
>         One of OAuth's strength's and weaknesses is that the target of authorization (the resource) is never specified. It is often bound up in the client registration and an often implied 1:1 relationship between resource and as. Given that in discovery phase registration has not yet occurred it seems important that the client know it has a valid combination of endpoints etc.
>
>           
>
>         This is why I was disappointed about wglc on discovery. We had a starting point for group adoption but we haven't really defined the full requirements IMO.
>
>           
>
>         I am on vacation or I would put some thought into some draft changes or a new draft. I apologize I can't do it now.
>
>         Phil
>
>         On Feb 24, 2016, at 08:12, Nat Sakimura   wrote:
>
>         Hi Phil,
>
>           
>
>         Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
>           
>
>         The way oauth-meta works is that
>
>           
>
>         1. RS tells the client where the AS is.
>
>         2. AS tells the client which RS endpoints the token can be used.
>
>           
>
>         Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
>         Nat
>
>           
>
>         2016年2月24日(水) 23:59 Phil Hunt :
>
>         Nat,
>
>           
>
>         I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
>           
>
>         If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
>           
>
>         The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
>           
>
>         This not only works in normal OAuth but should add security even to UMA situations.
>
>           
>
>         Phil
>
>           
>
>         @independentid
>
>         www.independentid.com 
>
>         phil.hunt@oracle.com 
>
>           
>
>           
>
>           
>
>           
>
>         On Feb 24, 2016, at 3:54 AM, Nat Sakimura   wrote:
>
>           
>
>         Hi Thomas,
>
>           
>
>         inline:
>
>           
>
>         2016年2月22日(月) 18:44 Thomas Broyer :
>
>         Couldn't the document only describe the metadata?
>
>         I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>
>         The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>
>         With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
>           
>
>         Yup. That's one of the requirements to be RESTful, is it not?
>
>           
>
>         In OAuth's case, the resource and the authorization server are usually tightly coupled. (Otherwise, you need another specs like UMA.)
>
>         So, the resource server should be able to tell either the location of the authz endpoint. In some trusted environment, the resource may as well return the location of the authz server configuration data. In these cases, you do not have to decide on what .well-known uri as you say. This frees up developers from configuration file location collisions etc. We should strive not to pollute the uri space as much as possible.
>
>           
>
>         (well, except if there are several ASs each with different scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>
>           
>
>         Yeah, I guess it is an edge case. I would rather like to see these authz servers to develop a trust framework under which they can agree on a single set of common scope parameter values.
>
>           
>
>         Cheers,
>
>           
>
>         Nat
>
>           
>
>           
>
>         On Fri, Feb 19, 2016 at 10:59 PM Justin Richer   wrote:
>
>         The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration†in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
>         I propose that we use “/.well-known/oauth-authorization-server†as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration†if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
>           — Justin
>
>         _______________________________________________
>
>         OAuth mailing list
>
>         OAuth@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>         _______________________________________________
>
>         OAuth mailing list
>
>         OAuth@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>         _______________________________________________
>
>         OAuth mailing list
>
>         OAuth@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>           
>
>         _______________________________________________
>
>         OAuth mailing list
>
>         OAuth@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>     _______________________________________________
>
>     OAuth mailing list
>
>     OAuth@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> -- 
> Vladimir Dzhuvinov ::vladimir@connect2id.com 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------030302010702030105050304
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1 for “OAuth
      2.0 Authorization Server Discoveryâ€

    

    
On 2/25/16 2:10 PM, Mike Jones wrote:

    

    

      
      
      
      

        
Thanks
            for your thoughts, Vladimir.  I’m increasingly inclined to
            accept your suggestion to change the title from “OAuth 2.0
            Discovery†to “OAuth 2.0 Authorization Server Discoveryâ€. 
            While the abstract already makes it clear that the scope of
            the document is AS discovery, doing so in the title seems
            like it could help clarify things, given that a lot of the
            discussion seems to be about resource discovery, which is
            out of scope of the document.

        
 

        
I’m
            not saying that resource discovery isn’t important – it is –
            but unlike authorization server discovery, where there’s
            lots of existing practice, including using the existing data
            format for describing OAuth implementations that aren’t
            being used with OpenID Connect, there’s no existing practice
            to standardize for resource discovery.  The time to create a
            standard for that seems to be after existing practice has
            emerged.  It *might* or might not use new metadata
            values in the AS discovery document, but that’s still to be
            determined.  The one reason to leave the title as-is is that
            resource discovery might end up involving extensions to this
            metadata format in some cases.

        
 

        
I
            think an analogy to the core OAuth documents RFC 6749 and
            RFC 6750 applies.  6749 is about the AS.  6750 is about the
            RS.  The discovery document is about the AS.  We don’t yet
            have a specification or existing practice for RS discovery,
            which would be the 6750 analogy.

        
 

        
In
            summary, which title do people prefer?

        
·      
              “OAuth
            2.0 Discoveryâ€

        
·      
              “OAuth
            2.0 Authorization Server Discoveryâ€

        
 

        
                                                         
            -- Mike

        
 

        
        

          

            
From:
                OAuth [mailto:oauth-bounces@ietf.org]
                On Behalf Of Vladimir Dzhuvinov

                Sent: Thursday, February 25, 2016 12:59 AM

                To: oauth@ietf.org

                Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery
                Location

          

        

        
 

        
In OIDC the
          discovery doc is of great utility to developers and
          integrators. Developers also tend to find it a more accurate
          and complete description of how to set up a client for a
          particular deployment, compared to traditional online docs,
          which may be not be up to date, or even missing. Very much
          like auto-generated Swagger and JavaDocs.

          

          Here are some example OIDC discovery docs:

          

          https://accounts.google.com/.well-known/openid-configuration

          

          https://www.paypalobjects.com/.well-known/openid-configuration

          

          https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration

          

          

          With this discovery document in place setup of identity
          federation can then be easily scripted. For example:

          

          http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

          

          

          Now, does that dictate any particular app architecture? My
          reading of the spec is that it doesn't, and it shouldn't
          either. By staying neutral on the topics of RS discovery and
          registering RPs with RSs. And how one arrives at the
          ".well-known/...". I'm not even sure that resource discovery
          should be a topic of this WG. Perhaps to this end, and to
          prevent confusion that the spec is trying to do something
          more, a more specific title would suit it better. E.g. "AS
          Discovery".

          

          Cheers,

          

          Vladimir

          

          

          

          

        

          
On 25/02/16 02:25, Phil Hunt (IDM) wrote:

        

        

          
And so does oracle and so does google. Each different. 

          
 

          
So how can an app dictate it then unless we all go to a common architecture?

          
 

          
Phil

          
 

          

            
On Feb 24, 2016, at 16:04, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server.  You can call that custom architecture if you want.  It’s well-defined but it’s not currently in the standards realm.  I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.

            
 

            
In this sense, yes, Azure is an application of the kind we’re talking about.  Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production.  A registry just doesn’t yet exist in which it can register those that are of general applicability.

            
 

            
                                                                -- Mike

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 3:52 PM

            
To: Mike Jones

            
Cc: <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
Mike

            
 

            
Take a look at the assumptions you are making. 

            
 

            
You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.  

            
 

            
Would ms azure allow custom arch?

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
The UserInfo Endpoint path isn’t fixed and so has to be discovered.

            
 

            
I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server.  Working group members have also described wanting to discover authorization servers starting from resource servers.  There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.

            
 

            
Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them.  Some of those values will likely define ways to discover resource servers, when applicable.

            
 

            
But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.

            
 

            
                                                                -- Mike

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 2:13 PM

            
To: Mike Jones <Michael.Jones@microsoft.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit. 

            
 

            
The userinfo is always fix and so u dont need discovery. 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure.  Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint†metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.

            
 

            
We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group.  For instance, see George Fletcher’s recent contribution.

            
 

            
Thanks for the good discussion, Phil.

            
 

            
                                                                -- Mike

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 1:25 PM

            
To: Mike Jones

            
Cc: <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list). 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use.  That what this draft accomplishes.

            
 

            
There’s nothing Connect-specific about using metadata response values like:

            
 

            
   "authorization_endpoint": "https://server.example.com/authorize",

            
   "token_endpoint": "https://server.example.com/token",

            
   "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],

            
   "registration_endpoint": "https://server.example.com/register",

            
   "response_types_supported":  ["code", "token"],

            
   "service_documentation": "http://server.example.com/service_documentation.html",

            
 

            
Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different?  I don’t see any good reason for unnecessary differences to be introduced.

            
 

            
                                                                -- Mike

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 12:45 PM

            
To: Anthony Nadalin <tonynad@microsoft.com>

            
Cc: Mike Jones <Michael.Jones@microsoft.com>; <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
Mike

            
 

            
Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers. 

            
 

            
The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time. 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> wrote:

            
 

            
Sure there is, it is as you have now made it far easier and the security considerations does not even address this

            
 

            
From: Mike Jones 

            
Sent: Wednesday, February 24, 2016 10:22 AM

            
To: Anthony Nadalin <tonynad@microsoft.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format.  “Security by obscurity†adds no real security at all.

            
 

            
                                                          -- Mike

            
 

            
From: Anthony Nadalin 

            
Sent: Wednesday, February 24, 2016 10:01 AM

            
To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            

              
The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.

            

            
 

            
That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations  section at all

            
 

            
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones

            
Sent: Wednesday, February 24, 2016 9:54 AM

            
To: Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.

            
 

            
None of Nat or John or I are suggesting that additional related functionality won’t be created.  I’m sure it will be.  Some applications will use WebFinger to locate the discovery metadata.  Some will possibly use link headers.  Some will possibly use application-specific .well-known values.  I’m sure there’s other things I haven’t even thought about.  All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.

            
 

            
So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts.  At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.

            
 

            
                                                          -- Mike

            
 

            
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)

            
Sent: Wednesday, February 24, 2016 8:39 AM

            
To: Nat Sakimura <sakimura@gmail.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

            
 

            
I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for. 

            
 

            
So if res.example.evil.com is not a valid resource endpoint for as.example.com the authz discovery should fail in some way (eg return nothing). 

            
 

            
There may be better ways to do this. Eg combine discovery. Or change the order of discovery. 

            
 

            
One of OAuth's strength's and weaknesses is that the target of authorization (the resource) is never specified. It is often bound up in the client registration and an often implied 1:1 relationship between resource and as. Given that in discovery phase registration has not yet occurred it seems important that the client know it has a valid combination of endpoints etc. 

            
 

            
This is why I was disappointed about wglc on discovery. We had a starting point for group adoption but we haven't really defined the full requirements IMO. 

            
 

            
I am on vacation or I would put some thought into some draft changes or a new draft. I apologize I can't do it now. 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:

            
 

            
Hi Phil, 

            
 

            
Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess. 

            
 

            
The way oauth-meta works is that 

            
 

            
1. RS tells the client where the AS is. 

            
2. AS tells the client which RS endpoints the token can be used. 

            
 

            
Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to. 

            
 

            
Nat

            
 

            
2016年2月24日(水) 23:59 Phil Hunt <phil.hunt@oracle.com>:

            
Nat,

            
 

            
I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).

            
 

            
If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.

            
 

            
The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.

            
 

            
This not only works in normal OAuth but should add security even to UMA situations.

            
 

            
Phil

            
 

            
@independentid

            
www.independentid.com

            
phil.hunt@oracle.com

            
 

            
 

            
 

            
 

            
 

            
On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> wrote:

            
 

            
 

            
Hi Thomas, 

            
 

            
inline: 

            
 

            
2016年2月22日(月) 18:44 Thomas Broyer <t.broyer@gmail.com>:

            
Couldn't the document only describe the metadata?

            
I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".

            
The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect). 

            
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed 

            
 

            
Yup. That's one of the requirements to be RESTful, is it not?  

            
 

            
In OAuth's case, the resource and the authorization server are usually tightly coupled. (Otherwise, you need another specs like UMA.) 

            
So, the resource server should be able to tell either the location of the authz endpoint. In some trusted environment, the resource may as well return the location of the authz server configuration data. In these cases, you do not have to decide on what .well-known uri as you say. This frees up developers from configuration file location collisions etc. We should strive not to pollute the uri space as much as possible. 

            
 

            
(well, except if there are several ASs each with different scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)

            
 

            
Yeah, I guess it is an edge case. I would rather like to see these authz servers to develop a trust framework under which they can agree on a single set of common scope parameter values. 

            
 

            
Cheers, 

            
 

            
Nat

            
 

            
 

            
 

            
On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:

            
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration†in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

            
 

            
I propose that we use “/.well-known/oauth-authorization-server†as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration†if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.

            
 

            
 — Justin

            
_______________________________________________

            
OAuth mailing list

            
OAuth@ietf.org

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

            
_______________________________________________

            
OAuth mailing list

            
OAuth@ietf.org

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

            
_______________________________________________

            
OAuth mailing list

            
OAuth@ietf.org

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

            
 

            
_______________________________________________

            
OAuth mailing list

            
OAuth@ietf.org

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

          

          
 

          


            

            

            

          
_______________________________________________

          
OAuth mailing list

          
OAuth@ietf.org

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

        

        


          

          

        
-- 

        
Vladimir Dzhuvinov :: vladimir@connect2id.com

      

      

      

      

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


    

    

  


--------------030302010702030105050304--


From nobody Thu Feb 25 11:52:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AF61B32B9 for ; Thu, 25 Feb 2016 11:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.156
X-Spam-Level: 
X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxfzERzViiJT for ; Thu, 25 Feb 2016 11:52:25 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id BA42C1B336D for ; Thu, 25 Feb 2016 11:52:25 -0800 (PST)
Received: (qmail 4028 invoked by uid 0); 25 Feb 2016 19:52:25 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 25 Feb 2016 19:52:25 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw3 with  id NqsF1s00k2is6CS01qsJa0; Thu, 25 Feb 2016 19:52:22 -0700
X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=rE68L1KyjUoA:10 a=zwqKzj3qmOAA:10 a=jFJIQSaiL_oA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=UGkfVyPCAAAA:8 a=yMhMjlubAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=NM0YaXG2AAAA:8 a=evN3UIMlAAAA:8 a=o3_0C12-AAAA:8 a=vggBfdFIAAAA:8 a=yPCof4ZbAAAA:8 a=is3RsFX7AAAA:8 a=A1X0JdhQAAAA:8 a=pGLkceISAAAA:8 a=fLVUkWqjAAAA:8 a=IqETP1_tAAAA:8 a=0z2PRw3EdQiAstwqMtYA:9 a=kaD2v796efRw7ndl:21 a=XH3NV38YMB4f9fQh:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=mjqp06U6--QA:10 a=jl1lMIPSATsA:10 a=xO_-FbM1n3EA:10 a=SSmOFEACAAAA:8 a=ntjbG0LyeLq2fSg1vJIA:9 a=S9OOEizZj-_wDbDh:21 a=rDriyWInyDxwzsHk:21 a=fS0XLUHfbHjupC9r:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=w/a0sx2c/O9g6RvHVqF1RWpsFFXM8bcH6hprLknsU1s=;  b=LoYNKcby0CUuL9CM5CzAnp4ckOXlkxuIzbsPa26WEiWFSdEYzclz74sEpD9bQhvw+oVQ5/RSH9/0DxOSUDbA4FY3Ywtj/fEYznqQJmtGYWfBhs8SOBEIvXxOMze4whyQ;
Received: from [162.206.229.38] (port=5523 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1aZ1xR-0006id-J5; Thu, 25 Feb 2016 12:52:18 -0700
From: "Donald F. Coffin" 
To: "'Mike Jones'" , "'Vladimir Dzhuvinov'" , 
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com> 
In-Reply-To: 
Date: Thu, 25 Feb 2016 14:50:06 -0500
Organization: REMI Networks
Message-ID: <016d01d17005$bb87ed90$3297c8b0$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016E_01D16FDB.D2B6C790"
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQErEGUxIthpCNQAgVnbL+9JTvjuPAHC1bISAhjsDgMBsnWuVwHQOV5DAdctzpoB6fP6OgJXYFR+AYtm9pYCRenD+QKjF4gVAdciSDEBKNzRkALyCc6EAPqP9j0CO2mxA5+hT5tg
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 162.206.229.38 authed with donald.coffin@reminetworks.com}
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 19:52:32 -0000

This is a multipart message in MIME format.

------=_NextPart_000_016E_01D16FDB.D2B6C790
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D

=20

Best regards,

Don

Donald F. Coffin

Founder/CTO

=20

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

=20

Phone:      (949) 636-8571

Email:         =
donald.coffin@reminetworks.com

=20

From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
Sent: Thursday, February 25, 2016 2:10 PM
To: Vladimir Dzhuvinov ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

=20

Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined =
to accept your suggestion to change the title from =E2=80=9COAuth 2.0 =
Discovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D.  While the abstract already makes it clear that the =
scope of the document is AS discovery, doing so in the title seems like =
it could help clarify things, given that a lot of the discussion seems =
to be about resource discovery, which is out of scope of the document.

=20

I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93 but unlike authorization server discovery, =
where there=E2=80=99s lots of existing practice, including using the =
existing data format for describing OAuth implementations that =
aren=E2=80=99t being used with OpenID Connect, there=E2=80=99s no =
existing practice to standardize for resource discovery.  The time to =
create a standard for that seems to be after existing practice has =
emerged.  It *might* or might not use new metadata values in the AS =
discovery document, but that=E2=80=99s still to be determined.  The one =
reason to leave the title as-is is that resource discovery might end up =
involving extensions to this metadata format in some cases.

=20

I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  The discovery =
document is about the AS.  We don=E2=80=99t yet have a specification or =
existing practice for RS discovery, which would be the 6750 analogy.

=20

In summary, which title do people prefer?

*         =E2=80=9COAuth 2.0 Discovery=E2=80=9D

*         =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D

=20

                                                          -- Mike

=20

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir =
Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: oauth@ietf.org =20
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

=20

In OIDC the discovery doc is of great utility to developers and =
integrators. Developers also tend to find it a more accurate and =
complete description of how to set up a client for a particular =
deployment, compared to traditional online docs, which may be not be up =
to date, or even missing. Very much like auto-generated Swagger and =
JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-=
known/openid-configuration


With this discovery document in place setup of identity federation can =
then be easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create=
_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one =
arrives at the ".well-known/...". I'm not even sure that resource =
discovery should be a topic of this WG. Perhaps to this end, and to =
prevent confusion that the spec is trying to do something more, a more =
specific title would suit it better. E.g. "AS Discovery".

Cheers,

Vladimir




On 25/02/16 02:25, Phil Hunt (IDM) wrote:

And so does oracle and so does google. Each different.=20
=20
So how can an app dictate it then unless we all go to a common =
architecture?
=20
Phil
=20

On Feb 24, 2016, at 16:04, Mike Jones  =
  =
wrote:
=20
Azure defines ways for resource servers to be registered for use with a =
client and for clients to dynamically request an access token for use at =
a particular resource server.  You can call that custom architecture if =
you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in =
the standards realm.  I know that Google has syntax for doing the same, =
as I=E2=80=99m sure do a lot of other cloud OAuth deployments, such as =
Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working group talked =
about possibly producing a standard version of syntax for making these =
kinds of requests during our discussions in Prague (during the Token =
Exchange discussion) but nobody has run with this yet.
=20
In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 =
discovery metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc:   
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Mike
=20
Take a look at the assumptions you are making.=20
=20
You seem to be assuming application software dictates oauth =
infrastructure architecture by suggesting that apps register in iana. =20
=20
Would ms azure allow custom arch?
=20
Phil
=20
On Feb 24, 2016, at 15:28, Mike Jones  =
  =
wrote:
=20
The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be =
discovered.
=20
I agree that for some OAuth profiles, one or more resource servers will =
have to be discovered starting from the authorization server.  Working =
group members have also described wanting to discover authorization =
servers starting from resource servers.  There isn=E2=80=99t a standard =
practice for any of this, which is why it=E2=80=99s intentionally left =
out of the current specification.
=20
Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it =
will be easy for subsequent specifications to document existing practice =
for different OAuth profiles and register discovery metadata values =
supporting them.  Some of those values will likely define ways to =
discover resource servers, when applicable.
=20
But first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones   =

Cc:      =

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Yup. And because there many relations the client mist be able to =
discover it. The client does not know if the res server is legit.=20
=20
The userinfo is always fix and so u dont need discovery.=20
=20
Phil
=20
On Feb 24, 2016, at 14:05, Mike Jones  =
  =
wrote:
=20
In OpenID Connect, there=E2=80=99s a resource server called the UserInfo =
Endpoint that returns claims about the authenticated user as a JSON data =
structure.  Its location is published in OpenID Connect discovery =
metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, =
which is defined at =
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadat=
a.
=20
We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they =
needn=E2=80=99t be one-to-one, as is being actively discussed by the =
working group.  For instance, see George Fletcher=E2=80=99s recent =
contribution.
=20
Thanks for the good discussion, Phil.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc:   
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Where is the profile endpoint (oidc's resource server) published? (For =
the non OIDC people on the list).=20
=20
Phil
=20
On Feb 24, 2016, at 13:09, Mike Jones  =
  =
wrote:
=20
To the extent that generic OAuth 2.0 needs to publish some of the same =
information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly =
the same syntax, since that syntax is already in widespread use.  That =
what this draft accomplishes.
=20
There=E2=80=99s nothing Connect-specific about using metadata response =
values like:
=20
   "authorization_endpoint":   =
"https://server.example.com/authorize",
   "token_endpoint":   =
"https://server.example.com/token",
   "token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
   "registration_endpoint":   =
"https://server.example.com/register",
   "response_types_supported":  ["code", "token"],
   "service_documentation":  =
 =
"http://server.example.com/service_documentation.html",
=20
Is there a reason that you would like the syntax for any of these or the =
other generally applicable OAuth 2.0 metadata values to be different?  I =
don=E2=80=99t see any good reason for unnecessary differences to be =
introduced.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com]=20
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin   =

Cc: Mike Jones   =
;    =
  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Mike
=20
Publishing on dev pages does not work for software (esp open source) =
that is deployed both in enterprises and on PaaS cloud providers.=20
=20
The current draft is may codify current OIDC practice and be appropriate =
for oidc but it is not ready for generic oauth. There is no generic =
oauth experience at this time.=20
=20
Phil
=20
On Feb 24, 2016, at 10:25, Anthony Nadalin  =
  wrote:
=20
Sure there is, it is as you have now made it far easier and the security =
considerations does not even address this
=20
From: Mike Jones=20
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin   =

Cc:      =

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
As we=E2=80=99d discussed in person, there=E2=80=99s no effective =
security difference between discovery information being published in an =
ad-hoc fashion on developer pages and it being published in a standard =
format.  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security =
at all.
=20
                                                          -- Mike
=20
From: Anthony Nadalin=20
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones   =
; Phil Hunt (IDM)  =
 ; Nat Sakimura  =
 
Cc:      =

Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
=20

The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.

=20
That may be widely deployed for OIDC but not widely deployed for OAuth. =
There are some authentication mechanism discovery for endpoint that =
really should not be in an OAuth standard since it=E2=80=99s really not =
dealt with. Now that all this information is available it makes poking =
around the endpoint more focused for people that want to disrupt your =
endpoints, that is really not addressed in the security considerations  =
section at all
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM)   =
; Nat Sakimura   =

Cc:      =

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
=20
None of Nat or John or I are suggesting that additional related =
functionality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  =
Some applications will use WebFinger to locate the discovery metadata.  =
Some will possibly use link headers.  Some will possibly use =
application-specific .well-known values.  I=E2=80=99m sure =
there=E2=80=99s other things I haven=E2=80=99t even thought about.  All =
of these depend upon having a discovery metadata document format and =
none of them change it =E2=80=93 other than possibly to register =
additional discovery metadata values.
=20
So by all means, the working group should continue discussing inventing =
possible new related mechanisms that make sense in some contexts.  At =
the same time, we can finish standardizing the already widely deployed =
core functionality that all of these mechanisms will need.
=20
                                                          -- Mike
=20
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura   
Cc:      =

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
I am suggesting that part of the discovery solution has to be the client =
indicating what resource endpoint it wants the oauth configuration data =
for.=20
=20
So if res.example.evil.com is not a valid resource endpoint for =
as.example.com the authz discovery should fail in some way (eg return =
nothing).=20
=20
There may be better ways to do this. Eg combine discovery. Or change the =
order of discovery.=20
=20
One of OAuth's strength's and weaknesses is that the target of =
authorization (the resource) is never specified. It is often bound up in =
the client registration and an often implied 1:1 relationship between =
resource and as. Given that in discovery phase registration has not yet =
occurred it seems important that the client know it has a valid =
combination of endpoints etc.=20
=20
This is why I was disappointed about wglc on discovery. We had a =
starting point for group adoption but we haven't really defined the full =
requirements IMO.=20
=20
I am on vacation or I would put some thought into some draft changes or =
a new draft. I apologize I can't do it now.=20
=20
Phil
=20
On Feb 24, 2016, at 08:12, Nat Sakimura   =
 wrote:
=20
Hi Phil,=20
=20
Are you suggesting that the AS metadata should include the RS URIs? =
Currently, it does not, but it can be done, I guess.=20
=20
The way oauth-meta works is that=20
=20
1. RS tells the client where the AS is.=20
2. AS tells the client which RS endpoints the token can be used.=20
=20
Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will =
say that is not the place the client may want to send the token to.=20
=20
Nat
=20
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt  =
 :
Nat,
=20
I=E2=80=99m not sure that having the resource server tell the client =
where its authorization server is secure by itself. The relationship =
between the Authorization Server and the Resource server need to be =
bound together in one of the discovery endpoints (the resource and/or =
the oauth service discovery).
=20
If a client discovers a fake resource server that is proxying for a real =
resource server the current discovery spec will not lead the client to =
understand it has the wrong resource server. Rather the fake resource =
service will just have a fake discovery service. The hacker can now =
intercept resource payload as well as tokens because they were able to =
convince the client to use the legit authorization service but use the =
token against the hackers proxy.
=20
The OAuth Discovery service needs to confirm to the client that the =
server is able to issue tokens for a stated resource endpoint.
=20
This not only works in normal OAuth but should add security even to UMA =
situations.
=20
Phil
=20
@independentid
www.independentid.com =20
phil.hunt@oracle.com =20
=20
=20
=20
=20
=20
On Feb 24, 2016, at 3:54 AM, Nat Sakimura   =
 wrote:
=20
=20
Hi Thomas,=20
=20
inline:=20
=20
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer  =
 :
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to =
do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, =
returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis =
for other metadata specs (like OpenID Connect).=20
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed=20
=20
Yup. That's one of the requirements to be RESTful, is it not? =20
=20
In OAuth's case, the resource and the authorization server are usually =
tightly coupled. (Otherwise, you need another specs like UMA.)=20
So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as =
well return the location of the authz server configuration data. In =
these cases, you do not have to decide on what .well-known uri as you =
say. This frees up developers from configuration file location =
collisions etc. We should strive not to pollute the uri space as much as =
possible.=20
=20
(well, except if there are several ASs each with different scopes; =
sounds like an edge-case to me though; maybe RFC6750 should instead be =
updated with such a parameter such that an RS could return several =
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
=20
Yeah, I guess it is an edge case. I would rather like to see these authz =
servers to develop a trust framework under which they can agree on a =
single set of common scope parameter values.=20
=20
Cheers,=20
=20
Nat
=20
=20
=20
On Fri, Feb 19, 2016 at 10:59 PM Justin Richer   =
 wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the =
right direction. It does, however, still have too many vestiges of its =
OpenID Connect origins. One issue in particular still really bothers me: =
the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the =
discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
=20
I propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery document.
=20
 =E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org =20
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org =20
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org =20
https://www.ietf.org/mailman/listinfo/oauth
=20
_______________________________________________
OAuth mailing list
OAuth@ietf.org =20
https://www.ietf.org/mailman/listinfo/oauth

=20





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

=20

--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com =
=20

------=_NextPart_000_016E_01D16FDB.D2B6C790
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+1 for =
=E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D=

 <=
/span>
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO
 
REMI =
Networks
2335 =
Dunwoody Xing #E
Dunwoody, GA =
30338-8221
 
Phone:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571
Email:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com
 <=
/span>
From: Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: =
Thursday, February 25, 2016 2:10 PM
To: Vladimir Dzhuvinov =
<vladimir@connect2id.com>; oauth@ietf.org
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery =
Location
 
Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly =
inclined to accept your suggestion to change the title from =
=E2=80=9COAuth 2.0 Discovery=E2=80=9D to =E2=80=9COAuth 2.0 =
Authorization Server Discovery=E2=80=9D.  While the abstract =
already makes it clear that the scope of the document is AS discovery, =
doing so in the title seems like it could help clarify things, given =
that a lot of the discussion seems to be about resource discovery, which =
is out of scope of the document.
 
I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93 but unlike authorization server discovery, =
where there=E2=80=99s lots of existing practice, including using the =
existing data format for describing OAuth implementations that =
aren=E2=80=99t being used with OpenID Connect, there=E2=80=99s no =
existing practice to standardize for resource discovery.  The time =
to create a standard for that seems to be after existing practice has =
emerged.  It *might* or might not use new metadata values in =
the AS discovery document, but that=E2=80=99s still to be =
determined.  The one reason to leave the title as-is is that =
resource discovery might end up involving extensions to this metadata =
format in some cases.
 
I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  =
The discovery document is about the AS.  We don=E2=80=99t yet have =
a specification or existing practice for RS discovery, which would be =
the 6750 analogy.
 
In summary, which title do people prefer?
=C2=B7         =
=E2=80=9COAuth 2.0 Discovery=E2=80=9D
=C2=B7         =
=E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D
 
            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;         -- =
Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, =
February 25, 2016 12:59 AM
To: oauth@ietf.org
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery =
Location
 
In OIDC the discovery doc is of great =
utility to developers and integrators. Developers also tend to find it a =
more accurate and complete description of how to set up a client for a =
particular deployment, compared to traditional online docs, which may be =
not be up to date, or even missing. Very much like auto-generated =
Swagger and JavaDocs.

Here are some example OIDC discovery =
docs:

htt=
ps://accounts.google.com/.well-known/openid-configuration

h=
ttps://www.paypalobjects.com/.well-known/openid-configuration

=
https://login.microsoftonline.com/fab=
rikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration

With this discovery document in place setup of identity federation =
can then be easily scripted. For example:

http://docs.aws.amazon.com/IAM/late=
st/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

Now, does that dictate any particular app architecture? My =
reading of the spec is that it doesn't, and it shouldn't either. By =
staying neutral on the topics of RS discovery and registering RPs with =
RSs. And how one arrives at the ".well-known/...". I'm not =
even sure that resource discovery should be a topic of this WG. Perhaps =
to this end, and to prevent confusion that the spec is trying to do =
something more, a more specific title would suit it better. E.g. =
"AS =
Discovery".

Cheers,

Vladimir


On 25/02/16 02:25, Phil Hunt (IDM) =
wrote:
And so does oracle =
and so does google. Each different. =

 
So how can an app =
dictate it then unless we all go to a common =
architecture?
 
Phil<=
/o:p>
 
On Feb 24, 2016, at =
16:04, Mike Jones <Michael.Jones@microsoft.c=
om> wrote:
 
Azure =
defines ways for resource servers to be registered for use with a client =
and for clients to dynamically request an access token for use at a =
particular resource server.  You can call that custom architecture =
if you want.  It=E2=80=99s well-defined but it=E2=80=99s not =
currently in the standards realm.  I know that Google has syntax =
for doing the same, as I=E2=80=99m sure do a lot of other cloud OAuth =
deployments, such as Oracle=E2=80=99s.  For what it=E2=80=99s =
worth, the working group talked about possibly producing a standard =
version of syntax for making these kinds of requests during our =
discussions in Prague (during the Token Exchange discussion) but nobody =
has run with this yet.
 
In =
this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 =
discovery metadata values that are used in production.  A registry =
just doesn=E2=80=99t yet exist in which it can register those that are =
of general applicability.
 =

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

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: Wednesday, February 24, 2016 3:52 =
PM
To: Mike Jones
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 =

Mike
 =

Take a look at the assumptions you are making. =

 
You seem to be =
assuming application software dictates oauth infrastructure architecture =
by suggesting that apps register in iana.  =

 
Would ms azure allow =
custom =
arch?
 
Phil
 
On Feb 24, 2016, at 15:28, Mike =
Jones <Michael.Jones@microsoft.c=
om> wrote:
 
The =
UserInfo Endpoint path isn=E2=80=99t fixed and so has to be =
discovered.
 
I agree that for =
some OAuth profiles, one or more resource servers will have to be =
discovered starting from the authorization server.  Working group =
members have also described wanting to discover authorization servers =
starting from resource servers.  There isn=E2=80=99t a standard =
practice for any of this, which is why it=E2=80=99s intentionally left =
out of the current specification.
 =

Once the IANA OAuth Discovery Metadata Registry =
has been established, which will happen after the current specification =
has been approved, it will be easy for subsequent specifications to =
document existing practice for different OAuth profiles and register =
discovery metadata values supporting them.  Some of those values =
will likely define ways to discover resource servers, when =
applicable.
 
But first, we =
need to finish the existing spec, so that the registry enabling these =
extensions gets established in the first place.
 =

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

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: Wednesday, February 24, 2016 2:13 =
PM
To: Mike Jones <Michael.Jones@microsoft.c=
om>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
Yup. And because =
there many relations the client mist be able to discover it. The client =
does not know if the res server is legit. =

 
The userinfo is always =
fix and so u dont need discovery. =

 
Phil
 
On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.c=
om> wrote:
 
In =
OpenID Connect, there=E2=80=99s a resource server called the UserInfo =
Endpoint that returns claims about the authenticated user as a JSON data =
structure.  Its location is published in OpenID Connect discovery =
metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, =
which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#Prov=
iderMetadata.
 
We =
didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they =
needn=E2=80=99t be one-to-one, as is being actively discussed by the =
working group.  For instance, see George Fletcher=E2=80=99s recent =
contribution.
 
Thanks for the =
good discussion, Phil.
 =

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

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: Wednesday, February 24, 2016 1:25 =
PM
To: Mike Jones
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
Where is the =
profile endpoint (oidc's resource server) published? (For the non OIDC =
people on the list). =

 
Phil
 
On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.c=
om> wrote:
 
To =
the extent that generic OAuth 2.0 needs to publish some of the same =
information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly =
the same syntax, since that syntax is already in widespread use.  =
That what this draft accomplishes.
 =

There=E2=80=99s nothing Connect-specific about =
using metadata response values like:
 =

   "authorization_endpoint"=
;: "https://server.exampl=
e.com/authorize",
   =
"token_endpoint": "https://server.example.co=
m/token",
   =
"token_endpoint_auth_methods_supported": =
["client_secret_basic", =
"private_key_jwt"],
   =
"registration_endpoint": "https://server.example=
.com/register",
   =
"response_types_supported":  ["code", =
"token"],
  =
 "service_documentation": "http:=
//server.example.com/service_documentation.html",
 
Is there a reason that you would like the =
syntax for any of these or the other generally applicable OAuth 2.0 =
metadata values to be different?  I don=E2=80=99t see any good =
reason for unnecessary differences to be =
introduced.
 =

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

From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: Wednesday, February 24, 2016 12:45 =
PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Mike Jones <Michael.Jones@microsoft.c=
om>; <oauth@ietf.org> =
<oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 =

Mike
 =

Publishing on dev pages does not work for software =
(esp open source) that is deployed both in enterprises and on PaaS cloud =
providers. 
 
The current =
draft is may codify current OIDC practice and be appropriate for oidc =
but it is not ready for generic oauth. There is no generic oauth =
experience at this time. =

 
Phil
 
On Feb 24, 2016, at 10:25, Anthony =
Nadalin <tonynad@microsoft.com> =
wrote:
 
Sure there is, =
it is as you have now made it far easier and the security considerations =
does not even address this
 =

From: Mike Jones 
Sent: =
Wednesday, February 24, 2016 10:22 AM
To: Anthony =
Nadalin <tonynad@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
As we=E2=80=99d =
discussed in person, there=E2=80=99s no effective security difference =
between discovery information being published in an ad-hoc fashion on =
developer pages and it being published in a standard format. =
 =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security at =
all.
 =

        &nb=
sp;           &nbs=
p;            =
;            =
            &=
nbsp;-- Mike
 
From: Anthony =
Nadalin 
Sent: Wednesday, February 24, 2016 10:01 =
AM
To: Mike Jones <Michael.Jones@microsoft.c=
om>; Phil Hunt (IDM) <phil.hunt@oracle.com>; =
Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
The point of the =
WGLC is to finish standardizing the core discovery functionality =
that=E2=80=99s already widely =
deployed.
 
That =
may be widely deployed for OIDC but not widely deployed for OAuth. There =
are some authentication mechanism discovery for endpoint that really =
should not be in an OAuth standard since it=E2=80=99s really not dealt =
with. Now that all this information is available it makes poking around =
the endpoint more focused for people that want to disrupt your =
endpoints, that is really not addressed in the security =
considerations  section at all
 =

From: OAuth [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Mike Jones
Sent: Wednesday, February =
24, 2016 9:54 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>; =
Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
The point of the =
WGLC is to finish standardizing the core discovery functionality =
that=E2=80=99s already widely deployed.
 =

None of Nat or John or I are suggesting that =
additional related functionality won=E2=80=99t be created.  =
I=E2=80=99m sure it will be.  Some applications will use WebFinger =
to locate the discovery metadata.  Some will possibly use link =
headers.  Some will possibly use application-specific .well-known =
values.  I=E2=80=99m sure there=E2=80=99s other things I =
haven=E2=80=99t even thought about.  All of these depend upon =
having a discovery metadata document format and none of them change it =
=E2=80=93 other than possibly to register additional discovery metadata =
values.
 
So by all means, the =
working group should continue discussing inventing possible new related =
mechanisms that make sense in some contexts.  At the same time, we =
can finish standardizing the already widely deployed core functionality =
that all of these mechanisms will need.
 =

        &nb=
sp;           &nbs=
p;            =
;            =
            &=
nbsp;-- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, =
February 24, 2016 8:39 AM
To: Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
I am suggesting =
that part of the discovery solution has to be the client indicating what =
resource endpoint it wants the oauth configuration data for. =

 
So if =
res.example.evil.com is not a valid resource endpoint for as.example.com =
the authz discovery should fail in some way (eg return nothing). =

 
There may be better =
ways to do this. Eg combine discovery. Or change the order of discovery. =

 
One of OAuth's =
strength's and weaknesses is that the target of authorization (the =
resource) is never specified. It is often bound up in the client =
registration and an often implied 1:1 relationship between resource and =
as. Given that in discovery phase registration has not yet occurred it =
seems important that the client know it has a valid combination of =
endpoints etc. 
 
This is =
why I was disappointed about wglc on discovery. We had a starting point =
for group adoption but we haven't really defined the full requirements =
IMO. 
 
I am on vacation =
or I would put some thought into some draft changes or a new draft. I =
apologize I can't do it now. =

 
Phil
 
On Feb 24, 2016, at 08:12, Nat Sakimura =
<sakimura@gmail.com> =
wrote:
 
Hi Phil, =

 
Are you suggesting =
that the AS metadata should include the RS URIs? Currently, it does not, =
but it can be done, I guess. =

 
The way oauth-meta =
works is that 
 
1. RS =
tells the client where the AS is. 
2. AS tells the =
client which RS endpoints the token can be used. =

 
Even if there is a bad =
AS with a valid certs that proxies to the good RS, the client will not =
send the token there as the authz server will say that is not the place =
the client may want to send the token to. =

 
Nat
 
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hunt@oracle.com>:
Nat,
 =

I=E2=80=99m not sure that having the resource =
server tell the client where its authorization server is secure by =
itself. The relationship between the Authorization Server and the =
Resource server need to be bound together in one of the discovery =
endpoints (the resource and/or the oauth service =
discovery).
 
If a client =
discovers a fake resource server that is proxying for a real resource =
server the current discovery spec will not lead the client to understand =
it has the wrong resource server. Rather the fake resource service will =
just have a fake discovery service. The hacker can now intercept =
resource payload as well as tokens because they were able to convince =
the client to use the legit authorization service but use the token =
against the hackers proxy.
 =

The OAuth Discovery service needs to confirm to =
the client that the server is able to issue tokens for a stated resource =
endpoint.
 
This not only =
works in normal OAuth but should add security even to UMA =
situations.
 =

Phil
 =

@independentid
www.independentid.com
phil.hunt@oracle.com<=
/pre>
 =

 
 
=

 
 
On Feb 24, 2016, =
at 3:54 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:
 =

 
Hi Thomas, =

 
inline: =

 
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 =
Thomas Broyer <t.broyer@gmail.com>:
Couldn't the document only describe the =
metadata?
I quite like the idea of =
draft-sakimura-oauth-meta if you really want to do discovery, and leave =
it open to implementers / to other specs to define a .well-known URL for =
"auto-configuration".
The metadata =
described here would then either be used as-is, at any URL, returned as =
draft-sakimura-oauth-meta metadata at the RS; or as a basis for other =
metadata specs (like OpenID Connect). 
With =
draft-sakimura-oauth-meta's "duri" and the "scope" =
attribute of WWW-Authenticate response header, you have everything you =
need to proceed 
 
Yup. =
That's one of the requirements to be RESTful, is it not?  =

 
In OAuth's case, the =
resource and the authorization server are usually tightly coupled. =
(Otherwise, you need another specs like UMA.) 
So, =
the resource server should be able to tell either the location of the =
authz endpoint. In some trusted environment, the resource may as well =
return the location of the authz server configuration data. In these =
cases, you do not have to decide on what .well-known uri as you say. =
This frees up developers from configuration file location collisions =
etc. We should strive not to pollute the uri space as much as possible. =

 
(well, except if there =
are several ASs each with different scopes; sounds like an edge-case to =
me though; maybe RFC6750 should instead be updated with such a parameter =
such that an RS could return several WWW-Authenticate: Bearer, each with =
its own "scope" and "duri" =
value?)
 
Yeah, I guess it is =
an edge case. I would rather like to see these authz servers to develop =
a trust framework under which they can agree on a single set of common =
scope parameter values. =

 
Cheers, =

 
Nat
 =

 
 
=

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> =
wrote:
The newly-trimmed OAuth Discovery document =
is helpful and moving in the right direction. It does, however, still =
have too many vestiges of its OpenID Connect origins. One issue in =
particular still really bothers me: the use of =
=E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery =
portion. Is this an OAuth discovery document, or an OpenID Connect one? =
There is absolutely no compelling reason to tie the URL to the OIDC =
discovery mechanism.
 
I =
propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery =
document.
 
 =E2=80=94 =
Justin
_____________________________________________=
__
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
________________________=
_______________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
________________________=
_______________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 =

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



______________=
_________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 
-- =

Vladimir Dzhuvinov :: vladimir@connect2id.com<=
/o:p>

------=_NextPart_000_016E_01D16FDB.D2B6C790--


From nobody Thu Feb 25 11:57:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA71B33AA for ; Thu, 25 Feb 2016 11:57:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UXLWuNDVP_z for ; Thu, 25 Feb 2016 11:57:41 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6089A1B33A7 for ; Thu, 25 Feb 2016 11:57:38 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id a4so42900197wme.1 for ; Thu, 25 Feb 2016 11:57:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=p4FDjD4ECYrg810NWwHELCZE+8PRMyCxwRY/3JhCTQk=; b=mgtAxcXcwxrfO436kM9Ei0dSuH8XLX/cwsuD8ELdbEL/TSO331sjU4QXNTnXnS+8bO yktpy2RWHUXJ7GtcMs7lERbFith+14OsiRxF1tRnYic5KTZL6SKPbaCaWG/yRfKCKwdd X4oDiFKRJQwQIuasly5rlyMMP3LQEj/GlqHjzFCmRS/6GZQx5wIXEcTt+G2XyDoIkW4I dgCD4DjOf3Aoml05jGRMPQDDi0V0x1X5a7kuJdN3Q7v2yKJWyjx60NlmHR+bplcC0tu1 ze4NELde1UguFv0+dkOrZUQAmmUACQCrbAoPirS8BvPQ8LCQGDprTWjKb/hTVrwcIxxy MbMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=p4FDjD4ECYrg810NWwHELCZE+8PRMyCxwRY/3JhCTQk=; b=QORCIXgQxFvnyQ+RSidTDPYOafWchJPCRXCc/xY1HoBaKmRKHP92H4nVsZFqq/4xvk TWxkvZaiejJlF0+/zQksH0n7cDQTsuaqyat8vyLhC70AOsEFlrjYmVObpIpfw5XEFc+a PaD5c0yF2Ge+V6n8XxkWHLCxHrwap45IdzElEcKQePZh4Oo7uxWN2g3SfcEq2ixJrhHW 3Cp30w0pDYRPcPpvtmvqgHEcmB+3Rc3abaGAu1AiH26iyZx0MlNcGVov1XBUpA/Sd0uP 8ozQAJqUquqRXBiwsVcuq6bSi+Gfux1A2TDOYps080q1cL/LGCjiX3uf6c7f9suMe6rK 1GUQ==
X-Gm-Message-State: AG10YOSYhcuyubS2kmJFmNWG3y3pRnptQCt3hAKutSyDfw57aQrg4R4Pz0NtGxgRfCsIJQ==
X-Received: by 10.28.92.195 with SMTP id q186mr401712wmb.37.1456430256711; Thu, 25 Feb 2016 11:57:36 -0800 (PST)
Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id r62sm4676290wmd.15.2016.02.25.11.57.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Feb 2016 11:57:35 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C4C5776B-08CC-4E6D-9B02-F232E86B767D"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 25 Feb 2016 20:57:32 +0100
Message-Id: <639703A2-B47D-4533-AF2D-0DE51D024ADB@ve7jtb.com>
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com> 
To: Michael Jones 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2016 19:57:49 -0000

--Apple-Mail=_C4C5776B-08CC-4E6D-9B02-F232E86B767D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6C7A6A2F-85B6-4F95-968B-389B5EB553DE"


--Apple-Mail=_6C7A6A2F-85B6-4F95-968B-389B5EB553DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Authorization server discovery.

> On Feb 25, 2016, at 8:10 PM, Mike Jones  =
wrote:
>=20
> Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined =
to accept your suggestion to change the title from =E2=80=9COAuth 2.0 =
Discovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D.  While the abstract already makes it clear that the =
scope of the document is AS discovery, doing so in the title seems like =
it could help clarify things, given that a lot of the discussion seems =
to be about resource discovery, which is out of scope of the document.
> =20
> I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93 but unlike authorization server discovery, =
where there=E2=80=99s lots of existing practice, including using the =
existing data format for describing OAuth implementations that aren=E2=80=99=
t being used with OpenID Connect, there=E2=80=99s no existing practice =
to standardize for resource discovery.  The time to create a standard =
for that seems to be after existing practice has emerged.  It *might* or =
might not use new metadata values in the AS discovery document, but =
that=E2=80=99s still to be determined.  The one reason to leave the =
title as-is is that resource discovery might end up involving extensions =
to this metadata format in some cases.
> =20
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  The discovery =
document is about the AS.  We don=E2=80=99t yet have a specification or =
existing practice for RS discovery, which would be the 6750 analogy.
> =20
> In summary, which title do people prefer?
> =C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
> =C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
> =20
>                                                           -- Mike
> =C2=A0 <>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir =
Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> In OIDC the discovery doc is of great utility to developers and =
integrators. Developers also tend to find it a more accurate and =
complete description of how to set up a client for a particular =
deployment, compared to traditional online docs, which may be not be up =
to date, or even missing. Very much like auto-generated Swagger and =
JavaDocs.
>=20
> Here are some example OIDC discovery docs:
>=20
> https://accounts.google.com/.well-known/openid-configuration =

>=20
> https://www.paypalobjects.com/.well-known/openid-configuration =

>=20
> =
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-k=
nown/openid-configuration =

>=20
>=20
> With this discovery document in place setup of identity federation can =
then be easily scripted. For example:
>=20
> =
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_=
oidc_verify-thumbprint.html =

>=20
>=20
> Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one =
arrives at the ".well-known/...". I'm not even sure that resource =
discovery should be a topic of this WG. Perhaps to this end, and to =
prevent confusion that the spec is trying to do something more, a more =
specific title would suit it better. E.g. "AS Discovery".
>=20
> Cheers,
>=20
> Vladimir
>=20
>=20
>=20
>=20
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> And so does oracle and so does google. Each different.=20
> =20
> So how can an app dictate it then unless we all go to a common =
architecture?
> =20
> Phil
> =20
> On Feb 24, 2016, at 16:04, Mike Jones  =
 wrote:
> =20
> Azure defines ways for resource servers to be registered for use with =
a client and for clients to dynamically request an access token for use =
at a particular resource server.  You can call that custom architecture =
if you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently =
in the standards realm.  I know that Google has syntax for doing the =
same, as I=E2=80=99m sure do a lot of other cloud OAuth deployments, =
such as Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working =
group talked about possibly producing a standard version of syntax for =
making these kinds of requests during our discussions in Prague (during =
the Token Exchange discussion) but nobody has run with this yet.
> =20
> In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 =
discovery metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Take a look at the assumptions you are making.=20
> =20
> You seem to be assuming application software dictates oauth =
infrastructure architecture by suggesting that apps register in iana. =20=

> =20
> Would ms azure allow custom arch?
> =20
> Phil
> =20
> On Feb 24, 2016, at 15:28, Mike Jones  =
 wrote:
> =20
> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be =
discovered.
> =20
> I agree that for some OAuth profiles, one or more resource servers =
will have to be discovered starting from the authorization server.  =
Working group members have also described wanting to discover =
authorization servers starting from resource servers.  There isn=E2=80=99t=
 a standard practice for any of this, which is why it=E2=80=99s =
intentionally left out of the current specification.
> =20
> Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it =
will be easy for subsequent specifications to document existing practice =
for different OAuth profiles and register discovery metadata values =
supporting them.  Some of those values will likely define ways to =
discover resource servers, when applicable.
> =20
> But first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones  =

> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Yup. And because there many relations the client mist be able to =
discover it. The client does not know if the res server is legit.=20
> =20
> The userinfo is always fix and so u dont need discovery.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 14:05, Mike Jones  =
 wrote:
> =20
> In OpenID Connect, there=E2=80=99s a resource server called the =
UserInfo Endpoint that returns claims about the authenticated user as a =
JSON data structure.  Its location is published in OpenID Connect =
discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata =
value, which is defined at =
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata=
 =
.
> =20
> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they needn=E2=80=99=
t be one-to-one, as is being actively discussed by the working group.  =
For instance, see George Fletcher=E2=80=99s recent contribution.
> =20
> Thanks for the good discussion, Phil.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Where is the profile endpoint (oidc's resource server) published? (For =
the non OIDC people on the list).=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 13:09, Mike Jones  =
 wrote:
> =20
> To the extent that generic OAuth 2.0 needs to publish some of the same =
information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly =
the same syntax, since that syntax is already in widespread use.  That =
what this draft accomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response =
values like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize" =
,
>    "token_endpoint": "https://server.example.com/token" =
,
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register" =
,
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": =
"http://server.example.com/service_documentation.html" =
,
> =20
> Is there a reason that you would like the syntax for any of these or =
the other generally applicable OAuth 2.0 metadata values to be =
different?  I don=E2=80=99t see any good reason for unnecessary =
differences to be introduced.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin  =

> Cc: Mike Jones  =
;  =
  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) =
that is deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be =
appropriate for oidc but it is not ready for generic oauth. There is no =
generic oauth experience at this time.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  =
 wrote:
> =20
> Sure there is, it is as you have now made it far easier and the =
security considerations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin  =

> Cc:    =

> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective =
security difference between discovery information being published in an =
ad-hoc fashion on developer pages and it being published in a standard =
format.  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security =
at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones  =
; Phil Hunt (IDM) =
 ; Nat Sakimura =
 
> Cc:    =

> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for =
OAuth. There are some authentication mechanism discovery for endpoint =
that really should not be in an OAuth standard since it=E2=80=99s really =
not dealt with. Now that all this information is available it makes =
poking around the endpoint more focused for people that want to disrupt =
your endpoints, that is really not addressed in the security =
considerations  section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM)  =
; Nat Sakimura  =

> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related =
functionality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  =
Some applications will use WebFinger to locate the discovery metadata.  =
Some will possibly use link headers.  Some will possibly use =
application-specific .well-known values.  I=E2=80=99m sure there=E2=80=99s=
 other things I haven=E2=80=99t even thought about.  All of these depend =
upon having a discovery metadata document format and none of them change =
it =E2=80=93 other than possibly to register additional discovery =
metadata values.
> =20
> So by all means, the working group should continue discussing =
inventing possible new related mechanisms that make sense in some =
contexts.  At the same time, we can finish standardizing the already =
widely deployed core functionality that all of these mechanisms will =
need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura  
> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the =
client indicating what resource endpoint it wants the oauth =
configuration data for.=20
> =20
> So if res.example.evil.com is not a valid resource endpoint for =
as.example.com the authz discovery should fail in some way (eg return =
nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change =
the order of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of =
authorization (the resource) is never specified. It is often bound up in =
the client registration and an often implied 1:1 relationship between =
resource and as. Given that in discovery phase registration has not yet =
occurred it seems important that the client know it has a valid =
combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a =
starting point for group adoption but we haven't really defined the full =
requirements IMO.=20
> =20
> I am on vacation or I would put some thought into some draft changes =
or a new draft. I apologize I can't do it now.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 08:12, Nat Sakimura  =
 wrote:
> =20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? =
Currently, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will =
say that is not the place the client may want to send the token to.=20
> =20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt =
 :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client =
where its authorization server is secure by itself. The relationship =
between the Authorization Server and the Resource server need to be =
bound together in one of the discovery endpoints (the resource and/or =
the oauth service discovery).
> =20
> If a client discovers a fake resource server that is proxying for a =
real resource server the current discovery spec will not lead the client =
to understand it has the wrong resource server. Rather the fake resource =
service will just have a fake discovery service. The hacker can now =
intercept resource payload as well as tokens because they were able to =
convince the client to use the legit authorization service but use the =
token against the hackers proxy.
> =20
> The OAuth Discovery service needs to confirm to the client that the =
server is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to =
UMA situations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
> =20
> =20
> =20
> =20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  =
 wrote:
> =20
> =20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
 :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any =
URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a =
basis for other metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually =
tightly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as =
well return the location of the authz server configuration data. In =
these cases, you do not have to decide on what .well-known uri as you =
say. This frees up developers from configuration file location =
collisions etc. We should strive not to pollute the uri space as much as =
possible.=20
> =20
> (well, except if there are several ASs each with different scopes; =
sounds like an edge-case to me though; maybe RFC6750 should instead be =
updated with such a parameter such that an RS could return several =
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these =
authz servers to develop a trust framework under which they can agree on =
a single set of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
> =20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  =
 wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
> =20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery =
document.
> =20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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

>=20
>=20
> --=20
> Vladimir Dzhuvinov :: vladimir@connect2id.com =
__________________________________________=
_____
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_6C7A6A2F-85B6-4F95-968B-389B5EB553DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Authorization server discovery.

On =
Feb 25, 2016, at 8:10 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for your thoughts, =
Vladimir.  I=E2=80=99m increasingly inclined to accept your =
suggestion to change the title from =E2=80=9COAuth 2.0 Discovery=E2=80=9D =
to =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D.  =
While the abstract already makes it clear that the scope of the document =
is AS discovery, doing so in the title seems like it could help clarify =
things, given that a lot of the discussion seems to be about resource =
discovery, which is out of scope of the document.
 
I=E2=80=
=99m not saying that resource discovery isn=E2=80=99t important =E2=80=93 =
it is =E2=80=93 but unlike authorization server discovery, where =
there=E2=80=99s lots of existing practice, including using the existing =
data format for describing OAuth implementations that aren=E2=80=99t =
being used with OpenID Connect, there=E2=80=99s no existing practice to =
standardize for resource discovery.  The time to create a standard =
for that seems to be after existing practice has emerged.  It *might* or might not use new metadata values in the AS =
discovery document, but that=E2=80=99s still to be determined.  The =
one reason to leave the title as-is is that resource discovery might end =
up involving extensions to this metadata format in some cases.
 
I =
think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  =
The discovery document is about the AS.  We don=E2=80=99t yet have =
a specification or existing practice for RS discovery, which would be =
the 6750 analogy.
 
In summary, which title =
do people prefer?
=C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
=C2=B7       =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of Vladimir =
Dzhuvinov
Sent: Thursday, February 25, 2016 =
12:59 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 =
Discovery Location
 
In OIDC the discovery doc is of =
great utility to developers and integrators. Developers also tend to =
find it a more accurate and complete description of how to set up a =
client for a particular deployment, compared to traditional online docs, =
which may be not be up to date, or even missing. Very much like =
auto-generated Swagger and JavaDocs.

Here =
are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration<=
/a>

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v=
2.0/.well-known/openid-configuration


With this discovery document in place setup of identity =
federation can then be easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_provid=
ers_create_oidc_verify-thumbprint.html


Now, does that dictate any particular app =
architecture? My reading of the spec is that it doesn't, and it =
shouldn't either. By staying neutral on the topics of RS discovery and =
registering RPs with RSs. And how one arrives at the ".well-known/...". =
I'm not even sure that resource discovery should be a topic of this WG. =
Perhaps to this end, and to prevent confusion that the spec is trying to =
do something more, a more specific title would suit it better. E.g. "AS =
Discovery".

Cheers,

Vladimir



On 25/02/16 02:25, Phil Hunt (IDM) wrote:
And so does =
oracle and so does google. Each different. 
 
So how can an =
app dictate it then unless we all go to a common architecture?
 
Phil
 
On Feb 24, =
2016, at 16:04, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Azure defines =
ways for resource servers to be registered for use with a client and for =
clients to dynamically request an access token for use at a particular =
resource server.  You can call that custom architecture if you =
want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in =
the standards realm.  I know that Google has syntax for doing the =
same, as I=E2=80=99m sure do a lot of other cloud OAuth deployments, =
such as Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working =
group talked about possibly producing a standard version of syntax for =
making these kinds of requests during our discussions in Prague (during =
the Token Exchange discussion) but nobody has run with this yet.
 
In this sense, =
yes, Azure is an application of the kind we=E2=80=99re talking =
about.  Azure already does define specific new OAuth 2.0 discovery =
metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: =
Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
Mike
 
Take a look at =
the assumptions you are making. 
 
You seem to be assuming application software =
dictates oauth infrastructure architecture by suggesting that apps =
register in iana.  
 
Would ms azure allow custom arch?
 
Phil
 
On Feb 24, =
2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
The UserInfo =
Endpoint path isn=E2=80=99t fixed and so has to be discovered.
 
I agree that =
for some OAuth profiles, one or more resource servers will have to be =
discovered starting from the authorization server.  Working group =
members have also described wanting to discover authorization servers =
starting from resource servers.  There isn=E2=80=99t a standard =
practice for any of this, which is why it=E2=80=99s intentionally left =
out of the current specification.
 
Once the IANA OAuth Discovery Metadata =
Registry has been established, which will happen after the current =
specification has been approved, it will be easy for subsequent =
specifications to document existing practice for different OAuth =
profiles and register discovery metadata values supporting them.  =
Some of those values will likely define ways to discover resource =
servers, when applicable.
 
But =
first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: =
Wednesday, February 24, 2016 2:13 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Yup. And because there many relations the =
client mist be able to discover it. The client does not know if the res =
server is legit. 
 
The=
 userinfo is always fix and so u dont need discovery. 
 
Phil
 
On Feb 24, =
2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
In OpenID =
Connect, there=E2=80=99s a resource server called the UserInfo Endpoint =
that returns claims about the authenticated user as a JSON data =
structure.  Its location is published in OpenID Connect discovery =
metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, =
which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#Provi=
derMetadata.
 =

We didn=E2=80=99t=
 include the UserInfo Endpoint in the generic OAuth discovery spec since =
in OAuth, there are lots of possible relationships between authorization =
servers and resource servers and they needn=E2=80=99t be one-to-one, as =
is being actively discussed by the working group.  For instance, =
see George Fletcher=E2=80=99s recent contribution.
 
Thanks for the =
good discussion, Phil.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: =
Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
Where is the =
profile endpoint (oidc's resource server) published? (For the non OIDC =
people on the list). 
 
Phil
 
On Feb 24, =
2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
To the extent =
that generic OAuth 2.0 needs to publish some of the same information as =
OpenID Connect =E2=80=93 which is built on generic OAuth 2.0 =E2=80=93 =
it makes sense to publish that information using exactly the same =
syntax, since that syntax is already in widespread use.  That what =
this draft accomplishes.
 
There=E2=80=99s nothing Connect-specific about using metadata =
response values like:
 
   "authorization_endpoint": "https://server.example.com/authorize",
   =
"token_endpoint": "https://server.example.com/token",
   =
"token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
   "registration_endpoint": "https://server.example.com/register",
   =
"response_types_supported":  ["code", "token"],
  =
 "service_documentation": "http://server.example.com/service_documentation.html",
 
Is there a =
reason that you would like the syntax for any of these or the other =
generally applicable OAuth 2.0 metadata values to be different?  I =
don=E2=80=99t see any good reason for unnecessary differences to be =
introduced.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] =

Sent: =
Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Mike Jones =
<Michael.Jones@microsoft.com>; <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Mike
 
Publishing on dev pages does not work for =
software (esp open source) that is deployed both in enterprises and on =
PaaS cloud providers. 
 
The=
 current draft is may codify current OIDC practice and be appropriate =
for oidc but it is not ready for generic oauth. There is no generic =
oauth experience at this time. 
 
Phil
 
On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> =
wrote:
 
Sure there is, =
it is as you have now made it far easier and the security considerations =
does not even address this
 
From: Mike Jones 
Sent: =
Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: RE: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
As we=E2=80=99d discussed in person, =
there=E2=80=99s no effective security difference between discovery =
information being published in an ad-hoc fashion on developer pages and =
it being published in a standard format.  =E2=80=9CSecurity by =
obscurity=E2=80=9D adds no real security at all.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- =
Mike
 
From: Anthony =
Nadalin 
Sent: =
Wednesday, February 24, 2016 10:01 AM
To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; =
Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
The point of =
the WGLC is to finish standardizing the core discovery functionality =
that=E2=80=99s already widely deployed.
 
That may be =
widely deployed for OIDC but not widely deployed for OAuth. There are =
some authentication mechanism discovery for endpoint that really should =
not be in an OAuth standard since it=E2=80=99s really not dealt with. =
Now that all this information is available it makes poking around the =
endpoint more focused for people that want to disrupt your endpoints, =
that is really not addressed in the security considerations  =
section at all
 
From: OAuth [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt =
(IDM) <phil.hunt@oracle.com>; =
Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location
 
The point of =
the WGLC is to finish standardizing the core discovery functionality =
that=E2=80=99s already widely deployed.
 
None of Nat or John or I are suggesting that =
additional related functionality won=E2=80=99t be created.  I=E2=80=99=
m sure it will be.  Some applications will use WebFinger to locate =
the discovery metadata.  Some will possibly use link headers.  =
Some will possibly use application-specific .well-known values.  =
I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even =
thought about.  All of these depend upon having a discovery =
metadata document format and none of them change it =E2=80=93 other than =
possibly to register additional discovery metadata values.
 
So by all =
means, the working group should continue discussing inventing possible =
new related mechanisms that make sense in some contexts.  At the =
same time, we can finish standardizing the already widely deployed core =
functionality that all of these mechanisms will need.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- =
Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org]=
 On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 =
AM
To: Nat =
Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
I am suggesting that part of the discovery =
solution has to be the client indicating what resource endpoint it wants =
the oauth configuration data for. 
 
So if res.example.evil.com is not a valid resource endpoint for =
as.example.com the =
authz discovery should fail in some way (eg return nothing). 
 
There may be =
better ways to do this. Eg combine discovery. Or change the order of =
discovery. 
 
One=
 of OAuth's strength's and weaknesses is that the target of =
authorization (the resource) is never specified. It is often bound up in =
the client registration and an often implied 1:1 relationship between =
resource and as. Given that in discovery phase registration has not yet =
occurred it seems important that the client know it has a valid =
combination of endpoints etc. 
 
This is why I was disappointed about wglc on =
discovery. We had a starting point for group adoption but we haven't =
really defined the full requirements IMO. 
 
I am on vacation or I would put some thought =
into some draft changes or a new draft. I apologize I can't do it now. =

 
Phil
 
On Feb 24, =
2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:
 
Hi Phil, 
 
Are you =
suggesting that the AS metadata should include the RS URIs? Currently, =
it does not, but it can be done, I guess. 
 
The way oauth-meta works is that 
 
1. RS tells the =
client where the AS is. 
2. AS tells the client which RS endpoints the token can be =
used. 
 
Even if there is a bad AS with a valid certs that proxies to =
the good RS, the client will not send the token there as the authz =
server will say that is not the place the client may want to send the =
token to. 
 
Nat
 
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hunt@oracle.com>:
Nat,
 
I=E2=80=99m not =
sure that having the resource server tell the client where its =
authorization server is secure by itself. The relationship between the =
Authorization Server and the Resource server need to be bound together =
in one of the discovery endpoints (the resource and/or the oauth service =
discovery).
 
If a client =
discovers a fake resource server that is proxying for a real resource =
server the current discovery spec will not lead the client to understand =
it has the wrong resource server. Rather the fake resource service will =
just have a fake discovery service. The hacker can now intercept =
resource payload as well as tokens because they were able to convince =
the client to use the legit authorization service but use the token =
against the hackers proxy.
 
The OAuth Discovery service needs to confirm =
to the client that the server is able to issue tokens for a stated =
resource endpoint.
 =

This not only =
works in normal OAuth but should add security even to UMA =
situations.
 
Phil
 
@independentid
www.independentid.com
phil.hunt@oracle.com
 
 
 
 
 
On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:
 
 
Hi Thomas, 
 
inline: 
 
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com>:
Couldn't the document only describe the =
metadata?
I =
quite like the idea of draft-sakimura-oauth-meta if you really want to =
do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
The metadata =
described here would then either be used as-is, at any URL, returned as =
draft-sakimura-oauth-meta metadata at the RS; or as a basis for other =
metadata specs (like OpenID Connect). 
With draft-sakimura-oauth-meta's "duri" and =
the "scope" attribute of WWW-Authenticate response header, you have =
everything you need to proceed 
 
Yup. That's one of the requirements to be =
RESTful, is it not?  
 
In OAuth's case, the resource and the =
authorization server are usually tightly coupled. (Otherwise, you need =
another specs like UMA.) 
So, the resource server should be able to tell either the =
location of the authz endpoint. In some trusted environment, the =
resource may as well return the location of the authz server =
configuration data. In these cases, you do not have to decide on what =
.well-known uri as you say. This frees up developers from configuration =
file location collisions etc. We should strive not to pollute the uri =
space as much as possible. 
 
(well, except if there are several ASs each =
with different scopes; sounds like an edge-case to me though; maybe =
RFC6750 should instead be updated with such a parameter such that an RS =
could return several WWW-Authenticate: Bearer, each with its own "scope" =
and "duri" value?)
 =

Yeah, I guess =
it is an edge case. I would rather like to see these authz servers to =
develop a trust framework under which they can agree on a single set of =
common scope parameter values. 
 
Cheers, 
 
Nat
 
 
 
On Fri, Feb 19, 2016 at 10:59 PM Justin =
Richer <jricher@mit.edu> =
wrote:
The =
newly-trimmed OAuth Discovery document is helpful and moving in the =
right direction. It does, however, still have too many vestiges of its =
OpenID Connect origins. One issue in particular still really bothers me: =
the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the =
discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
 
I propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery document.
 
 =E2=80=94 =
Justin
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 



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


-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_6C7A6A2F-85B6-4F95-968B-389B5EB553DE--

--Apple-Mail=_C4C5776B-08CC-4E6D-9B02-F232E86B767D
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAyMjUxOTU3MzNaMCMGCSqGSIb3DQEJBDEWBBQEEFkFHbpSPSPaJvZmu0/V
eEbYhDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQB9aTiKu2qRWIp6KLBHp0pc0cksTdXHIYoaQBVtIeR84WzRB6mGqZgx
oXQlrNifHKVelSLfGqIdD5lNV4jBaJex6ECQs7TuCDWH3nDK6Tjo4FBl+dVHyqSyS6ixqoXrbfEQ
FFjtk87mjwhhcZ4NT6417cX6Ow5cC45NYalQ2EF+Fv0/Uw7d6wqGaQpaZHZnOoJtzDDa6XIvhayq
RaX/xQEkwoXTh6ytd9bIhPAukiehPJHr515klupVOdHo23RkXlehy/Ny92qGEpS5Gc7ap88PQePA
+BjtGhamgNza2l+3bKpagSjM23xSSML3F1keIAsTJBh+N3eTDaQvnIIawzS5AAAAAAAA
--Apple-Mail=_C4C5776B-08CC-4E6D-9B02-F232E86B767D--


From nobody Thu Feb 25 20:05:23 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A521A0470 for ; Thu, 25 Feb 2016 20:05:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=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 HfYreYSGh339 for ; Thu, 25 Feb 2016 20:05:19 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 588D81A0430 for ; Thu, 25 Feb 2016 20:05:16 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,498,1449493200"; d="scan'208,217"; a="60288856"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Feb 2016 15:05:10 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8086"; a="83808666"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 26 Feb 2016 15:05:08 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3707.srv.dir.telstra.com ([fe80::ccc:aa8f:d2a6:740%28]) with mapi; Fri, 26 Feb 2016 15:04:59 +1100
From: "Manger, James" 
To: George Fletcher , "oauth@ietf.org" 
Date: Fri, 26 Feb 2016 15:04:57 +1100
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AdFv4RoBLzOniVFDSG+U6fXZhZuMagAZ7/Sw
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com>
In-Reply-To: <56CF1D79.1070507@aol.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBB019D97WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 04:05:22 -0000

--_000_255B9BB34FB7D647A506DC292726F6E13BBB019D97WSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WW91IGFyZSByaWdodCwgR2VvcmdlLCB0aGF0IG1ha2luZyB0aGUgQVMgdHJhY2sgL3YyL+KApiBv
ciAvdjMv4oCmIGluIFJTIHBhdGhzIGlzIGxpa2VseSB0byBiZSBicml0dGxlIOKAlCBidXQgdHJh
Y2tpbmcgUlMgd2ViIG9yaWdpbnMgaXMgbm90IHRvbyBvbmVyb3VzLg0KDQpQb1AgaGFzIHNvbWUg
bmljZSBzZWN1cml0eSBhZHZhbnRhZ2VzIG92ZXIgYmVhcmVyIHRva2VucyBvciBwYXNzd29yZHMu
IEhvd2V2ZXIsIGl0IHNob3VsZCBzdGlsbCBiZSBwb3NzaWJsZSB0byB1c2UgdGhlIGxhdHRlciBm
YWlybHkgc2FmZWx5IOKAlCBidXQgaXQgZG9lcyByZXF1aXJlIHRoZSBpc3N1ZXIgb2YgY3JlZGVu
dGlhbHMgdG8gaW5kaWNhdGUgd2hlcmUgdGhleSBjYW4gYmUgdXNlZC4NCg0KLS0NCkphbWVzIE1h
bmdlcg0KDQoNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgR2VvcmdlIEZsZXRjaGVyDQpTZW50OiBGcmlkYXksIDI2IEZlYnJ1YXJ5IDIw
MTYgMjoyOCBBTQ0KVG86IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5j
b20+OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERp
c2NvdmVyeSBMb2NhdGlvbg0KDQpUaGF0IHNhaWQsIEknbSBub3QgYWdhaW5zdCB0aGUgQVMgaW5m
b3JtaW5nIHRoZSBjbGllbnQgdGhhdCB0aGUgdG9rZW4gY2FuIGJlIHVzZWQgYXQgdGhlIE1haWxS
ZXNvdXJjZSwgQ29udGFjdFJlc291cmNlIGFuZCBNZXNzYWdpbmdSZXNvdXJjZSB0byBoZWxwIHRo
ZSBjbGllbnQga25vdyBub3QgdG8gc2VuZCB0aGUgdG9rZW4gdG8gYSBCbG9nUmVzb3VyY2UuIEhv
d2V2ZXIsIGlkZW50aWZ5aW5nIHRoZSBhY3R1YWwgZW5kcG9pbnQgc2VlbXMgb3Zlcmx5IGNvbXBs
ZXggd2hlbiB3aGF0IGlzIHJlYWxseSB0cnlpbmcgdG8gYmUgcHJvdGVjdGVkIGlzIGEgdG9rZW4g
ZnJvbSBiZWluZyB1c2VkIHdoZXJlIGl0IHNob3VsZG4ndCBiZSAod2hpY2ggaXMgc29sdmVkIGJ5
IFBvcCkNCg0KVGhhbmtzLA0KR2VvcmdlDQpPbiAyLzI1LzE2IDEwOjI1IEFNLCBHZW9yZ2UgRmxl
dGNoZXIgd3JvdGU6DQpJbnRlcmVzdGluZy4uLiB0aGlzIGlzIG5vdCBhdCBhbGwgbXkgY3VycmVu
dCBleHBlcmllbmNlOikgSWYgYSBSUyBnb2VzIGZyb20gdjIgb2YgaXQncyBBUEkgdG8gdjMgYW5k
IHRoYXQgUlMgdXNlcyB0aGUgY3VycmVudCBzdGFuZGFyZCBvZiBwdXR0aW5nIGEgInYyIiBvciJ2
MyIgaW4gaXQncyBBUEkgcGF0aC4uLiB0aGVuIGEgdG9rZW4gaXNzdWVkIGZvciB2MiBvZiB0aGUg
QVBJIGNhbiBub3QgYmUgc2VudCB0byB2MyBvZiB0aGUgQVBJLCBiZWNhdXNlIHYzIHdhc24ndCB3
YXNuJ3QgcmVnaXN0ZXJlZC9kZXBsb3llZCB3aGVuIHRoZSB0b2tlbiB3YXMgaXNzdWVkLg0KDQpU
aGUgY29uc3RhbnQgbWFuYWdlbWVudCBvZiBzY29wZXMgdG8gVVJJIGVuZHBvaW50cyBzZWVtcyBs
aWtlIGEgY29tcGxleGl0eSB0aGF0IHdpbGwgcXVpY2tseSBnZXQgb3V0IG9mIGhhbmQuDQoNClRo
YW5rcywNCkdlb3JnZQ0KT24gMi8yNS8xNiAyOjIyIEFNLCBWbGFkaW1pciBEemh1dmlub3Ygd3Jv
dGU6DQoNCk9uIDI1LzAyLzE2IDA5OjAyLCBNYW5nZXIsIEphbWVzIHdyb3RlOg0KDQpJJ20gY29u
Y2VybmVkIHRoYXQgZm9yY2luZyB0aGUgQVMgdG8ga25vdyBhYm91dCBhbGwgUlMncyBlbmRwb2lu
dHMgdGhhdCB3aWxsIGFjY2VwdCBpdCdzIHRva2VucyBjcmVhdGVzIGEgdmVyeSBicml0dGxlIGRl
cGxveW1lbnQgYXJjaGl0ZWN0dXJlDQoNClRoZSBBUyBpcyBpc3N1aW5nIHRlbXBvcmFyeSBjcmVk
ZW50aWFscyAoYWNjZXNzX3Rva2VucykgdG8gY2xpZW50cyBidXQgZG9lc27igJl0IGtub3cgd2hl
cmUgdGhvc2UgY3JlZGVudGlhbHMgd2lsbCB3b3JrPyBUaGF04oCZcyBicm9rZW4uDQoNCg0KDQpB
biBBUyBzaG91bGQgYWJzb2x1dGVseSBpbmRpY2F0ZSB3aGVyZSBhbiBhY2Nlc3NfdG9rZW4gY2Fu
IGJlIHVzZWQuIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgc3VnZ2VzdHMgaW5kaWNhdGluZyB0
aGlzIHdpdGggMSBvciBtb3JlIOKAnHJ1cmnigJ0gKHJlc291cmNlIFVSSSkgdmFsdWVzIGluIGFu
IEhUVFAgTGluayBoZWFkZXIuIEEgYmV0dGVyIGFwcHJvYWNoIHdvdWxkIGJlIGluY2x1ZGluZyBh
IGxpc3Qgb2Ygd2ViIG9yaWdpbnMgaW4gdGhlIHRva2VuIHJlc3BvbnNlIGJlc2lkZSB0aGUgYWNj
ZXNzX3Rva2VuIGZpZWxkLg0KKzENCg0KVGhpcyB3aWxsIGFwcGVhciBtb3JlIGNvbnNpc3RlbnQg
d2l0aCB0aGUgY3VycmVudCBleHBlcmllbmNlLCBhbmQgT0F1dGggZG9lcyBhbGxvdyB0aGUgdG9r
ZW4gcmVzcG9uc2UgSlNPTiBvYmplY3QgdG8gYmUgZXh0ZW5kZWQgd2l0aCBhZGRpdGlvbmFsIG1l
bWJlcnMgKGFzIGl0J3MgZG9uZSBpbiBPcGVuSUQgQ29ubmVjdCBhbHJlYWR5KS4NCg0KQ2hlZXJz
LA0KVmxhZGltaXINCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0KRnJvbTogT0F1dGgg
W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvcmdlIEZsZXRj
aGVyDQoNClNlbnQ6IFRodXJzZGF5LCAyNSBGZWJydWFyeSAyMDE2IDY6MTcgQU0NCg0KVG86IFBo
aWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bT47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11cmFAZ21h
aWwuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxv
YXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09B
VVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpJJ20gY29uY2VybmVk
IHRoYXQgZm9yY2luZyB0aGUgQVMgdG8ga25vdyBhYm91dCBhbGwgUlMncyBlbmRwb2ludHMgdGhh
dCB3aWxsIGFjY2VwdCBpdCdzIHRva2VucyBjcmVhdGVzIGEgdmVyeSBicml0dGxlIGRlcGxveW1l
bnQgYXJjaGl0ZWN0dXJlLiBXaGF0IGlmIGEgUlMgbW92ZXMgdG8gYSBuZXcgZW5kcG9pbnQ/IEFs
bCBjbGllbnRzIHdvdWxkIGJlIHJlcXVpcmVkIHRvIGdldCBuZXcgdG9rZW5zIChpZiBJIHVuZGVy
c3RhbmQgY29ycmVjdGx5KS4gQW5kIHRoZSBSUyBtb3ZlIHdvdWxkIGhhdmUgdG8gY29vcmRpbmF0
ZSB3aXRoIHRoZSBBUyB0byBtYWtlIHN1cmUgYWxsIHRoZSB0aW1pbmcgaXMgcGVyZmVjdCBpbiB0
aGUgc3dpdGNoIG92ZXIgb2YgZW5kcG9pbnRzLg0KDQoNCg0KSSBzdXNwZWN0IGEgY29tbW9uIGRl
cGxveW1lbnQgYXJjaGl0ZWN0dXJlIHRvZGF5IGlzIHRoYXQgZWFjaCBSUyByZXF1aXJlcyBvbmUg
b3IgbW9yZSBzY29wZXMgdG8gYWNjZXNzIGl0J3MgcmVzb3VyY2VzLiBUaGUgY2xpZW50IHRoZW4g
YXNrcyB0aGUgdXNlciB0byBhdXRob3JpemUgYSB0b2tlbiB3aXRoIGEgcmVxdWVzdGVkIGxpc3Qg
b2Ygc2NvcGVzLiBUaGUgY2xpZW50IGNhbiB0aGVuIHNlbmQgdGhlIHRva2VuIHRvIHRoZSBhcHBy
b3ByaWF0ZSBSUyBlbmRwb2ludC4gVGhlIFJTIHdpbGwgbm90IGF1dGhvcml6ZSBhY2Nlc3MgdW5s
ZXNzIHRoZSB0b2tlbiBoYXMgdGhlIHJlcXVpcmVkIHNjb3Blcy4NCg0KDQoNCklmIHRoZSBjb25j
ZXJuIGlzIHRoYXQgdGhlIGNsaWVudCBtYXkgYWNjaWRlbnRhbGx5IHNlbmQgdGhlIHRva2VuIHRv
IGEgImJhZCIgUlMgd2hpY2ggd2lsbCB0aGVuIHJlcGxheSB0aGUgdG9rZW4sIHRoZW4gSSdkIHJh
dGhlciB1c2UgYSBQb1AgbWVjaGFuaXNtIGJlY2F1c2UgdGhlIHBvaW50IGlzIHRoYXQgeW91IHdh
bnQgdG8gZW5zdXJlIHRoZSBjb3JyZWN0IGNsaWVudCBpcyBwcmVzZW50aW5nIHRoZSB0b2tlbi4g
VHJ5aW5nIHRvIGVuc3VyZSB0aGUgY2xpZW50IGRvZXNuJ3Qgc2VuZCB0aGUgdG9rZW4gdG8gdGhl
IHdyb25nIGVuZHBvaW50IHNlZW1zIGZyYXVnaHQgd2l0aCBwcm9ibGVtcy4NCg0KDQoNClRoYW5r
cywNCg0KR2VvcmdlDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQoNCg==

--_000_255B9BB34FB7D647A506DC292726F6E13BBB019D97WSMSG3153Vsrv_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K
CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy
IDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp
bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z
b2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy
LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29s
b3I9d2hpdGUgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29y
ZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTJz5Zb3UgYXJlIHJpZ2h0LCBHZW9yZ2UsIHRoYXQgbWFraW5nIHRo
ZSBBUyB0cmFjayAvdjIv4oCmIG9yIC92My/igKYgaW4gUlMgcGF0aHMgaXMgbGlrZWx5IHRvIGJl
IGJyaXR0bGUg4oCUIGJ1dCB0cmFja2luZyBSUyB3ZWIgb3JpZ2lucyBpcyBub3QgdG9vIG9uZXJv
dXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMnPlBvUCBoYXMgc29tZSBuaWNlIHNlY3VyaXR5IGFkdmFudGFnZXMgb3Zl
ciBiZWFyZXIgdG9rZW5zIG9yIHBhc3N3b3Jkcy4gSG93ZXZlciwgaXQgc2hvdWxkIHN0aWxsIGJl
IHBvc3NpYmxlIHRvIHVzZSB0aGUgbGF0dGVyIGZhaXJseSBzYWZlbHkg4oCUIGJ1dCBpdCBkb2Vz
IHJlcXVpcmUgdGhlIGlzc3VlciBvZiBjcmVkZW50aWFscyB0byBpbmRpY2F0ZSB3aGVyZSB0aGV5
IGNhbiBiZSB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
Uyc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOndp
bmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl
eHQnPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBP
ZiA8L2I+R2VvcmdlIEZsZXRjaGVyPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIDI2IEZlYnJ1YXJ5
IDIwMTYgMjoyOCBBTTxicj48Yj5Ubzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7dmxhZGlt
aXJAY29ubmVjdDJpZC5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4g
UmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48
L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VGhhdCBz
YWlkLCBJJ20gbm90IGFnYWluc3QgdGhlIEFTIGluZm9ybWluZyB0aGUgY2xpZW50IHRoYXQgdGhl
IHRva2VuIGNhbiBiZSB1c2VkIGF0IHRoZSBNYWlsUmVzb3VyY2UsIENvbnRhY3RSZXNvdXJjZSBh
bmQgTWVzc2FnaW5nUmVzb3VyY2UgdG8gaGVscCB0aGUgY2xpZW50IGtub3cgbm90IHRvIHNlbmQg
dGhlIHRva2VuIHRvIGEgQmxvZ1Jlc291cmNlLiBIb3dldmVyLCBpZGVudGlmeWluZyB0aGUgYWN0
dWFsIGVuZHBvaW50IHNlZW1zIG92ZXJseSBjb21wbGV4IHdoZW4gd2hhdCBpcyByZWFsbHkgdHJ5
aW5nIHRvIGJlIHByb3RlY3RlZCBpcyBhIHRva2VuIGZyb20gYmVpbmcgdXNlZCB3aGVyZSBpdCBz
aG91bGRuJ3QgYmUgKHdoaWNoIGlzIHNvbHZlZCBieSBQb3ApPGJyPjxicj5UaGFua3MsPGJyPkdl
b3JnZTxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIDIvMjUvMTYgMTA6
MjUgQU0sIEdlb3JnZSBGbGV0Y2hlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2tx
dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48cCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9u
dC1mYW1pbHk6IkhlbHZldGljYSIsc2Fucy1zZXJpZic+SW50ZXJlc3RpbmcuLi4gdGhpcyBpcyBu
b3QgYXQgYWxsIG15IGN1cnJlbnQgZXhwZXJpZW5jZTopIElmIGEgUlMgZ29lcyBmcm9tIHYyIG9m
IGl0J3MgQVBJIHRvIHYzIGFuZCB0aGF0IFJTIHVzZXMgdGhlIGN1cnJlbnQgc3RhbmRhcmQgb2Yg
cHV0dGluZyBhICZxdW90O3YyJnF1b3Q7IG9yJnF1b3Q7djMmcXVvdDsgaW4gaXQncyBBUEkgcGF0
aC4uLiB0aGVuIGEgdG9rZW4gaXNzdWVkIGZvciB2MiBvZiB0aGUgQVBJIGNhbiBub3QgYmUgc2Vu
dCB0byB2MyBvZiB0aGUgQVBJLCBiZWNhdXNlIHYzIHdhc24ndCB3YXNuJ3QgcmVnaXN0ZXJlZC9k
ZXBsb3llZCB3aGVuIHRoZSB0b2tlbiB3YXMgaXNzdWVkLiA8YnI+PGJyPlRoZSBjb25zdGFudCBt
YW5hZ2VtZW50IG9mIHNjb3BlcyB0byBVUkkgZW5kcG9pbnRzIHNlZW1zIGxpa2UgYSBjb21wbGV4
aXR5IHRoYXQgd2lsbCBxdWlja2x5IGdldCBvdXQgb2YgaGFuZC48YnI+PGJyPlRoYW5rcyw8YnI+
R2VvcmdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIDIv
MjUvMTYgMjoyMiBBTSwgVmxhZGltaXIgRHpodXZpbm92IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwv
ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIDI1LzAyLzE2IDA5OjAy
LCBNYW5nZXIsIEphbWVzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0
eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1b3RlIHN0
eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwcmU+SSdtIGNvbmNl
cm5lZCB0aGF0IGZvcmNpbmcgdGhlIEFTIHRvIGtub3cgYWJvdXQgYWxsIFJTJ3MgZW5kcG9pbnRz
IHRoYXQgd2lsbCBhY2NlcHQgaXQncyB0b2tlbnMgY3JlYXRlcyBhIHZlcnkgYnJpdHRsZSBkZXBs
b3ltZW50IGFyY2hpdGVjdHVyZTxvOnA+PC9vOnA+PC9wcmU+PC9ibG9ja3F1b3RlPjxwcmU+VGhl
IEFTIGlzIGlzc3VpbmcgdGVtcG9yYXJ5IGNyZWRlbnRpYWxzIChhY2Nlc3NfdG9rZW5zKSB0byBj
bGllbnRzIGJ1dCBkb2VzbuKAmXQga25vdyB3aGVyZSB0aG9zZSBjcmVkZW50aWFscyB3aWxsIHdv
cms/IFRoYXTigJlzIGJyb2tlbi48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT48cHJlPkFuIEFTIHNob3VsZCBhYnNvbHV0ZWx5IGluZGljYXRlIHdoZXJlIGFuIGFj
Y2Vzc190b2tlbiBjYW4gYmUgdXNlZC4gZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBzdWdnZXN0
cyBpbmRpY2F0aW5nIHRoaXMgd2l0aCAxIG9yIG1vcmUg4oCccnVyaeKAnSAocmVzb3VyY2UgVVJJ
KSB2YWx1ZXMgaW4gYW4gSFRUUCBMaW5rIGhlYWRlci4gQSBiZXR0ZXIgYXBwcm9hY2ggd291bGQg
YmUgaW5jbHVkaW5nIGEgbGlzdCBvZiB3ZWIgb3JpZ2lucyBpbiB0aGUgdG9rZW4gcmVzcG9uc2Ug
YmVzaWRlIHRoZSBhY2Nlc3NfdG9rZW4gZmllbGQuPG86cD48L286cD48L3ByZT48L2Jsb2NrcXVv
dGU+PHAgY2xhc3M9TXNvTm9ybWFsPisxIDxicj48YnI+VGhpcyB3aWxsIGFwcGVhciBtb3JlIGNv
bnNpc3RlbnQgd2l0aCB0aGUgY3VycmVudCBleHBlcmllbmNlLCBhbmQgT0F1dGggZG9lcyBhbGxv
dyB0aGUgdG9rZW4gcmVzcG9uc2UgSlNPTiBvYmplY3QgdG8gYmUgZXh0ZW5kZWQgd2l0aCBhZGRp
dGlvbmFsIG1lbWJlcnMgKGFzIGl0J3MgZG9uZSBpbiBPcGVuSUQgQ29ubmVjdCBhbHJlYWR5KS48
YnI+PGJyPkNoZWVycyw8YnI+VmxhZGltaXI8YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48Ymxv
Y2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48cHJl
Pi0tPG86cD48L286cD48L3ByZT48cHJlPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wcmU+PHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0
bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv
YT5dIE9uIEJlaGFsZiBPZiBHZW9yZ2UgRmxldGNoZXI8bzpwPjwvbzpwPjwvcHJlPjxwcmU+U2Vu
dDogVGh1cnNkYXksIDI1IEZlYnJ1YXJ5IDIwMTYgNjoxNyBBTTxvOnA+PC9vOnA+PC9wcmU+PHBy
ZT5UbzogUGhpbCBIdW50IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+Jmx0
O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OzwvYT47IE5hdCBTYWtpbXVyYSA8YSBocmVmPSJtYWls
dG86c2FraW11cmFAZ21haWwuY29tIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT48bzpw
PjwvbzpwPjwvcHJlPjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0
O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4m
bHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT5TdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3By
ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5JJ20gY29uY2VybmVkIHRoYXQgZm9y
Y2luZyB0aGUgQVMgdG8ga25vdyBhYm91dCBhbGwgUlMncyBlbmRwb2ludHMgdGhhdCB3aWxsIGFj
Y2VwdCBpdCdzIHRva2VucyBjcmVhdGVzIGEgdmVyeSBicml0dGxlIGRlcGxveW1lbnQgYXJjaGl0
ZWN0dXJlLiBXaGF0IGlmIGEgUlMgbW92ZXMgdG8gYSBuZXcgZW5kcG9pbnQ/IEFsbCBjbGllbnRz
IHdvdWxkIGJlIHJlcXVpcmVkIHRvIGdldCBuZXcgdG9rZW5zIChpZiBJIHVuZGVyc3RhbmQgY29y
cmVjdGx5KS4gQW5kIHRoZSBSUyBtb3ZlIHdvdWxkIGhhdmUgdG8gY29vcmRpbmF0ZSB3aXRoIHRo
ZSBBUyB0byBtYWtlIHN1cmUgYWxsIHRoZSB0aW1pbmcgaXMgcGVyZmVjdCBpbiB0aGUgc3dpdGNo
IG92ZXIgb2YgZW5kcG9pbnRzLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPjxwcmU+SSBzdXNwZWN0IGEgY29tbW9uIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlIHRv
ZGF5IGlzIHRoYXQgZWFjaCBSUyByZXF1aXJlcyBvbmUgb3IgbW9yZSBzY29wZXMgdG8gYWNjZXNz
IGl0J3MgcmVzb3VyY2VzLiBUaGUgY2xpZW50IHRoZW4gYXNrcyB0aGUgdXNlciB0byBhdXRob3Jp
emUgYSB0b2tlbiB3aXRoIGEgcmVxdWVzdGVkIGxpc3Qgb2Ygc2NvcGVzLiBUaGUgY2xpZW50IGNh
biB0aGVuIHNlbmQgdGhlIHRva2VuIHRvIHRoZSBhcHByb3ByaWF0ZSBSUyBlbmRwb2ludC4gVGhl
IFJTIHdpbGwgbm90IGF1dGhvcml6ZSBhY2Nlc3MgdW5sZXNzIHRoZSB0b2tlbiBoYXMgdGhlIHJl
cXVpcmVkIHNjb3Blcy48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT48cHJlPklmIHRoZSBjb25jZXJuIGlzIHRoYXQgdGhlIGNsaWVudCBtYXkgYWNjaWRlbnRhbGx5
IHNlbmQgdGhlIHRva2VuIHRvIGEgJnF1b3Q7YmFkJnF1b3Q7IFJTIHdoaWNoIHdpbGwgdGhlbiBy
ZXBsYXkgdGhlIHRva2VuLCB0aGVuIEknZCByYXRoZXIgdXNlIGEgUG9QIG1lY2hhbmlzbSBiZWNh
dXNlIHRoZSBwb2ludCBpcyB0aGF0IHlvdSB3YW50IHRvIGVuc3VyZSB0aGUgY29ycmVjdCBjbGll
bnQgaXMgcHJlc2VudGluZyB0aGUgdG9rZW4uIFRyeWluZyB0byBlbnN1cmUgdGhlIGNsaWVudCBk
b2Vzbid0IHNlbmQgdGhlIHRva2VuIHRvIHRoZSB3cm9uZyBlbmRwb2ludCBzZWVtcyBmcmF1Z2h0
IHdpdGggcHJvYmxlbXMuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+PHByZT5UaGFua3MsPG86cD48L286cD48L3ByZT48cHJlPkdlb3JnZTxvOnA+PC9vOnA+PC9w
cmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwcmU+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv
cHJlPjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3By
ZT48cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48
L286cD48L3ByZT48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+PGJyPjxi
cj48bzpwPjwvbzpwPjwvcD48cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPG86cD48L286cD48L3ByZT48cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+
PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+PC9ibG9ja3F1b3RlPjxwIGNsYXNz
PU1zb05vcm1hbD48YnI+PGJyPjxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwcmU+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJl
PjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT48
cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286
cD48L3ByZT48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+

--_000_255B9BB34FB7D647A506DC292726F6E13BBB019D97WSMSG3153Vsrv_--


From nobody Thu Feb 25 20:08:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362F81A212A for ; Thu, 25 Feb 2016 20:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN-JVp3Wnjwk for ; Thu, 25 Feb 2016 20:08:43 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 38F4B1A1A02 for ; Thu, 25 Feb 2016 20:08:43 -0800 (PST)
Received: by mail-qg0-x231.google.com with SMTP id y89so57151314qge.2 for ; Thu, 25 Feb 2016 20:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=1fcdZG86367iRC5UHBUKypvMaUpSR/nrKJ3muMwZZFs=; b=0P7TIFcPzivZ6iPiblVz/idpaJyDVi//G0MmNdhRo7oLMn1fLgmtvSGhtt1z938LL1 sXPanN48eZ6K4hBhghkO/SOSEcTeqEbTmVyoyONTUSpw6FD2ccdHMxrhpzcL2yXhHyeq FBjB5jSNNXd9xjdKBkver2pADr29Ad6zkCpBnlJ5yIqJ3wIwMNy7kyNFWFOvHb7QAD+J m9jsgMbgU7kzXU9eAlWTDB6v9wg+w53L1OLToTAtHl+g2BQueSnLPuiy2Pu0y6u4L5lK Ha3faQDBDkRLmy4SG7/mROHen4vW3G1wZhnyGbfF4+Anb6sBqvitFzy5xgjkAive9Nxv 8s6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=1fcdZG86367iRC5UHBUKypvMaUpSR/nrKJ3muMwZZFs=; b=S0Y7vit10xvG6pD2wYqT/H35cviF1uUcbICaxx5MxWZNx5PBNymhlqHtA0pU8HCDRB zePReKdrlevI8Bz0OFUr9MxJ48ELS2cjRc3aa5CBNRk2KYIEr9m52GmiT1pEZQjLWw9W 7AGAkKjxcPZ8NoZ2Llms4DjxVDq2OUJKSB9EFgsj2BWqwfHFkmzwKxbQ6bL1SG2JqURe 1avlMLNzHcwIfeau1lKpw/ehVW7pSoWHGjE62qo4iR4CNOIhw9QaCe9DNnGyp9p1CdTT 0h817SYZ5kVLLidyiXwgZl18qZULA4vuO5ydV4O4RxJYbahK7zl/IlonB70s3CCbOCSQ rzKg==
X-Gm-Message-State: AG10YOQ+lAyafuwuQQc3srl4m3A/U2qtd4g+NbmhbwTIQSPA4kQFt/pDJKltL33NINe4y7Q0TvL7velNZifDlw==
X-Received: by 10.140.165.205 with SMTP id l196mr65529783qhl.58.1456459717403;  Thu, 25 Feb 2016 20:08:37 -0800 (PST)
MIME-Version: 1.0
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>
From: Nat Sakimura 
Date: Fri, 26 Feb 2016 04:08:28 +0000
Message-ID: 
To: "Manger, James" , George Fletcher , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1134f04c15e9f6052ca474cd
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 04:08:46 -0000

--001a1134f04c15e9f6052ca474cd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I will include the origin in the next rev.

For http header v.s JSON, shall I bring the JSON back in?
2016=E5=B9=B42=E6=9C=8826=E6=97=A5(=E9=87=91) 13:05 Manger, James :

> You are right, George, that making the AS track /v2/=E2=80=A6 or /v3/=E2=
=80=A6 in RS paths
> is likely to be brittle =E2=80=94 but tracking RS web origins is not too =
onerous.
>
>
>
> PoP has some nice security advantages over bearer tokens or passwords.
> However, it should still be possible to use the latter fairly safely =E2=
=80=94 but
> it does require the issuer of credentials to indicate where they can be
> used.
>
>
>
> --
>
> James Manger
>
>
>
>
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Friday, 26 February 2016 2:28 AM
> *To:* Vladimir Dzhuvinov ; oauth@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> That said, I'm not against the AS informing the client that the token can
> be used at the MailResource, ContactResource and MessagingResource to hel=
p
> the client know not to send the token to a BlogResource. However,
> identifying the actual endpoint seems overly complex when what is really
> trying to be protected is a token from being used where it shouldn't be
> (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>
> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of puttin=
g
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API c=
an
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deploye=
d
> when the token was issued.
>
> The constant management of scopes to URI endpoints seems like a complexit=
y
> that will quickly get out of hand.
>
> Thanks,
> George
>
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that w=
ill accept it's tokens creates a very brittle deployment architecture
>
> The AS is issuing temporary credentials (access_tokens) to clients but do=
esn=E2=80=99t know where those credentials will work? That=E2=80=99s broken=
.
>
>
>
> An AS should absolutely indicate where an access_token can be used. draft=
-sakimura-oauth-meta suggests indicating this with 1 or more =E2=80=9Cruri=
=E2=80=9D (resource URI) values in an HTTP Link header. A better approach w=
ould be including a list of web origins in the token response beside the ac=
cess_token field.
>
> +1
>
> This will appear more consistent with the current experience, and OAuth
> does allow the token response JSON object to be extended with additional
> members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
> --
>
> James Manger
>
>
>
> From: OAuth [mailto:oauth-bounces@ietf.org ] On B=
ehalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt  ; Nat Sakimura=
  
>
> Cc:    
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I'm concerned that forcing the AS to know about all RS's endpoints that w=
ill accept it's tokens creates a very brittle deployment architecture. What=
 if a RS moves to a new endpoint? All clients would be required to get new =
tokens (if I understand correctly). And the RS move would have to coordinat=
e with the AS to make sure all the timing is perfect in the switch over of =
endpoints.
>
>
>
> I suspect a common deployment architecture today is that each RS requires=
 one or more scopes to access it's resources. The client then asks the user=
 to authorize a token with a requested list of scopes. The client can then =
send the token to the appropriate RS endpoint. The RS will not authorize ac=
cess unless the token has the required scopes.
>
>
>
> If the concern is that the client may accidentally send the token to a "b=
ad" RS which will then replay the token, then I'd rather use a PoP mechanis=
m because the point is that you want to ensure the correct client is presen=
ting the token. Trying to ensure the client doesn't send the token to the w=
rong endpoint seems fraught with problems.
>
>
>
> Thanks,
>
> George
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a1134f04c15e9f6052ca474cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I will include the origin in the next rev. 

For http header v.s JSON=
, shall I bring the JSON back in? 
2016=E5=B9=B42=E6=9C=8826=E6=97=A5(=E9=87=91) 13:05 Manger, James =
<James.H.Manger@team.=
telstra.com>:
You are right, George, that making the AS track /v=
2/=E2=80=A6 or /v3/=E2=80=A6 in RS paths is likely to be brittle =E2=80=94 =
but tracking RS web origins is not too onerous.
=C2=A0
PoP has some nice security advantages over be=
arer tokens or passwords. However, it should still be possible to use the l=
atter fairly safely =E2=80=94 but it does require the issuer of credentials=
 to indicate where they can be used.
=C2=A0
--
James Manger
=C2=A0
=C2=A0
=C2=A0
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent=
: Friday, 26 February 2016 2:28 AM
To: Vladimir Dzhuvinov <=
;vladimir@conn=
ect2id.com>; oau=
th@ietf.org

Subject: Re: [OAUTH-=
WG] OAuth 2.0 Discovery Location
=

=

=C2=A0
That said, I'm not against the AS inform=
ing the client that the token can be used at the MailResource, ContactResou=
rce and MessagingResource to help the client know not to send the token to =
a BlogResource. However, identifying the actual endpoint seems overly compl=
ex when what is really trying to be protected is a token from being used wh=
ere it shouldn't be (which is solved by Pop)

Thanks,
George
On 2/25/16 10:25 AM, George Fle=
tcher wrote:
<=
span style=3D"font-family:"Helvetica",sans-serif">Interesting... =
this is not at all my current experience:) If a RS goes from v2 of it's=
 API to v3 and that RS uses the current standard of putting a "v2"=
; or"v3" in it's API path... then a token issued for v2 of th=
e API can not be sent to v3 of the API, because v3 wasn't wasn't re=
gistered/deployed when the token was issued. 

The constant managemen=
t of scopes to URI endpoints seems like a complexity that will quickly get =
out of hand.

Thanks,
George
On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:<=
/p>
=C2=A0
On 25/02/16 09:02, Manger, James wrote:
I'm concern=
ed that forcing the AS to know about all RS's endpoints that will accep=
t it's tokens creates a very brittle deployment architecture<=
/u>
The AS is issuing temporary credentials (access_=
tokens) to clients but doesn=E2=80=99t know where those credentials will wo=
rk? That=E2=80=99s broken.
=C2=A0
An AS should absolutely indicate where an access_token can be used. =
draft-sakimura-oauth-meta suggests indicating this with 1 or more =E2=80=9C=
ruri=E2=80=9D (resource URI) values in an HTTP Link header. A better approa=
ch would be including a list of web origins in the token response beside th=
e access_token field.
+1 

This will appear more consistent with the current experience, =
and OAuth does allow the token response JSON object to be extended with add=
itional members (as it's done in OpenID Connect already).

Cheers=
,
Vladimir


--
James Manger<=
/u>
=C2=A0
From: OAuth [mailto:oauth-bounces@ietf=
.org] On Behalf Of George Fletcher
Sent: Thursd=
ay, 25 February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com=
>; Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org><=
/u>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=C2=A0
I'm concerned tha=
t forcing the AS to know about all RS's endpoints that will accept it&#=
39;s tokens creates a very brittle deployment architecture. What if a RS mo=
ves to a new endpoint? All clients would be required to get new tokens (if =
I understand correctly). And the RS move would have to coordinate with the =
AS to make sure all the timing is perfect in the switch over of endpoints.<=
u>
=C2=A0
I suspect a common d=
eployment architecture today is that each RS requires one or more scopes to=
 access it's resources. The client then asks the user to authorize a to=
ken with a requested list of scopes. The client can then send the token to =
the appropriate RS endpoint. The RS will not authorize access unless the to=
ken has the required scopes.
=C2=A0
If the concern is that the client may accidentally send the token =
to a "bad" RS which will then replay the token, then I'd rath=
er use a PoP mechanism because the point is that you want to ensure the cor=
rect client is presenting the token. Trying to ensure the client doesn'=
t send the token to the wrong endpoint seems fraught with problems.<=
u>
=C2=A0
Thanks,
=

George



_______________________________________________=

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




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





______________________________=
_________________
OAuth mailing list<=
/pre>
OAuth@ietf.or=
g
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0
_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a1134f04c15e9f6052ca474cd--


From nobody Thu Feb 25 21:52:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9CA1A8755 for ; Thu, 25 Feb 2016 21:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccu13pN4CplR for ; Thu, 25 Feb 2016 21:52:06 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 5D8A51A6FFC for ; Thu, 25 Feb 2016 21:52:06 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id c10so47694661pfc.2 for ; Thu, 25 Feb 2016 21:52:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dk+KI+Ry8blU91voUiPYd4acIbZt9n7gk7oU04dBxrM=; b=v+CoxzMIZa+lGdLQZQjcKnwVjeCZglBD21N0tBlaYaiyqzHDxJ9t/sHjNQwCFciK1M lvbYxTeXRe/2pkUz0C5Xev7DATWccZOkiQl5BqDchjiTveQNc4Uwji0KccEqKoE3dV73 5LVIUJTBL6lWE1ry/1hYoZUOuxXljLzXFoWiaZQEghZEVfzsWSMBGxymei7/gVeAbfs5 X+5Az2r9qQt+kxi5Nf4+vx9/+QjgX4pM+k+1WhR9RYavroSTSjpTOiz160AKPCoccNdD EQNwGPTR7xfBn336stQIIm5eBVZU6qSPpV8PEN8ieC8eWIp8yEkH+4gAGEg1Zcq6tkiG vkeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dk+KI+Ry8blU91voUiPYd4acIbZt9n7gk7oU04dBxrM=; b=Z9GfiX/vHxU4nfajEm9AXxMfb2XQBf0eu4xYpLaPNRGIRnNuS7xJokPbWo76X6KAt1 ck68dUyqlEGXJ6U1EAlVx0NN5ZuHDgx1RK5dp936P+qDMjbrbcbxsERxR1FZvv7MAT6w lg/Golt05loEG8U3JvBiBnznDHSf24AHQFcbLkmljLMqyJyeas/OLRbo5r/WpFNghsku n8b1QzqMtrRpRwqA4xJswXKL1MzqAohUM5ML7/2M2zZpN5B5lAEYo75zQNoaYsWWnlvm XIJ6XwkLg/UKoR+yUUaoODLJZjiyHxfiHLhRSmGOhNxxtbnnFk4NEHSSpP8vpnYsV04T jzqA==
X-Gm-Message-State: AG10YOSfrOwmFSn1lmM90X1I/MOEyd/8z2rJuYnzdVgfxnMy8BuJhlM7m/nVI6ySWLUgzw==
X-Received: by 10.98.0.11 with SMTP id 11mr68983549pfa.5.1456465925859; Thu, 25 Feb 2016 21:52:05 -0800 (PST)
Received: from tovan.intra.gree-office.net ([27.110.57.144]) by smtp.gmail.com with ESMTPSA id c68sm16089633pfj.41.2016.02.25.21.52.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 21:52:05 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_171DF1C3-F98E-40A4-9EF2-FB0B57A42316"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: nov matake 
In-Reply-To: 
Date: Fri, 26 Feb 2016 14:52:02 +0900
Message-Id: 
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 05:52:09 -0000

--Apple-Mail=_171DF1C3-F98E-40A4-9EF2-FB0B57A42316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It sounds like we want to return a list of available access tokens =
=E2=80=9Caud=E2=80=9D values from AS config discovery endpoint (and also =
via oauth-meta too?), doesn=E2=80=99t it?

and RS config discovery endpoint will return acceptable access token =
=E2=80=9Ciss=E2=80=9D values, a list of every RS endpoints, required =
scopes per endpoint etc.
(it would be another thread though)

Thanks,
Nov

> On Feb 26, 2016, at 13:08, Nat Sakimura  wrote:
>=20
> I will include the origin in the next rev.=20
>=20
> For http header v.s JSON, shall I bring the JSON back in?=20
> 2016=E5=B9=B42=E6=9C=8826=E6=97=A5(=E9=87=91) 13:05 Manger, James =
>:
> You are right, George, that making the AS track /v2/=E2=80=A6 or =
/v3/=E2=80=A6 in RS paths is likely to be brittle =E2=80=94 but tracking =
RS web origins is not too onerous.
>=20
> =20
>=20
> PoP has some nice security advantages over bearer tokens or passwords. =
However, it should still be possible to use the latter fairly safely =E2=80=
=94 but it does require the issuer of credentials to indicate where they =
can be used.
>=20
> =20
>=20
> --
>=20
> James Manger
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
> Sent: Friday, 26 February 2016 2:28 AM
> To: Vladimir Dzhuvinov >; oauth@ietf.org =

>=20
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>=20
> =20
>=20
> That said, I'm not against the AS informing the client that the token =
can be used at the MailResource, ContactResource and MessagingResource =
to help the client know not to send the token to a BlogResource. =
However, identifying the actual endpoint seems overly complex when what =
is really trying to be protected is a token from being used where it =
shouldn't be (which is solved by Pop)
>=20
> Thanks,
> George
>=20
> On 2/25/16 10:25 AM, George Fletcher wrote:
>=20
> Interesting... this is not at all my current experience:) If a RS goes =
from v2 of it's API to v3 and that RS uses the current standard of =
putting a "v2" or"v3" in it's API path... then a token issued for v2 of =
the API can not be sent to v3 of the API, because v3 wasn't wasn't =
registered/deployed when the token was issued.=20
>=20
> The constant management of scopes to URI endpoints seems like a =
complexity that will quickly get out of hand.
>=20
> Thanks,
> George
>=20
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>=20
> =20
>=20
> On 25/02/16 09:02, Manger, James wrote:
>=20
> I'm concerned that forcing the AS to know about all RS's endpoints =
that will accept it's tokens creates a very brittle deployment =
architecture
> The AS is issuing temporary credentials (access_tokens) to clients but =
doesn=E2=80=99t know where those credentials will work? That=E2=80=99s =
broken.
> =20
> An AS should absolutely indicate where an access_token can be used. =
draft-sakimura-oauth-meta suggests indicating this with 1 or more =
=E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.
> +1=20
>=20
> This will appear more consistent with the current experience, and =
OAuth does allow the token response JSON object to be extended with =
additional members (as it's done in OpenID Connect already).
>=20
> Cheers,
> Vladimir
>=20
>=20
>=20
> --
> James Manger
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
> Sent: Thursday, 25 February 2016 6:17 AM
> To: Phil Hunt  ; =
Nat Sakimura  
> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I'm concerned that forcing the AS to know about all RS's endpoints =
that will accept it's tokens creates a very brittle deployment =
architecture. What if a RS moves to a new endpoint? All clients would be =
required to get new tokens (if I understand correctly). And the RS move =
would have to coordinate with the AS to make sure all the timing is =
perfect in the switch over of endpoints.
> =20
> I suspect a common deployment architecture today is that each RS =
requires one or more scopes to access it's resources. The client then =
asks the user to authorize a token with a requested list of scopes. The =
client can then send the token to the appropriate RS endpoint. The RS =
will not authorize access unless the token has the required scopes.
> =20
> If the concern is that the client may accidentally send the token to a =
"bad" RS which will then replay the token, then I'd rather use a PoP =
mechanism because the point is that you want to ensure the correct =
client is presenting the token. Trying to ensure the client doesn't send =
the token to the wrong endpoint seems fraught with problems.
> =20
> Thanks,
> George
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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


--Apple-Mail=_171DF1C3-F98E-40A4-9EF2-FB0B57A42316
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


It sounds like we want to return a list of =
available access tokens =E2=80=9Caud=E2=80=9D values from AS config =
discovery endpoint (and also via oauth-meta too?), doesn=E2=80=99t =
it?

and RS =
config discovery endpoint will return acceptable access token =E2=80=9Ciss=
=E2=80=9D values, a list of every RS endpoints, required scopes per =
endpoint etc.
(it would be another thread =
though)

Thanks,
Nov

On Feb 26, 2016, at 13:08, Nat Sakimura <sakimura@gmail.com> =
wrote:

I =
will include the origin in the next rev. 

For=
 http header v.s JSON, shall I bring the JSON back in? 
2016=E5=B9=B42=E6=9C=88=
26=E6=97=A5(=E9=87=91) 13:05 Manger, James <James.H.Manger@team.telstra.com>:
You are right, George, that making the AS track =
/v2/=E2=80=A6 or /v3/=E2=80=A6 in RS paths is likely to be brittle =E2=80=94=
 but tracking RS web origins is not too onerous.
 
PoP has some nice security advantages over bearer =
tokens or passwords. However, it should still be possible to use the =
latter fairly safely =E2=80=94 but it does require the issuer of =
credentials to indicate where they can be used.
 
--
James Manger
 
 
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of =
George Fletcher
Sent: Friday, 26 =
February 2016 2:28 AM
To: Vladimir =
Dzhuvinov <vladimir@connect2id.com>; oauth@ietf.org

Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
That said, I'm not against the AS =
informing the client that the token can be used at the MailResource, =
ContactResource and MessagingResource to help the client know not to =
send the token to a BlogResource. However, identifying the actual =
endpoint seems overly complex when what is really trying to be protected =
is a token from being used where it shouldn't be (which is solved by =
Pop)

Thanks,
George
On 2/25/16 10:25 AM, George Fletcher wrote:
Interesting... this is not at all my current experience:) If =
a RS goes from v2 of it's API to v3 and that RS uses the current =
standard of putting a "v2" or"v3" in it's API path... then a token =
issued for v2 of the API can not be sent to v3 of the API, because v3 =
wasn't wasn't registered/deployed when the token was issued. 

The constant management of scopes to URI =
endpoints seems like a complexity that will quickly get out of hand.

Thanks,
George
On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
 
On 25/02/16 09:02, Manger, James wrote:
I'm concerned that forcing the AS to know about all RS's =
endpoints that will accept it's tokens creates a very brittle deployment =
architecture
The AS is issuing temporary credentials (access_tokens) to =
clients but doesn=E2=80=99t know where those credentials will work? =
That=E2=80=99s broken.
 
An AS should absolutely indicate where an access_token can be =
used. draft-sakimura-oauth-meta suggests indicating this with 1 or more =
=E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.
+1 

This will appear more consistent with the =
current experience, and OAuth does allow the token response JSON object =
to be extended with additional members (as it's done in OpenID Connect =
already).

Cheers,
Vladimir


--
James Manger
 
From: OAuth [mailto:oauth-bounces@ietf.org] On =
Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 =
Discovery Location
 
I'm concerned that forcing the AS to know about all RS's =
endpoints that will accept it's tokens creates a very brittle deployment =
architecture. What if a RS moves to a new endpoint? All clients would be =
required to get new tokens (if I understand correctly). And the RS move =
would have to coordinate with the AS to make sure all the timing is =
perfect in the switch over of endpoints.
 
I suspect a common deployment =
architecture today is that each RS requires one or more scopes to access =
it's resources. The client then asks the user to authorize a token with =
a requested list of scopes. The client can then send the token to the =
appropriate RS endpoint. The RS will not authorize access unless the =
token has the required scopes.
 
If the concern is that the client =
may accidentally send the token to a "bad" RS which will then replay the =
token, then I'd rather use a PoP mechanism because the point is that you =
want to ensure the correct client is presenting the token. Trying to =
ensure the client doesn't send the token to the wrong endpoint seems =
fraught with problems.
 
Thanks,
George



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




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





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

OAuth mailing list

OAuth@ietf.org

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



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

=

--Apple-Mail=_171DF1C3-F98E-40A4-9EF2-FB0B57A42316--


From nobody Fri Feb 26 01:06:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EDA1AD0CF for ; Fri, 26 Feb 2016 01:06:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D60f0xIBLQfh for ; Fri, 26 Feb 2016 01:06:46 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4859F1AD0AB for ; Fri, 26 Feb 2016 01:06:46 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id c200so63182843wme.0 for ; Fri, 26 Feb 2016 01:06:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=V/jkfOGezoxpzMx1lcvEri7rQNncIvXum4S3XsZebyY=; b=PdrlDZgEuVE4lEFaynfevuyRSgWfdjfPRw3kdy5oqxiIk16bMdTTC5kAo0ZnnMpErj GLJiCWa8He+PPd+1Brm3nJOvP5jRZLXovTux9ntTinjbAeWguvdULLyUQfgAc4vxsw6N QalcAEwAeaqjGTq5Xve4AlOvK4L3dWpsOoYjJvuSLnJYzrgNJJOJO02J8/s/xHtpxWNZ ScC/wJ3QzYA7lJ2J8gNESmQo8IIWMWPkTAKidFT3UxvdFibYdZBUT3C9l+De3dacCJud uSoTWLQ0DaOMulXAlT+ofZquQp855+8BemwH/MyPVBrXS0Sf7Lj2e50A00wQwv/gQrVb D93w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=V/jkfOGezoxpzMx1lcvEri7rQNncIvXum4S3XsZebyY=; b=XucABJ61DZ9o91juAWvjHOrk+IgP51Dvf+/2UsTaZZ2FHaiX40yLFNVXhVBQsrPUYY 6JQtJuKfVBwABPdhF4QcH/LJiXIQg0VD/k+YfFB0bgwmb03Ng++MwHOg01Y4pgjjJpyW tdvO4GaZjswt+RpSxfI//Nedg2/P8KyRqRLoQ3Ue2QYwYGGwIt5mWP+EmQmj7NwISZzh QFTSu4Xwj/EsbG3YWJIB7958TDz6gr+oJMai2lntCKtfIv4UvXvgxwwJ9JMdHwk/z8TY owwRB3SYDjRDMlI3K9+nxnb4iz+iK+cnMZcD4rSmFFbg+MmAvTxImHW1EPvoGSb+Ymjq 2sdQ==
X-Gm-Message-State: AD7BkJIizj7BdLOkhC3ivGnTyDmhIBhI7Oucajr6dsXySmhnwjcvmSiuoCQYjHvrge+Gqw==
X-Received: by 10.28.68.86 with SMTP id r83mr1961166wma.73.1456477604700; Fri, 26 Feb 2016 01:06:44 -0800 (PST)
Received: from [10.0.2.140] (cli-5b7e84b4.bcn.adamo.es. [91.126.132.180]) by smtp.gmail.com with ESMTPSA id a128sm1974416wmh.6.2016.02.26.01.06.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 01:06:43 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8A319E3F-0089-44FA-A357-0861B1057C70"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 26 Feb 2016 10:06:42 +0100
Message-Id: <870DD5B5-2FF9-4BE0-ABA5-FB3486E4840B@ve7jtb.com>
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>  
To: nov matake 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 09:06:50 -0000

--Apple-Mail=_8A319E3F-0089-44FA-A357-0861B1057C70
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D694C9FF-D341-42BE-84F0-09113DF3B4C3"


--Apple-Mail=_D694C9FF-D341-42BE-84F0-09113DF3B4C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

A given AS may be supporting different protocols and or scopes with =
different privileges.

Those would need to be mapped into where the token can be used.=20

If we try to use audience only to stop cross RS replay it will in my =
opinion become hopelessly complex.

I think the only secure and practical solution is likely asymmetric POP. =
   That only requires the RS to trust the AS.   The AS doesn=E2=80=99t =
need to know the RS if it is using JWT access tokens.

I am skeptical that this can be solved by meta-data alone.

John B.
> On Feb 26, 2016, at 6:52 AM, nov matake  wrote:
>=20
> It sounds like we want to return a list of available access tokens =
=E2=80=9Caud=E2=80=9D values from AS config discovery endpoint (and also =
via oauth-meta too?), doesn=E2=80=99t it?
>=20
> and RS config discovery endpoint will return acceptable access token =
=E2=80=9Ciss=E2=80=9D values, a list of every RS endpoints, required =
scopes per endpoint etc.
> (it would be another thread though)
>=20
> Thanks,
> Nov
>=20
>> On Feb 26, 2016, at 13:08, Nat Sakimura > wrote:
>>=20
>> I will include the origin in the next rev.=20
>>=20
>> For http header v.s JSON, shall I bring the JSON back in?=20
>> 2016=E5=B9=B42=E6=9C=8826=E6=97=A5(=E9=87=91) 13:05 Manger, James =
>:
>> You are right, George, that making the AS track /v2/=E2=80=A6 or =
/v3/=E2=80=A6 in RS paths is likely to be brittle =E2=80=94 but tracking =
RS web origins is not too onerous.
>>=20
>> =20
>>=20
>> PoP has some nice security advantages over bearer tokens or =
passwords. However, it should still be possible to use the latter fairly =
safely =E2=80=94 but it does require the issuer of credentials to =
indicate where they can be used.
>>=20
>> =20
>>=20
>> --
>>=20
>> James Manger
>>=20
>> =20
>>=20
>> =20
>>=20
>> =20
>>=20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
>> Sent: Friday, 26 February 2016 2:28 AM
>> To: Vladimir Dzhuvinov >; oauth@ietf.org =

>>=20
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>=20
>> =20
>>=20
>> That said, I'm not against the AS informing the client that the token =
can be used at the MailResource, ContactResource and MessagingResource =
to help the client know not to send the token to a BlogResource. =
However, identifying the actual endpoint seems overly complex when what =
is really trying to be protected is a token from being used where it =
shouldn't be (which is solved by Pop)
>>=20
>> Thanks,
>> George
>>=20
>> On 2/25/16 10:25 AM, George Fletcher wrote:
>>=20
>> Interesting... this is not at all my current experience:) If a RS =
goes from v2 of it's API to v3 and that RS uses the current standard of =
putting a "v2" or"v3" in it's API path... then a token issued for v2 of =
the API can not be sent to v3 of the API, because v3 wasn't wasn't =
registered/deployed when the token was issued.=20
>>=20
>> The constant management of scopes to URI endpoints seems like a =
complexity that will quickly get out of hand.
>>=20
>> Thanks,
>> George
>>=20
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>=20
>> =20
>>=20
>> On 25/02/16 09:02, Manger, James wrote:
>>=20
>> I'm concerned that forcing the AS to know about all RS's endpoints =
that will accept it's tokens creates a very brittle deployment =
architecture
>> The AS is issuing temporary credentials (access_tokens) to clients =
but doesn=E2=80=99t know where those credentials will work? That=E2=80=99s=
 broken.
>> =20
>> An AS should absolutely indicate where an access_token can be used. =
draft-sakimura-oauth-meta suggests indicating this with 1 or more =
=E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.
>> +1=20
>>=20
>> This will appear more consistent with the current experience, and =
OAuth does allow the token response JSON object to be extended with =
additional members (as it's done in OpenID Connect already).
>>=20
>> Cheers,
>> Vladimir
>>=20
>>=20
>>=20
>> --
>> James Manger
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
>> Sent: Thursday, 25 February 2016 6:17 AM
>> To: Phil Hunt  ; =
Nat Sakimura  
>> Cc:    =

>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> I'm concerned that forcing the AS to know about all RS's endpoints =
that will accept it's tokens creates a very brittle deployment =
architecture. What if a RS moves to a new endpoint? All clients would be =
required to get new tokens (if I understand correctly). And the RS move =
would have to coordinate with the AS to make sure all the timing is =
perfect in the switch over of endpoints.
>> =20
>> I suspect a common deployment architecture today is that each RS =
requires one or more scopes to access it's resources. The client then =
asks the user to authorize a token with a requested list of scopes. The =
client can then send the token to the appropriate RS endpoint. The RS =
will not authorize access unless the token has the required scopes.
>> =20
>> If the concern is that the client may accidentally send the token to =
a "bad" RS which will then replay the token, then I'd rather use a PoP =
mechanism because the point is that you want to ensure the correct =
client is presenting the token. Trying to ensure the client doesn't send =
the token to the wrong endpoint seems fraught with problems.
>> =20
>> Thanks,
>> George
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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


--Apple-Mail=_D694C9FF-D341-42BE-84F0-09113DF3B4C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

A given AS may be supporting different protocols and or =
scopes with different privileges.

Those would need to be mapped into where the token can be =
used. 

If =
we try to use audience only to stop cross RS replay it will in my =
opinion become hopelessly complex.

I think the only secure and practical =
solution is likely asymmetric POP.    That only requires the =
RS to trust the AS.   The AS doesn=E2=80=99t need to know the RS if =
it is using JWT access tokens.

I am skeptical that this can be solved =
by meta-data alone.

John B.
On Feb 26, 2016, at 6:52 AM, nov matake =
<matake@gmail.com> wrote:

It sounds like we want to return a list of available access =
tokens =E2=80=9Caud=E2=80=9D values from AS config discovery endpoint =
(and also via oauth-meta too?), doesn=E2=80=99t it?

and RS config discovery =
endpoint will return acceptable access token =E2=80=9Ciss=E2=80=9D =
values, a list of every RS endpoints, required scopes per endpoint =
etc.
(it would be another thread though)

Thanks,
Nov

On Feb =
26, 2016, at 13:08, Nat Sakimura <sakimura@gmail.com> wrote:

I will include the =
origin in the next rev. 

For http header =
v.s JSON, shall I bring the JSON back in? 
2016=E5=B9=B42=E6=9C=882=
6=E6=97=A5(=E9=87=91) 13:05 Manger, James <James.H.Manger@team.telstra.com>:
You are right, George, that making the AS track =
/v2/=E2=80=A6 or /v3/=E2=80=A6 in RS paths is likely to be brittle =E2=80=94=
 but tracking RS web origins is not too onerous.
 
PoP has some nice security advantages over bearer =
tokens or passwords. However, it should still be possible to use the =
latter fairly safely =E2=80=94 but it does require the issuer of =
credentials to indicate where they can be used.
 
--
James Manger
 
 
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of =
George Fletcher
Sent: Friday, 26 =
February 2016 2:28 AM
To: Vladimir =
Dzhuvinov <vladimir@connect2id.com>; oauth@ietf.org

Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
That said, I'm not against the AS =
informing the client that the token can be used at the MailResource, =
ContactResource and MessagingResource to help the client know not to =
send the token to a BlogResource. However, identifying the actual =
endpoint seems overly complex when what is really trying to be protected =
is a token from being used where it shouldn't be (which is solved by =
Pop)

Thanks,
George
On 2/25/16 10:25 AM, George Fletcher wrote:
Interesting... this is not at all my current experience:) If =
a RS goes from v2 of it's API to v3 and that RS uses the current =
standard of putting a "v2" or"v3" in it's API path... then a token =
issued for v2 of the API can not be sent to v3 of the API, because v3 =
wasn't wasn't registered/deployed when the token was issued. 

The constant management of scopes to URI =
endpoints seems like a complexity that will quickly get out of hand.

Thanks,
George
On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
 
On 25/02/16 09:02, Manger, James wrote:
I'm concerned that forcing the AS to know about all RS's =
endpoints that will accept it's tokens creates a very brittle deployment =
architecture
The AS is issuing temporary credentials (access_tokens) to =
clients but doesn=E2=80=99t know where those credentials will work? =
That=E2=80=99s broken.
 
An AS should absolutely indicate where an access_token can be =
used. draft-sakimura-oauth-meta suggests indicating this with 1 or more =
=E2=80=9Cruri=E2=80=9D (resource URI) values in an HTTP Link header. A =
better approach would be including a list of web origins in the token =
response beside the access_token field.
+1 

This will appear more consistent with the =
current experience, and OAuth does allow the token response JSON object =
to be extended with additional members (as it's done in OpenID Connect =
already).

Cheers,
Vladimir


--
James Manger
 
From: OAuth [mailto:oauth-bounces@ietf.org] On =
Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 =
Discovery Location
 
I'm concerned that forcing the AS to know about all RS's =
endpoints that will accept it's tokens creates a very brittle deployment =
architecture. What if a RS moves to a new endpoint? All clients would be =
required to get new tokens (if I understand correctly). And the RS move =
would have to coordinate with the AS to make sure all the timing is =
perfect in the switch over of endpoints.
 
I suspect a common deployment =
architecture today is that each RS requires one or more scopes to access =
it's resources. The client then asks the user to authorize a token with =
a requested list of scopes. The client can then send the token to the =
appropriate RS endpoint. The RS will not authorize access unless the =
token has the required scopes.
 
If the concern is that the client =
may accidentally send the token to a "bad" RS which will then replay the =
token, then I'd rather use a PoP mechanism because the point is that you =
want to ensure the correct client is presenting the token. Trying to =
ensure the client doesn't send the token to the wrong endpoint seems =
fraught with problems.
 
Thanks,
George



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




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





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

OAuth mailing list

OAuth@ietf.org

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



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

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

=

--Apple-Mail=_D694C9FF-D341-42BE-84F0-09113DF3B4C3--

--Apple-Mail=_8A319E3F-0089-44FA-A357-0861B1057C70
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAyMjYwOTA2NDNaMCMGCSqGSIb3DQEJBDEWBBSNRaitxx1wAVu8LZ5hTDb2
bxSIvDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBtpaVP7TExkAOoaT6LteZOor1xJzeeeIvoh3GTbba1ve3ncMaltbaC
jxMkK62YDS4jx3qyH5R9qmtRa4I5oupIns/cWysgZrxsXFUxQIG0emg5YHIFUGUjdDN2dUWH63JH
PJGG0+1JjBi5D9GuZu+uhirrFsR0s0BnhaAe3E2aH9lrYUo/ECGhFuqyeMjfh0WDrssiD/1rHeL2
vRZtxDehcKAPNw5yYJFbFmldAHSL6kMmUpdNdZQFP01HxGC0WtKj58d0DyideMWcX3duw4+ZmFvH
XGvH1koBbQze7PkUflsrHn3r2FOLDl1S5KntD9V0w4dMI+C0xcL+lQcwNJGYAAAAAAAA
--Apple-Mail=_8A319E3F-0089-44FA-A357-0861B1057C70--


From nobody Fri Feb 26 06:50:17 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647C61B2D53 for ; Fri, 26 Feb 2016 06:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt6wNUxiRDkL for ; Fri, 26 Feb 2016 06:50:15 -0800 (PST)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 10E001B2D52 for ; Fri, 26 Feb 2016 06:50:15 -0800 (PST)
Received: by mail-pa0-x231.google.com with SMTP id yy13so52154708pab.3 for ; Fri, 26 Feb 2016 06:50:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=6JN5KgcWIxMuZolh19M1FBOk+iwat2OOICi7v6Nj8rU=; b=mDSYLLR+0K7A/hr6+0siI9JcimYs/zg2Q/+T/mlL5hqEZCTG40Up3w1Tnf9CuM6Mcb NN7KLcR2fRilAMSqYkTJO4OMqXqfUsJW2S9XTudrp7XqufOeoJX7dZRqKO3JLK58drpz 1JAuWKGLDYYJQYr/QKzKHctFVQXcBZtsVN604r1RpX0p6B9ZiUz7nwKlh/CRCjYLA1TA LNSAD6hQ7JX8Swq9l7zAvhVaZi/egkgBdDykKD7674yF58u8EUB4vA8d3gryCTiOEfM+ zENIBmnn5KGRiBgDDqeDTOE2FwcCXNhx9PCSREcQik+mPPgFZTzkikJS3juvFIbCHws8 5sKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=6JN5KgcWIxMuZolh19M1FBOk+iwat2OOICi7v6Nj8rU=; b=ANXGuOv0rl6bP/d0dK2NB35d/OisSKUA2iVRrNH2r/4ORkp6r08lq/5tGHykJ17T1e MxC+9zVPhGYgUlPQoN3jp9KXQx76vNvkDaPCajIXiBrtN4XJ4RfwDqvT+2jbIS7db6Jl qOupTc1Q+vyKVkOpSBxcYUX5+zleRl71woQkK1D2t6DiEF/S392YnwBDp7n+Zl+V+7y0 sbzzvnex0rk6A3iiTr5NPfhYiQCaHdk0Xx+sfZ8DTkJI9JxNcwa/8Tr9hEKJAhCI8OD3 zpXUqTxuGZ0HTu9aSiUDaA8YGF9KCMj9qITeB0lUPOric1ZpuKm2G2Y+1/69ztLQPI3/ e0vw==
X-Gm-Message-State: AD7BkJLAEG5LDN4UZOSv+sFa2lp0dS7pJPvGtJFzVL9cwIrumEN/tlyOijTXvm6r65dXLw==
X-Received: by 10.66.150.170 with SMTP id uj10mr2513523pab.91.1456498214692; Fri, 26 Feb 2016 06:50:14 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id vy6sm20018639pac.38.2016.02.26.06.50.12 for  (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 06:50:13 -0800 (PST)
From: "Brock Allen" 
To: 
Date: Fri, 26 Feb 2016 09:49:54 -0500
Message-ID: <008201d170a4$f5216910$df643b30$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01D1707B.0C4BFD50"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFwpNhDZHY7YaWBTMm0eUjuaPDRiA==
Content-Language: en-us
Archived-At: 
Subject: [OAUTH-WG] HTTP signing spec and nonce
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 14:50:16 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0083_01D1707B.0C4BFD50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Question about the HTTP signing spec - why is there no nonce (and just a
timestamp)?

 

TIA

 

-Brock

 


------=_NextPart_000_0083_01D1707B.0C4BFD50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Question about =
the HTTP signing spec – why is there no nonce (and just a =
timestamp)?
 
TIA
 
-Brock
 

------=_NextPart_000_0083_01D1707B.0C4BFD50--


From nobody Fri Feb 26 07:28:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8971A6FBF for ; Fri, 26 Feb 2016 07:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 204E4pZGPZ-f for ; Fri, 26 Feb 2016 07:28:10 -0800 (PST)
Received: from omr-a007e.mx.aol.com (omr-a007e.mx.aol.com [204.29.186.58]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BC41A6FA8 for ; Fri, 26 Feb 2016 07:28:10 -0800 (PST)
Received: from mtaout-aaf02.mx.aol.com (mtaout-aaf02.mx.aol.com [172.26.127.98]) by omr-a007e.mx.aol.com (Outbound Mail Relay) with ESMTP id B055A3800055; Fri, 26 Feb 2016 10:28:08 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaf02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 650B038000095; Fri, 26 Feb 2016 10:28:08 -0500 (EST)
To: nov matake , Nat Sakimura 
References:     <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56D06F17.9010603@aol.com>
Date: Fri, 26 Feb 2016 10:28:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020108070906030108080005"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456500488; bh=4rUxoEfUIkpW+SjYKi6mlJkkPxbY+FbzfB+E/b4nT4I=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=gMrPUBp9XG6EY2ZuV8uTR8zHunPjjr3fIeQsouqVlr0IcWyQQdFeBf2zptDTI8/Te 9fvhdDYcZsK7jKR/S7jxTFhD7HisQIT+WXP32qGH8fz2iy8U+Canlc7Cbj3c2iNN4c rfyT3/Hia7wHjP3RYiOhq5btjat/wy+1MrNM2oJQ=
x-aol-sid: 3039ac1a7f6256d06f083566
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 15:28:14 -0000

This is a multi-part message in MIME format.
--------------020108070906030108080005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

As long as the "aud" value is more akin to a fixed URI from which the 
client can determine valid endpoints for that "aud", this could work. It 
does make the client do a lot of discovery.

I don't think the "aud" value can be a domain.

Thanks,
George

On 2/26/16 12:52 AM, nov matake wrote:
> It sounds like we want to return a list of available access tokens 
> “aud†values from AS config discovery endpoint (and also via 
> oauth-meta too?), doesn’t it?
>
> and RS config discovery endpoint will return acceptable access token 
> “iss†values, a list of every RS endpoints, required scopes per 
> endpoint etc.
> (it would be another thread though)
>
> Thanks,
> Nov
>
>> On Feb 26, 2016, at 13:08, Nat Sakimura > > wrote:
>>
>> I will include the origin in the next rev.
>>
>> For http header v.s JSON, shall I bring the JSON back in?
>> 2016年2月26日(金) 13:05 Manger, James 
>> > >:
>>
>>     You are right, George, that making the AS track /v2/… or /v3/… in
>>     RS paths is likely to be brittle — but tracking RS web origins is
>>     not too onerous.
>>
>>     PoP has some nice security advantages over bearer tokens or
>>     passwords. However, it should still be possible to use the latter
>>     fairly safely — but it does require the issuer of credentials to
>>     indicate where they can be used.
>>
>>     --
>>
>>     James Manger
>>
>>     *From:*OAuth [mailto:oauth-bounces@ietf.org
>>     ] *On Behalf Of *George Fletcher
>>     *Sent:* Friday, 26 February 2016 2:28 AM
>>     *To:* Vladimir Dzhuvinov >     >; oauth@ietf.org
>>     
>>
>>
>>     *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>     That said, I'm not against the AS informing the client that the
>>     token can be used at the MailResource, ContactResource and
>>     MessagingResource to help the client know not to send the token
>>     to a BlogResource. However, identifying the actual endpoint seems
>>     overly complex when what is really trying to be protected is a
>>     token from being used where it shouldn't be (which is solved by Pop)
>>
>>     Thanks,
>>     George
>>
>>     On 2/25/16 10:25 AM, George Fletcher wrote:
>>
>>         Interesting... this is not at all my current experience:) If
>>         a RS goes from v2 of it's API to v3 and that RS uses the
>>         current standard of putting a "v2" or"v3" in it's API path...
>>         then a token issued for v2 of the API can not be sent to v3
>>         of the API, because v3 wasn't wasn't registered/deployed when
>>         the token was issued.
>>
>>         The constant management of scopes to URI endpoints seems like
>>         a complexity that will quickly get out of hand.
>>
>>         Thanks,
>>         George
>>
>>         On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>
>>             On 25/02/16 09:02, Manger, James wrote:
>>
>>                     I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>>
>>                 The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>
>>                   
>>
>>                 An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri†(resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>>
>>             +1
>>
>>             This will appear more consistent with the current
>>             experience, and OAuth does allow the token response JSON
>>             object to be extended with additional members (as it's
>>             done in OpenID Connect already).
>>
>>             Cheers,
>>             Vladimir
>>
>>
>>                 --
>>
>>                 James Manger
>>
>>                   
>>
>>                 From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
>>
>>                 Sent: Thursday, 25 February 2016 6:17 AM
>>
>>                 To: Phil Hunt ; Nat Sakimura 
>>
>>                 Cc:    
>>
>>                 Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>                   
>>
>>                 I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>
>>                   
>>
>>                 I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>
>>                   
>>
>>                 If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>
>>                   
>>
>>                 Thanks,
>>
>>                 George
>>
>>
>>
>>
>>                 _______________________________________________
>>
>>                 OAuth mailing list
>>
>>                 OAuth@ietf.org 
>>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             OAuth mailing list
>>
>>             OAuth@ietf.org 
>>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         OAuth mailing list
>>
>>         OAuth@ietf.org 
>>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>

--------------020108070906030108080005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    As long as the "aud" value
      is more akin to a fixed URI from which the client can determine
      valid endpoints for that "aud", this could work. It does make the
      client do a lot of discovery. 

      

      I don't think the "aud" value can be a domain.

      

      Thanks,

      George

    

    
On 2/26/16 12:52 AM, nov matake wrote:

    

    

      
      
It sounds like we want to return a list of available
        access tokens “aud†values from AS config discovery endpoint
        (and also via oauth-meta too?), doesn’t it?

      


      

      
and RS config discovery endpoint will return
        acceptable access token “iss†values, a list of every RS
        endpoints, required scopes per endpoint etc.

      
(it would be another thread though)

      


      

      
Thanks,

      
Nov

      


      

      

        

          
On Feb 26, 2016, at 13:08, Nat Sakimura <sakimura@gmail.com> wrote:

          

          
I will include the origin in the next rev. 

            

            For http header v.s JSON, shall I bring the JSON back in? 

            

              
2016年2月26日(金) 13:05 Manger, James
                <James.H.Manger@team.telstra.com>:

              

              

                

                  

                    
You are right, George, that making the
                        AS track /v2/… or /v3/… in RS paths is likely to
                        be brittle — but tracking RS web origins is not
                        too onerous.

                    
 

                    
PoP has some nice security advantages
                        over bearer tokens or passwords. However, it
                        should still be possible to use the latter
                        fairly safely — but it does require the issuer
                        of credentials to indicate where they can be
                        used.

                    
 

                    
--

                    
James Manger

                    
 

                    
 

                    
 

                    

                      

                        
From: OAuth [mailto:oauth-bounces@ietf.org]
                            On Behalf Of George
                            Fletcher

                            Sent: Friday, 26 February
                            2016 2:28 AM

                            To: Vladimir Dzhuvinov <vladimir@connect2id.com>;
                            oauth@ietf.org

                      

                    

                  

                

                

                  

                    

                      

                        


                            Subject: Re: [OAUTH-WG]
                            OAuth 2.0 Discovery Location

                      

                    

                  

                

                

                  

                    
 

                    
That
                      said, I'm not against the AS informing the client
                      that the token can be used at the MailResource,
                      ContactResource and MessagingResource to help the
                      client know not to send the token to a
                      BlogResource. However, identifying the actual
                      endpoint seems overly complex when what is really
                      trying to be protected is a token from being used
                      where it shouldn't be (which is solved by Pop)

                      

                      Thanks,

                      George

                    

                      
On 2/25/16 10:25 AM, George
                        Fletcher wrote:

                    

                    

                      
Interesting...
                          this is not at all my current experience:) If
                          a RS goes from v2 of it's API to v3 and that
                          RS uses the current standard of putting a "v2"
                          or"v3" in it's API path... then a token issued
                          for v2 of the API can not be sent to v3 of the
                          API, because v3 wasn't wasn't
                          registered/deployed when the token was issued.
                          

                          

                          The constant management of scopes to URI
                          endpoints seems like a complexity that will
                          quickly get out of hand.

                          

                          Thanks,

                          George

                      

                        
On 2/25/16 2:22 AM,
                          Vladimir Dzhuvinov wrote:

                      

                      

                        
 

                        

                          
On 25/02/16 09:02,
                            Manger, James wrote:

                        

                        

                          

                            
I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture

                          

                          
The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.

                          
 

                          
An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri†(resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.

                        

                        
+1 

                          

                          This will appear more consistent with the
                          current experience, and OAuth does allow the
                          token response JSON object to be extended with
                          additional members (as it's done in OpenID
                          Connect already).

                          

                          Cheers,

                          Vladimir

                          

                          

                        

                        

                          
--

                          
James Manger

                          
 

                          
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher

                          
Sent: Thursday, 25 February 2016 6:17 AM

                          
To: Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

                          
Cc: <oauth@ietf.org> <oauth@ietf.org>

                          
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

                          
 

                          
I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.

                          
 

                          
I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.

                          
 

                          
If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.

                          
 

                          
Thanks,

                          
George

                          


                            

                            

                          

                          
_______________________________________________

                          
OAuth mailing list

                          
OAuth@ietf.org

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

                        

                        


                          

                          

                          

                        

                        
_______________________________________________

                        
OAuth mailing list

                        
OAuth@ietf.org

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

                      

                      


                        

                        

                        

                        

                      

                      
_______________________________________________

                      
OAuth mailing list

                      
OAuth@ietf.org

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

                    

                    
 

                  

                

                _______________________________________________

                OAuth mailing list

                OAuth@ietf.org

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

              

            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

          

        

      

      

    

  


--------------020108070906030108080005--


From nobody Fri Feb 26 11:31:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055F1B2EF1 for ; Fri, 26 Feb 2016 11:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.515
X-Spam-Level: 
X-Spam-Status: No, score=0.515 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 GLff-PWErFLV for ; Fri, 26 Feb 2016 11:31:09 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0DD1B2EEF for ; Fri, 26 Feb 2016 11:31:09 -0800 (PST)
Received: by mail-oi0-x236.google.com with SMTP id m82so68631066oif.1 for ; Fri, 26 Feb 2016 11:31:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=n7XbIyAjS2Tp/QES/JQdhuCoAlcp8r/qkEvgPmxuv8U=; b=f9C9xHI8UEMnTtECSOrFg/pJ+DGTWyGgWYeQA15JNZYGM7G5G1NMcZc+UCueIaIROK H4BdZpzMXcm4kXE2XJikopojgXHRwzzkqeLr+IlvbuZl2hM+gejcW5VYzCJQFnJQVWUQ ZHzPlBTjzLYI+JEYFFWO8e0U3Atf5HoJlI6f5HSzfOts6vm0DkNzugYcIJO83lBupdka Yy7kHXzmgcFaCmxXkpLsP2znHKFr+X5OL3ykreLf4xvmRltVBrAO9niCfyS6WqosEu4F 7mISPhHSlJ7y7JXkcJA6HReuznd9DTt5fTHXUGthBjeXFEYX4K4UkeHSCTKO71jDQcZI 0RpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n7XbIyAjS2Tp/QES/JQdhuCoAlcp8r/qkEvgPmxuv8U=; b=Jc/mahsg/DPHlQ279dUGRwEDiG9ehe9J59fbDiUjbCwhXez+cfKsN0NhcKTQePnmj9 Q+f+qUPIafGtwrkWr6D0oAl4i4vt4MRDv+CtFbPE/HG2xpSw2Bsr7Kb67aeGZMPz7o4J yPx3+f6vtR7+sQwKqbtEwHTv450LhaT0OYLDXpoxjL8GiP3vP6Fn3NPps4UfYtm2uhu9 AYOQ7HBdl3F5/EmzHdI1jvsDyXkICzZHh11GejOGOV1C9Eq7xHd4nyIfDbhuX1r7qVbq wN3TbGf3g/ZgOwpDsSsphhU1O5rrqOttS4Xh6XOoN23Y8R7L1HRpuGYHqRE5dCbchCsG epfw==
X-Gm-Message-State: AD7BkJLBhEMYekmKoPYvJW4joGDZbt/iyTxV4DInc+HTShWhQ2CoOOKH4HELRP76fALx2HlrT/3GMtyrAny7eToT
X-Received: by 10.202.65.65 with SMTP id o62mr2467531oia.13.1456515068359; Fri, 26 Feb 2016 11:31:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.79.233 with HTTP; Fri, 26 Feb 2016 11:30:48 -0800 (PST)
From: William Denniss 
Date: Fri, 26 Feb 2016 11:30:48 -0800
Message-ID: 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113cc9c6431ba3052cb157d4
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries for Android and iOS now available
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 19:31:11 -0000

--001a113cc9c6431ba3052cb157d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The Google Identity team this week open sourced AppAuth for Android and
iOS. AppAuth is a client library for OAuth that enables native Android and
iOS apps to perform authorization flows in a secure and usable way using
in-app browser tabs (Custom Tabs on Android, SFSafariViewController on
iOS), fully supporting the draft best practice
 for performing
standards-based auth in native apps.

The libraries are opinionated and follow the draft best practice
completely. Low-level protocol APIs are exposed allowing customizability
including the ability to support OAuth extensions and custom parameters.
Higher level convenience APIs are also provided to assist with auth state
management, and encapsulate common requests like exchanging the
authorization code and making API calls with fresh tokens.

You can grab the code here:
https://openid.github.io/AppAuth-Android
https://openid.github.io/AppAuth-iOS

The library should work with any Authorization Server that supports public
clients with custom URI scheme and/or app-claimed HTTPS redirects (custom
URI schemes are still required for full backwards compatibility support,
though on newer systems app-claimed HTTPS links are viable =E2=80=93 both a=
re
supported by the library). We have verified interop with the Google and
PingFederate OAuth implementations.

Please give it a spin, and let me know how it works with your own
implementations!

--001a113cc9c6431ba3052cb157d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The Google Identity team this week open sourced AppAu=
th for Android and iOS.=C2=A0AppAuth is a =
client library for OAuth that enables native Android and=C2=A0iOS=C2=
=A0apps to perform authorization flows in a secure and usable way using in-=
app browser tabs (Custom Tabs on Android, SFSafariViewController on iOS), f=
ully supporting the draft=C2=A0best practice=C2=A0for performing standards-based auth in native apps=
.

The libraries are opinionated and follow the dra=
ft best practice completely. Low-level protocol APIs are exposed allowing c=
ustomizability including the ability to support OAuth extensions and custom=
 parameters. Higher level convenience APIs are also provided to assist with=
 auth state management, and encapsulate common requests like exchanging the=
 authorization code and making API calls with fresh tokens.

<=
/div>
You can grab the code here:
https://openid.github.io/AppAuth-Android
https://openid.githu=
b.io/AppAuth-iOS

The library should work wi=
th any Authorization Server that supports public clients with custom URI sc=
heme and/or app-claimed HTTPS redirects (custom URI schemes are still requi=
red for full backwards compatibility support, though on newer systems app-c=
laimed HTTPS links are viable =E2=80=93 both are supported by the library).=
 We have verified interop with the Google and PingFederate OAuth implementa=
tions.

Please give it a spin, and let me know how =
it works with your own implementations!



--001a113cc9c6431ba3052cb157d4--


From nobody Fri Feb 26 14:28:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0281B31D4 for ; Fri, 26 Feb 2016 14:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FIwNe4G4a6ry for ; Fri, 26 Feb 2016 14:28:24 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 4E4471B31D2 for ; Fri, 26 Feb 2016 14:28:24 -0800 (PST)
Received: by mail-ig0-x234.google.com with SMTP id xg9so43785034igb.1 for ; Fri, 26 Feb 2016 14:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/BrVn0RrUfReeCnU14zRcCieYBJ6tJMYiQkWPzkwt+c=; b=oLzTCzNFUMVXbW+JosoWzffoXTeQl1rhngqB6zOlH9OrhTjpeXvTu6Z5/NqVYnPYgo MHEfFFRoU+1d9EWGC6gM7JI4KdkFyuTJi/bfk1KxmkbazCELs2R0MEq4SdrCIbyftMQ5 W3udWfnMQSY43i2/iVmXKhaFAMGaKOkKyrvUs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/BrVn0RrUfReeCnU14zRcCieYBJ6tJMYiQkWPzkwt+c=; b=blExTtEUgQ+JDhcVZfIN14HJ/HibWpnIjEzJ4kQM1ZS/I+ei13Y5O9eo5koFd/fkQt m6VZUcez9OtCyM4IDSV1sns9oxAfavECAhanPi706tIFdLOyWFewQmvqAD4M6KF2G82N zD3k8/YBboxQSwMEEacRmA56ldz4LQ/klqQrL2q8+jnm1qYsEUoxzUzCdAzAO03bMtLA /+uC9stQFuUhVhxdOFTl3zXUqv7jNXZR4OgMNWYTk4cU2upbfKUHEkHFFKDjoA1/qWI9 kzY7P9gv+2LCdPBzw/m4Oxym+sYIYxR/xlKYz2ia5NzaVvvtJNG28h5ryyJh5rt0V2My wfbw==
X-Gm-Message-State: AD7BkJJxk5ZPe55I3W2rPiX+K8URzRVUppjchpgJLqGqiuADNN1rl/4IDZ+0Uz0SeftskbOh9HBSO+Hf1q/6Jsj7
X-Received: by 10.50.60.34 with SMTP id e2mr249742igr.77.1456525703643; Fri, 26 Feb 2016 14:28:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 26 Feb 2016 14:27:54 -0800 (PST)
In-Reply-To: <56CEB0A6.4050500@gmx.net>
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net>
From: Brian Campbell 
Date: Fri, 26 Feb 2016 15:27:54 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=047d7b10ce3b2c298a052cb3d130
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2016 22:28:27 -0000

--047d7b10ce3b2c298a052cb3d130
Content-Type: text/plain; charset=UTF-8

My preference is for Option A.

The mix-up attack, in all it's variations, relies on there being no means
in OAuth for the AS to identify itself to the client when it returns the
user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation'
addresses that fundamental missing piece by including the 'iss'
authorization response parameter.

During the course of the discussions in Darmstadt Hans and I independently
implemented and successfully interop tested the 'iss' and 'client_id'
authorization response parameters, which is what was anticipated to be in
the mitigation draft. Doing so was very simple and straightforward. And it
addresses the vulnerability. We decided, unfortunately, to pull that
functionality out of a looming a product release due to the churn in this
WG and the perceived risk of changes in what would eventually become the
standard solution. Of course, that kind of risk is always present with
draft standards but it's been very frustrating in this case to have worked
towards a simple solution to a known problem only to have progress get hung
up in lack of agreement in this WG.

I'll also say that in many/most cases the AS doesn't explicitly know all of
the resources that tokens it issues can or will be used at (and there are
often more than one). So the ruri/Resource URI parameter isn't really a
workable option.



On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Vladimir,
>
> yes, we could do a formal analysis and it would be a very good idea.
> It would even go faster if a few of us work together on it. Anyone
> interested?
>
> This would be a good contribution for the workshop in July, btw.
>
> Ciao
> Hannes
>
> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
> > Hi Mike,
> >
> > You mention that you spent considerable time in research. I wonder if
> > there is existing theory, in communications or information theory, that
> > can be used to formally establish and prove (or disprove) the security
> > of the proposed OAuth measures? Perhaps some work that is totally
> > unrelated to identity and the web protocols, but could well apply here?
> >
> > My reasoning is that we have a closed system that is fairly simple, so
> > formal analysis must be entirely possible.
> >
> > 1. We have 5 parties (client, AS, RS, user, user agent).
> >
> > 2. The OAuth protocol follows a simple and well-defined pattern of
> > messages between the parties.
> >
> > 3. The points and the number of ways by which an adversary may break
> > into OAuth must therefore be finite.
> >
> > 4. The security requirement is essentially to guarantee the precedence
> > and authenticity of the messages from discovery endpoint to RS, and the
> > preferred way to do that is by establishing a binding between the
> > messages, which can be forward or backward binding.
> >
> >
> > Right now the WG concern is whether all possible attacks have been
> > recognised, and then taken care of. If we can have a formal model that
> > can reliably reveal and prove that, this will be a huge breakthrough.
> >
> > Cheers,
> >
> > Vladimir
> >
> >
> >
> > On 20/02/16 12:41, Mike Jones wrote:
> >> Suggesting that they be read is of course, the right long-term
> approach.  But as someone who spent 20+ years as a researcher before
> switching to digital identity, I was sensitive to not wanting to upstage
> their work by copying too much of their material into our draft before
> their publications were widely known.  I'll of course commit to working the
> researchers and the working group to create a self-contained concise
> description of the threats and mitigations in the working group document.
> >>
> >>                              Cheers,
> >>                              -- Mike
> >>
> >> -----Original Message-----
> >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> >> Sent: Saturday, February 20, 2016 2:25 AM
> >> To: Mike Jones ; William Denniss <
> wdenniss@google.com>; Phil Hunt (IDM) 
> >> Cc: oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call
> for Adoption
> >>
> >> Hi Mike,
> >>
> >> On 02/20/2016 10:52 AM, Mike Jones wrote:
> >>> Have you read both of their publications?  If not, do yourself a favor
> >>> and do.  They're actually both very readable and quite informative.
> >> I have read both documents. In context of this discussion the question
> is whether we
> >>
> >> (a) require them to be read (in which case they should be a normative
> reference), or
> >> (b) suggest them to be read (since they provide additional background
> information). In this case they are an informative reference.
> >>
> >> I believe believe we want (b) for the OAuth WG document. While I
> encourage everyone to read the publications I also believe that there is
> lots of material in there that goes beyond the information our audience
> typically reads (such as the text about the formal analysis).
> >>
> >> There is probably also a middle-ground where we either copy relevant
> text from the papers into the draft or reference specific sections that are
> "must-read".
> >>
> >> One other issue: I actually thought that the threat that is outlined in
> the research paper is sufficiently well described but the second threat,
> which is called 'cut-and-paste attack', requires more work.
> >> I noted this in my summary mail to the list, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--047d7b10ce3b2c298a052cb3d130
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


My preference is for Option A. 

The mix-up attack, in all it's variations, relies on there being no m=
eans in OAuth for the AS to identify itself to the client when it returns t=
he user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-=
Up Mitigation' addresses that fundamental missing piece by including th=
e 'iss' authorization response parameter. 

During the =
course of the discussions in Darmstadt Hans and I independently implemented=
 and successfully interop tested the 'iss' and 'client_id' =
authorization response parameters, which is what was anticipated to be in t=
he mitigation draft. Doing so was very simple and straightforward. And it a=
ddresses the vulnerability. We decided, unfortunately, to pull that functio=
nality out of a looming a product release due to the churn in this WG and t=
he perceived risk of changes in what would eventually become the standard s=
olution. Of course, that kind of risk is always present with draft standard=
s but it's been very frustrating in this case to have worked towards a =
simple solution to a known problem only to have progress get hung up in lac=
k of agreement in this WG. =C2=A0 =C2=A0 

I'll also s=
ay that in many/most cases the AS doesn't explicitly know all of the re=
sources that tokens it issues can or will be used at (and there are often m=
ore than one). So the ruri/Resource URI parameter isn't really a workab=
le option. 



On Thu, Feb 2=
5, 2016 at 12:43 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net<=
/a>> wrote:
Vladimir,



yes, we could do a formal analysis and it would be a very good idea.

It would even go faster if a few of us work together on it. Anyone

interested?



This would be a good contribution for the workshop in July, btw.



Ciao

Hannes




On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:

> Hi Mike,

>

> You mention that you spent considerable time in research. I wonder if<=
br>
> there is existing theory, in communications or information theory, tha=
t

> can be used to formally establish and prove (or disprove) the security=


> of the proposed OAuth measures? Perhaps some work that is totally

> unrelated to identity and the web protocols, but could well apply here=
?

>

> My reasoning is that we have a closed system that is fairly simple, so=


> formal analysis must be entirely possible.

>

> 1. We have 5 parties (client, AS, RS, user, user agent).

>

> 2. The OAuth protocol follows a simple and well-defined pattern of

> messages between the parties.

>

> 3. The points and the number of ways by which an adversary may break
> into OAuth must therefore be finite.

>

> 4. The security requirement is essentially to guarantee the precedence=


> and authenticity of the messages from discovery endpoint to RS, and th=
e

> preferred way to do that is by establishing a binding between the

> messages, which can be forward or backward binding.

>

>

> Right now the WG concern is whether all possible attacks have been

> recognised, and then taken care of. If we can have a formal model that=


> can reliably reveal and prove that, this will be a huge breakthrough.<=
br>
>

> Cheers,

>

> Vladimir

>

>

>

> On 20/02/16 12:41, Mike Jones wrote:

>> Suggesting that they be read is of course, the right long-term app=
roach.=C2=A0 But as someone who spent 20+ years as a researcher before swit=
ching to digital identity, I was sensitive to not wanting to upstage their =
work by copying too much of their material into our draft before their publ=
ications were widely known.=C2=A0 I'll of course commit to working the =
researchers and the working group to create a self-contained concise descri=
ption of the threats and mitigations in the working group document.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

>>

>> -----Original Message-----

>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]

>> Sent: Saturday, February 20, 2016 2:25 AM

>> To: Mike Jones <=
Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>

>> Cc: oauth@ietf.org

>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Ca=
ll for Adoption

>>

>> Hi Mike,

>>

>> On 02/20/2016 10:52 AM, Mike Jones wrote:

>>> Have you read both of their publications?=C2=A0 If not, do you=
rself a favor

>>> and do.=C2=A0 They're actually both very readable and quit=
e informative.

>> I have read both documents. In context of this discussion the ques=
tion is whether we

>>

>> (a) require them to be read (in which case they should be a normat=
ive reference), or

>> (b) suggest them to be read (since they provide additional backgro=
und information). In this case they are an informative reference.

>>

>> I believe believe we want (b) for the OAuth WG document. While I e=
ncourage everyone to read the publications I also believe that there is lot=
s of material in there that goes beyond the information our audience typica=
lly reads (such as the text about the formal analysis).

>>

>> There is probably also a middle-ground where we either copy releva=
nt text from the papers into the draft or reference specific sections that =
are "must-read".

>>

>> One other issue: I actually thought that the threat that is outlin=
ed in the research paper is sufficiently well described but the second thre=
at, which is called 'cut-and-paste attack', requires more work.

>> I noted this in my summary mail to the list, see http://www.ietf.org/mail-archive/web/oauth/current/ms=
g15697.html

>>

>> Ciao

>> Hannes

>>

>>

>> _______________________________________________

>> OAuth mailing list

>> OAuth@ietf.org

>> https://www.ietf.org/mailman/listinfo/oauth<=
br>
>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

>





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--047d7b10ce3b2c298a052cb3d130--


From nobody Fri Feb 26 18:43:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA5F1B3329 for ; Fri, 26 Feb 2016 18:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XubvmxLn6fLm for ; Fri, 26 Feb 2016 18:42:55 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C1C1B331C for ; Fri, 26 Feb 2016 18:42:53 -0800 (PST)
X-AuditID: 1209190d-463ff70000002cc5-2a-56d10d25b072
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id ED.B9.11461.52D01D65; Fri, 26 Feb 2016 21:42:45 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1R2giEa027768; Fri, 26 Feb 2016 21:42:45 -0500
Received: from [172.27.5.37] (75-104-65-21.mobility.exede.net [75.104.65.21]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1R2gUtU026697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Feb 2016 21:42:38 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_5206E4BE-D692-465F-B1E6-6FC5C5B32109"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <56CF53ED.2050609@aol.com>
Date: Fri, 26 Feb 2016 21:42:28 -0500
Message-Id: <9AF27019-E89E-4FA7-822B-468328ED7280@mit.edu>
References:     <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>  <4C62FA24-38D3-44E7-8FFB-EF4C6E653FB0! ! @oracle.com>  <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>  <56CF53ED.2050609@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsUixG6noqvKezHMYP5+fYs7XSvYLfZO+8Ri cfLtKzaLd+8+MDqweNzfvZLdY/7nFlaPJUt+Mnm07vjLHsASxWWTkpqTWZZapG+XwJVxa+V9 loJN31gqTrVsZ2lgfNHC0sXIySEhYCLx4MUFpi5GLg4hgTYmiaVzutkhnI2MEl/aZjFCOKeY JFq63rCCtDALJEicXHaeEcTmFdCTeHXrMlhcGGjUw6nTwGw2AVWJ6WtagMZycHAKqEtsOuAO EmYBCv+9/oQFZCazwERGiYZnU1gg5lhJnP8ykw1iWTeHxKx9T8EGiQioSTStXMMIcausxO7f j5gmMPLPQnLHLCR3QMS1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJ usXJiXl5qUW6Rnq5mSV6qSmlmxhBkcApybuD8d9dr0OMAhyMSjy8GWsuhAmxJpYVV+YeYpTk YFIS5c34CBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwhuyDCjHm5JYWZValA+TkuZgURLnjbl5 NExIID2xJDU7NbUgtQgmK8PBoSTBO5/7YpiQYFFqempFWmZOCUKaiYMTZDgP0PA9IDW8xQWJ ucWZ6RD5U4z2HAuO3V7LxLFv3R0g+ePgPSB55SiQFGLJy89LlRLnbQFpEwBpyyjNg5sMSnLe GY6irxjFgR4V5n0FUsUDTJBws18BrWUCWjtzwzmQtSWJCCmpBkbmxevqtu94r7AqdpvkojmH 29OXu3fmKAb/MP2Q/Irxypc7Es3776s7haX5eq9NFQhq+iP2tH3Lp9b7fSdiYgxm+l6udjx/ dRWLn9MFy7+5qjLyW+f8y9HreTZtqcuSI57GK3ZpfY601zsyt+Uw9x3JhbsDj3CuiLoZLnjs walCrnsCfu3P2A8qsRRnJBpqMRcVJwIAT+AH000DAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 02:43:03 -0000

--Apple-Mail=_5206E4BE-D692-465F-B1E6-6FC5C5B32109
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D

 =E2=80=94 Justin

> On Feb 25, 2016, at 2:20 PM, George Fletcher  wrote:
>=20
> +1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
>=20
> On 2/25/16 2:10 PM, Mike Jones wrote:
>> Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly =
inclined to accept your suggestion to change the title from =E2=80=9COAuth=
 2.0 Discovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D.  While the abstract already makes it clear that the =
scope of the document is AS discovery, doing so in the title seems like =
it could help clarify things, given that a lot of the discussion seems =
to be about resource discovery, which is out of scope of the document.
>> =20
>> I=E2=80=99m not saying that resource discovery isn=E2=80=99t =
important =E2=80=93 it is =E2=80=93 but unlike authorization server =
discovery, where there=E2=80=99s lots of existing practice, including =
using the existing data format for describing OAuth implementations that =
aren=E2=80=99t being used with OpenID Connect, there=E2=80=99s no =
existing practice to standardize for resource discovery.  The time to =
create a standard for that seems to be after existing practice has =
emerged.  It *might* or might not use new metadata values in the AS =
discovery document, but that=E2=80=99s still to be determined.  The one =
reason to leave the title as-is is that resource discovery might end up =
involving extensions to this metadata format in some cases.
>> =20
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  The discovery =
document is about the AS.  We don=E2=80=99t yet have a specification or =
existing practice for RS discovery, which would be the 6750 analogy.
>> =20
>> In summary, which title do people prefer?
>> =C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
>> =C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D=

>> =20
>>                                                           -- Mike
>> =C2=A0 <>
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Vladimir Dzhuvinov
>> Sent: Thursday, February 25, 2016 12:59 AM
>> To: oauth@ietf.org 
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> In OIDC the discovery doc is of great utility to developers and =
integrators. Developers also tend to find it a more accurate and =
complete description of how to set up a client for a particular =
deployment, compared to traditional online docs, which may be not be up =
to date, or even missing. Very much like auto-generated Swagger and =
JavaDocs.
>>=20
>> Here are some example OIDC discovery docs:
>>=20
>> https://accounts.google.com/.well-known/openid-configuration =

>>=20
>> https://www.paypalobjects.com/.well-known/openid-configuration =

>>=20
>> =
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-k=
nown/openid-configuration =

>>=20
>>=20
>> With this discovery document in place setup of identity federation =
can then be easily scripted. For example:
>>=20
>> =
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_=
oidc_verify-thumbprint.html =

>>=20
>>=20
>> Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one =
arrives at the ".well-known/...". I'm not even sure that resource =
discovery should be a topic of this WG. Perhaps to this end, and to =
prevent confusion that the spec is trying to do something more, a more =
specific title would suit it better. E.g. "AS Discovery".
>>=20
>> Cheers,
>>=20
>> Vladimir
>>=20
>>=20
>>=20
>>=20
>> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>> And so does oracle and so does google. Each different.=20
>> =20
>> So how can an app dictate it then unless we all go to a common =
architecture?
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 16:04, Mike Jones  =
 wrote:
>> =20
>> Azure defines ways for resource servers to be registered for use with =
a client and for clients to dynamically request an access token for use =
at a particular resource server.  You can call that custom architecture =
if you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently =
in the standards realm.  I know that Google has syntax for doing the =
same, as I=E2=80=99m sure do a lot of other cloud OAuth deployments, =
such as Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working =
group talked about possibly producing a standard version of syntax for =
making these kinds of requests during our discussions in Prague (during =
the Token Exchange discussion) but nobody has run with this yet.
>> =20
>> In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 =
discovery metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
>> =20
>>                                                                 -- =
Mike
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Mike
>> =20
>> Take a look at the assumptions you are making.=20
>> =20
>> You seem to be assuming application software dictates oauth =
infrastructure architecture by suggesting that apps register in iana. =20=

>> =20
>> Would ms azure allow custom arch?
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 15:28, Mike Jones  =
 wrote:
>> =20
>> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be =
discovered.
>> =20
>> I agree that for some OAuth profiles, one or more resource servers =
will have to be discovered starting from the authorization server.  =
Working group members have also described wanting to discover =
authorization servers starting from resource servers.  There isn=E2=80=99t=
 a standard practice for any of this, which is why it=E2=80=99s =
intentionally left out of the current specification.
>> =20
>> Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it =
will be easy for subsequent specifications to document existing practice =
for different OAuth profiles and register discovery metadata values =
supporting them.  Some of those values will likely define ways to =
discover resource servers, when applicable.
>> =20
>> But first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
>> =20
>>                                                                 -- =
Mike
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones  =

>> Cc:    =

>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Yup. And because there many relations the client mist be able to =
discover it. The client does not know if the res server is legit.=20
>> =20
>> The userinfo is always fix and so u dont need discovery.=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 14:05, Mike Jones  =
 wrote:
>> =20
>> In OpenID Connect, there=E2=80=99s a resource server called the =
UserInfo Endpoint that returns claims about the authenticated user as a =
JSON data structure.  Its location is published in OpenID Connect =
discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata =
value, which is defined at =
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata=
 =
.
>> =20
>> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they needn=E2=80=99=
t be one-to-one, as is being actively discussed by the working group.  =
For instance, see George Fletcher=E2=80=99s recent contribution.
>> =20
>> Thanks for the good discussion, Phil.
>> =20
>>                                                                 -- =
Mike
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
>> Sent: Wednesday, February 24, 2016 1:25 PM
>> To: Mike Jones
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Where is the profile endpoint (oidc's resource server) published? =
(For the non OIDC people on the list).=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 13:09, Mike Jones  =
 wrote:
>> =20
>> To the extent that generic OAuth 2.0 needs to publish some of the =
same information as OpenID Connect =E2=80=93 which is built on generic =
OAuth 2.0 =E2=80=93 it makes sense to publish that information using =
exactly the same syntax, since that syntax is already in widespread use. =
 That what this draft accomplishes.
>> =20
>> There=E2=80=99s nothing Connect-specific about using metadata =
response values like:
>> =20
>>    "authorization_endpoint": "https://server.example.com/authorize" =
,
>>    "token_endpoint": "https://server.example.com/token" =
,
>>    "token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
>>    "registration_endpoint": "https://server.example.com/register" =
,
>>    "response_types_supported":  ["code", "token"],
>>    "service_documentation": =
"http://server.example.com/service_documentation.html" =
,
>> =20
>> Is there a reason that you would like the syntax for any of these or =
the other generally applicable OAuth 2.0 metadata values to be =
different?  I don=E2=80=99t see any good reason for unnecessary =
differences to be introduced.
>> =20
>>                                                                 -- =
Mike
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
>> Sent: Wednesday, February 24, 2016 12:45 PM
>> To: Anthony Nadalin  =

>> Cc: Mike Jones  =
;  =
  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Mike
>> =20
>> Publishing on dev pages does not work for software (esp open source) =
that is deployed both in enterprises and on PaaS cloud providers.=20
>> =20
>> The current draft is may codify current OIDC practice and be =
appropriate for oidc but it is not ready for generic oauth. There is no =
generic oauth experience at this time.=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 10:25, Anthony Nadalin  =
 wrote:
>> =20
>> Sure there is, it is as you have now made it far easier and the =
security considerations does not even address this
>> =20
>> From: Mike Jones=20
>> Sent: Wednesday, February 24, 2016 10:22 AM
>> To: Anthony Nadalin  =

>> Cc:    =

>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> As we=E2=80=99d discussed in person, there=E2=80=99s no effective =
security difference between discovery information being published in an =
ad-hoc fashion on developer pages and it being published in a standard =
format.  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security =
at all.
>> =20
>>                                                           -- Mike
>> =20
>> From: Anthony Nadalin=20
>> Sent: Wednesday, February 24, 2016 10:01 AM
>> To: Mike Jones  =
; Phil Hunt (IDM) =
 ; Nat Sakimura =
 
>> Cc:    =

>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
>> =20
>> That may be widely deployed for OIDC but not widely deployed for =
OAuth. There are some authentication mechanism discovery for endpoint =
that really should not be in an OAuth standard since it=E2=80=99s really =
not dealt with. Now that all this information is available it makes =
poking around the endpoint more focused for people that want to disrupt =
your endpoints, that is really not addressed in the security =
considerations  section at all
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Mike Jones
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Phil Hunt (IDM)  =
; Nat Sakimura  =

>> Cc:    =

>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
>> =20
>> None of Nat or John or I are suggesting that additional related =
functionality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  =
Some applications will use WebFinger to locate the discovery metadata.  =
Some will possibly use link headers.  Some will possibly use =
application-specific .well-known values.  I=E2=80=99m sure there=E2=80=99s=
 other things I haven=E2=80=99t even thought about.  All of these depend =
upon having a discovery metadata document format and none of them change =
it =E2=80=93 other than possibly to register additional discovery =
metadata values.
>> =20
>> So by all means, the working group should continue discussing =
inventing possible new related mechanisms that make sense in some =
contexts.  At the same time, we can finish standardizing the already =
widely deployed core functionality that all of these mechanisms will =
need.
>> =20
>>                                                           -- Mike
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Phil Hunt (IDM)
>> Sent: Wednesday, February 24, 2016 8:39 AM
>> To: Nat Sakimura  
>> Cc:    =

>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> I am suggesting that part of the discovery solution has to be the =
client indicating what resource endpoint it wants the oauth =
configuration data for.=20
>> =20
>> So if res.example.evil.com is not a valid resource endpoint for =
as.example.com the authz discovery should fail in some way (eg return =
nothing).=20
>> =20
>> There may be better ways to do this. Eg combine discovery. Or change =
the order of discovery.=20
>> =20
>> One of OAuth's strength's and weaknesses is that the target of =
authorization (the resource) is never specified. It is often bound up in =
the client registration and an often implied 1:1 relationship between =
resource and as. Given that in discovery phase registration has not yet =
occurred it seems important that the client know it has a valid =
combination of endpoints etc.=20
>> =20
>> This is why I was disappointed about wglc on discovery. We had a =
starting point for group adoption but we haven't really defined the full =
requirements IMO.=20
>> =20
>> I am on vacation or I would put some thought into some draft changes =
or a new draft. I apologize I can't do it now.=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 08:12, Nat Sakimura  =
 wrote:
>> =20
>> Hi Phil,=20
>> =20
>> Are you suggesting that the AS metadata should include the RS URIs? =
Currently, it does not, but it can be done, I guess.=20
>> =20
>> The way oauth-meta works is that=20
>> =20
>> 1. RS tells the client where the AS is.=20
>> 2. AS tells the client which RS endpoints the token can be used.=20
>> =20
>> Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will =
say that is not the place the client may want to send the token to.=20
>> =20
>> Nat
>> =20
>> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt =
 :
>> Nat,
>> =20
>> I=E2=80=99m not sure that having the resource server tell the client =
where its authorization server is secure by itself. The relationship =
between the Authorization Server and the Resource server need to be =
bound together in one of the discovery endpoints (the resource and/or =
the oauth service discovery).
>> =20
>> If a client discovers a fake resource server that is proxying for a =
real resource server the current discovery spec will not lead the client =
to understand it has the wrong resource server. Rather the fake resource =
service will just have a fake discovery service. The hacker can now =
intercept resource payload as well as tokens because they were able to =
convince the client to use the legit authorization service but use the =
token against the hackers proxy.
>> =20
>> The OAuth Discovery service needs to confirm to the client that the =
server is able to issue tokens for a stated resource endpoint.
>> =20
>> This not only works in normal OAuth but should add security even to =
UMA situations.
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>> =20
>> =20
>> =20
>> =20
>> =20
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  =
 wrote:
>> =20
>> =20
>> Hi Thomas,=20
>> =20
>> inline:=20
>> =20
>> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
 :
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any =
URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a =
basis for other metadata specs (like OpenID Connect).=20
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed=20
>> =20
>> Yup. That's one of the requirements to be RESTful, is it not? =20
>> =20
>> In OAuth's case, the resource and the authorization server are =
usually tightly coupled. (Otherwise, you need another specs like UMA.)=20=

>> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as =
well return the location of the authz server configuration data. In =
these cases, you do not have to decide on what .well-known uri as you =
say. This frees up developers from configuration file location =
collisions etc. We should strive not to pollute the uri space as much as =
possible.=20
>> =20
>> (well, except if there are several ASs each with different scopes; =
sounds like an edge-case to me though; maybe RFC6750 should instead be =
updated with such a parameter such that an RS could return several =
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>> =20
>> Yeah, I guess it is an edge case. I would rather like to see these =
authz servers to develop a trust framework under which they can agree on =
a single set of common scope parameter values.=20
>> =20
>> Cheers,=20
>> =20
>> Nat
>> =20
>> =20
>> =20
>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  =
 wrote:
>> The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
>> =20
>> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery =
document.
>> =20
>>  =E2=80=94 Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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

>>=20
>>=20
>> --=20
>> Vladimir Dzhuvinov :: vladimir@connect2id.com =

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

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


--Apple-Mail=_5206E4BE-D692-465F-B1E6-6FC5C5B32109
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 for =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D

 =E2=80=94 Justin

On =
Feb 25, 2016, at 2:20 PM, George Fletcher <gffletch@aol.com> =
wrote:



 =20
  

    +1 for =
=E2=80=9COAuth
      2.0 Authorization Server Discovery=E2=80=9D

    

    
On 2/25/16 2:10 PM, Mike Jones =
wrote:

    

    

     =20
      
      
      
Thanks
            for your thoughts, Vladimir.  I=E2=80=99m increasingly =
inclined to
            accept your suggestion to change the title from =E2=80=9COAuth=
 2.0
            Discovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization =
Server Discovery=E2=80=9D. 
            While the abstract already makes it clear that the scope of
            the document is AS discovery, doing so in the title seems
            like it could help clarify things, given that a lot of the
            discussion seems to be about resource discovery, which is
            out of scope of the document.
 
I=E2=80=99m
            not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93
            but unlike authorization server discovery, where there=E2=80=99=
s
            lots of existing practice, including using the existing data
            format for describing OAuth implementations that aren=E2=80=99=
t
            being used with OpenID Connect, there=E2=80=99s no existing =
practice
            to standardize for resource discovery.  The time to =
create a
            standard for that seems to be after existing practice has
            emerged.  It *might* or might not use =
new metadata
            values in the AS discovery document, but that=E2=80=99s =
still to be
            determined.  The one reason to leave the title as-is is =
that
            resource discovery might end up involving extensions to this
            metadata format in some cases.
 
I
            think an analogy to the core OAuth documents RFC 6749 and
            RFC 6750 applies.  6749 is about the AS.  6750 is =
about the
            RS.  The discovery document is about the AS.  We =
don=E2=80=99t yet
            have a specification or existing practice for RS discovery,
            which would be the 6750 analogy.
 
In
            summary, which title do people prefer?
=C2=B7      
              =E2=80=9COAuth
            2.0 Discovery=E2=80=9D
=C2=B7      
              =E2=80=9COAuth
            2.0 Authorization Server Discovery=E2=80=9D
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;         
            -- Mike
 

        
        

          
From:
                OAuth [mailto:oauth-bounces@ietf.org]
                On Behalf Of Vladimir Dzhuvinov

                Sent: Thursday, February 25, 2016 =
12:59 AM

                To: oauth@ietf.org

                Subject: Re: [OAUTH-WG] OAuth 2.0 =
Discovery
                Location

          

        
 
In OIDC the
          discovery doc is of great utility to developers and
          integrators. Developers also tend to find it a more accurate
          and complete description of how to set up a client for a
          particular deployment, compared to traditional online docs,
          which may be not be up to date, or even missing. Very much
          like auto-generated Swagger and JavaDocs.

          

          Here are some example OIDC discovery docs:

          

          https://accounts.google.com/.well-known/openid-configuration

          

          https://www.paypalobjects.com/.well-known/openid-configuration<=
/a>

          

          https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v=
2.0/.well-known/openid-configuration

          

          

          With this discovery document in place setup of identity
          federation can then be easily scripted. For example:

          

          http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_provid=
ers_create_oidc_verify-thumbprint.html

          

          

          Now, does that dictate any particular app architecture? My
          reading of the spec is that it doesn't, and it shouldn't
          either. By staying neutral on the topics of RS discovery and
          registering RPs with RSs. And how one arrives at the
          ".well-known/...". I'm not even sure that resource discovery
          should be a topic of this WG. Perhaps to this end, and to
          prevent confusion that the spec is trying to do something
          more, a more specific title would suit it better. E.g. "AS
          Discovery".

          

          Cheers,

          

          Vladimir

          

          

          

          

        
On 25/02/16 02:25, Phil =
Hunt (IDM) wrote:

        

        

          
And so does oracle and so does google. Each =
different. 

          
 

          
So how can an app dictate it then unless we =
all go to a common architecture?

          
 

          
Phil

          
 

          

            
On Feb 24, 2016, at 16:04, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
Azure defines ways for resource servers to =
be registered for use with a client and for clients to dynamically =
request an access token for use at a particular resource server.  =
You can call that custom architecture if you want.  It=E2=80=99s =
well-defined but it=E2=80=99s not currently in the standards =
realm.  I know that Google has syntax for doing the same, as I=E2=80=99=
m sure do a lot of other cloud OAuth deployments, such as =
Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working group =
talked about possibly producing a standard version of syntax for making =
these kinds of requests during our discussions in Prague (during the =
Token Exchange discussion) but nobody has run with this yet.

            
 

            
In this sense, yes, Azure is an application =
of the kind we=E2=80=99re talking about.  Azure already does define =
specific new OAuth 2.0 discovery metadata values that are used in =
production.  A registry just doesn=E2=80=99t yet exist in which it =
can register those that are of general applicability.

            
 

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

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 3:52 =
PM

            
To: Mike Jones

            
Cc: <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
Mike

            
 

            
Take a look at the assumptions you are =
making. 

            
 

            
You seem to be assuming application software =
dictates oauth infrastructure architecture by suggesting that apps =
register in iana.  

            
 

            
Would ms azure allow custom arch?

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
The UserInfo Endpoint path isn=E2=80=99t =
fixed and so has to be discovered.

            
 

            
I agree that for some OAuth profiles, one or =
more resource servers will have to be discovered starting from the =
authorization server.  Working group members have also described =
wanting to discover authorization servers starting from resource =
servers.  There isn=E2=80=99t a standard practice for any of this, =
which is why it=E2=80=99s intentionally left out of the current =
specification.

            
 

            
Once the IANA OAuth Discovery Metadata =
Registry has been established, which will happen after the current =
specification has been approved, it will be easy for subsequent =
specifications to document existing practice for different OAuth =
profiles and register discovery metadata values supporting them.  =
Some of those values will likely define ways to discover resource =
servers, when applicable.

            
 

            
But first, we need to finish the existing =
spec, so that the registry enabling these extensions gets established in =
the first place.

            
 

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

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 2:13 =
PM

            
To: Mike Jones <Michael.Jones@microsoft.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
Yup. And because there many relations the =
client mist be able to discover it. The client does not know if the res =
server is legit. 

            
 

            
The userinfo is always fix and so u dont =
need discovery. 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
In OpenID Connect, there=E2=80=99s a =
resource server called the UserInfo Endpoint that returns claims about =
the authenticated user as a JSON data structure.  Its location is =
published in OpenID Connect discovery metadata as the =
=E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is defined at =
http://openid.net/specs/openid-connect-discovery-1_0.html#Provi=
derMetadata.

            
 

            
We didn=E2=80=99t include the UserInfo =
Endpoint in the generic OAuth discovery spec since in OAuth, there are =
lots of possible relationships between authorization servers and =
resource servers and they needn=E2=80=99t be one-to-one, as is being =
actively discussed by the working group.  For instance, see George =
Fletcher=E2=80=99s recent contribution.

            
 

            
Thanks for the good discussion, Phil.

            
 

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

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 1:25 =
PM

            
To: Mike Jones

            
Cc: <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
Where is the profile endpoint (oidc's =
resource server) published? (For the non OIDC people on the list). 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:

            
 

            
To the extent that generic OAuth 2.0 needs =
to publish some of the same information as OpenID Connect =E2=80=93 =
which is built on generic OAuth 2.0 =E2=80=93 it makes sense to publish =
that information using exactly the same syntax, since that syntax is =
already in widespread use.  That what this draft accomplishes.

            
 

            
There=E2=80=99s nothing Connect-specific =
about using metadata response values like:

            
 

            
   "authorization_endpoint": =
"https://server.example.com/authorize",

            
   "token_endpoint": "https://server.example.com/token",

            
   =
"token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],

            
   "registration_endpoint": "https://server.example.com/register",

            
   =
"response_types_supported":  ["code", "token"],

            
   "service_documentation": "http://server.example.com/service_documentation.html",

            
 

            
Is there a reason that you would like the =
syntax for any of these or the other generally applicable OAuth 2.0 =
metadata values to be different?  I don=E2=80=99t see any good =
reason for unnecessary differences to be introduced.

            
 

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

            
 

            
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 

            
Sent: Wednesday, February 24, 2016 12:45 =
PM

            
To: Anthony Nadalin <tonynad@microsoft.com>

            
Cc: Mike Jones <Michael.Jones@microsoft.com>; <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
Mike

            
 

            
Publishing on dev pages does not work for =
software (esp open source) that is deployed both in enterprises and on =
PaaS cloud providers. 

            
 

            
The current draft is may codify current OIDC =
practice and be appropriate for oidc but it is not ready for generic =
oauth. There is no generic oauth experience at this time. 

            
 

            
Phil

            
 

            
On Feb 24, 2016, at 10:25, Anthony Nadalin =
<tonynad@microsoft.com> wrote:

            
 

            
Sure there is, it is as you have now made it =
far easier and the security considerations does not even address =
this

            
 

            
From: Mike Jones 

            
Sent: Wednesday, February 24, 2016 10:22 =
AM

            
To: Anthony Nadalin <tonynad@microsoft.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
As we=E2=80=99d discussed in person, =
there=E2=80=99s no effective security difference between discovery =
information being published in an ad-hoc fashion on developer pages and =
it being published in a standard format.  =E2=80=9CSecurity by =
obscurity=E2=80=9D adds no real security at all.

            
 

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

            
 

            
From: Anthony Nadalin 

            
Sent: Wednesday, February 24, 2016 10:01 =
AM

            
To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            

              
The point of the WGLC is to finish =
standardizing the core discovery functionality that=E2=80=99s already =
widely deployed.

            

            
 

            
That may be widely deployed for OIDC but not =
widely deployed for OAuth. There are some authentication mechanism =
discovery for endpoint that really should not be in an OAuth standard =
since it=E2=80=99s really not dealt with. Now that all this information =
is available it makes poking around the endpoint more focused for people =
that want to disrupt your endpoints, that is really not addressed in the =
security considerations  section at all

            
 

            
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike =
Jones

            
Sent: Wednesday, February 24, 2016 9:54 =
AM

            
To: Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
The point of the WGLC is to finish =
standardizing the core discovery functionality that=E2=80=99s already =
widely deployed.

            
 

            
None of Nat or John or I are suggesting that =
additional related functionality won=E2=80=99t be created.  I=E2=80=99=
m sure it will be.  Some applications will use WebFinger to locate =
the discovery metadata.  Some will possibly use link headers.  =
Some will possibly use application-specific .well-known values.  =
I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even =
thought about.  All of these depend upon having a discovery =
metadata document format and none of them change it =E2=80=93 other than =
possibly to register additional discovery metadata values.

            
 

            
So by all means, the working group should =
continue discussing inventing possible new related mechanisms that make =
sense in some contexts.  At the same time, we can finish =
standardizing the already widely deployed core functionality that all of =
these mechanisms will need.

            
 

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

            
 

            
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt =
(IDM)

            
Sent: Wednesday, February 24, 2016 8:39 =
AM

            
To: Nat Sakimura <sakimura@gmail.com>

            
Cc: <oauth@ietf.org> <oauth@ietf.org>

            
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery =
Location

            
 

            
I am suggesting that part of the discovery =
solution has to be the client indicating what resource endpoint it wants =
the oauth configuration data for. 

            
 

            
So if res.example.evil.com is not a valid resource endpoint for =
as.example.com the =
authz discovery should fail in some way (eg return nothing). 

            
 

            
There may be better ways to do this. Eg =
combine discovery. Or change the order of discovery. 

            
 

            
One of OAuth's strength's and weaknesses is =
that the target of authorization (the resource) is never specified. It =
is often bound up in the client registration and an often implied 1:1 =
relationship between resource and as. Given that in discovery phase =
registration has not yet occurred it seems important that the client =
know it has a valid combination of endpoints etc. 

            
 

            
This is why I was disappointed about wglc on =
discovery. We had a starting point for group adoption but we haven't =
really defined the full requirements IMO. 

            
 

            
I am on vacation or I would put some thought =
into some draft changes or a new draft. I apologize I can't do it now. =


            
 

            
Phil

            
 

            
On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:

            
 

            
Hi Phil, 

            
 

            
Are you suggesting that the AS metadata =
should include the RS URIs? Currently, it does not, but it can be done, =
I guess. 

            
 

            
The way oauth-meta works is that 

            
 

            
1. RS tells the client where the AS is. 

            
2. AS tells the client which RS endpoints =
the token can be used. 

            
 

            
Even if there is a bad AS with a valid certs =
that proxies to the good RS, the client will not send the token there as =
the authz server will say that is not the place the client may want to =
send the token to. 

            
 

            
Nat

            
 

            
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hunt@oracle.com>:

            
Nat,

            
 

            
I=E2=80=99m not sure that having the =
resource server tell the client where its authorization server is secure =
by itself. The relationship between the Authorization Server and the =
Resource server need to be bound together in one of the discovery =
endpoints (the resource and/or the oauth service discovery).

            
 

            
If a client discovers a fake resource server =
that is proxying for a real resource server the current discovery spec =
will not lead the client to understand it has the wrong resource server. =
Rather the fake resource service will just have a fake discovery =
service. The hacker can now intercept resource payload as well as tokens =
because they were able to convince the client to use the legit =
authorization service but use the token against the hackers proxy.

            
 

            
The OAuth Discovery service needs to confirm =
to the client that the server is able to issue tokens for a stated =
resource endpoint.

            
 

            
This not only works in normal OAuth but =
should add security even to UMA situations.

            
 

            
Phil

            
 

            
@independentid

            
www.independentid.com

            
phil.hunt@oracle.com

            
 

            
 

            
 

            
 

            
 

            
On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> wrote:

            
 

            
 

            
Hi Thomas, 

            
 

            
inline: 

            
 

            
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com>:

            
Couldn't the document only describe the =
metadata?

            
I quite like the idea of =
draft-sakimura-oauth-meta if you really want to do discovery, and leave =
it open to implementers / to other specs to define a .well-known URL for =
"auto-configuration".

            
The metadata described here would then =
either be used as-is, at any URL, returned as draft-sakimura-oauth-meta =
metadata at the RS; or as a basis for other metadata specs (like OpenID =
Connect). 

            
With draft-sakimura-oauth-meta's "duri" and =
the "scope" attribute of WWW-Authenticate response header, you have =
everything you need to proceed 

            
 

            
Yup. That's one of the requirements to be =
RESTful, is it not?  

            
 

            
In OAuth's case, the resource and the =
authorization server are usually tightly coupled. (Otherwise, you need =
another specs like UMA.) 

            
So, the resource server should be able to =
tell either the location of the authz endpoint. In some trusted =
environment, the resource may as well return the location of the authz =
server configuration data. In these cases, you do not have to decide on =
what .well-known uri as you say. This frees up developers from =
configuration file location collisions etc. We should strive not to =
pollute the uri space as much as possible. 

            
 

            
(well, except if there are several ASs each =
with different scopes; sounds like an edge-case to me though; maybe =
RFC6750 should instead be updated with such a parameter such that an RS =
could return several WWW-Authenticate: Bearer, each with its own "scope" =
and "duri" value?)

            
 

            
Yeah, I guess it is an edge case. I would =
rather like to see these authz servers to develop a trust framework =
under which they can agree on a single set of common scope parameter =
values. 

            
 

            
Cheers, 

            
 

            
Nat

            
 

            
 

            
 

            
On Fri, Feb 19, 2016 at 10:59 PM Justin =
Richer <jricher@mit.edu> wrote:

            
The newly-trimmed OAuth Discovery document =
is helpful and moving in the right direction. It does, however, still =
have too many vestiges of its OpenID Connect origins. One issue in =
particular still really bothers me: the use of =
=E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery =
portion. Is this an OAuth discovery document, or an OpenID Connect one? =
There is absolutely no compelling reason to tie the URL to the OIDC =
discovery mechanism.

            
 

            
I propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery document.

            
 

            
 =E2=80=94 Justin

            
_______________________________________________

            
OAuth mailing list
=

            
OAuth@ietf.org

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

            
_______________________________________________

            
OAuth mailing list
=

            
OAuth@ietf.org

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

            
_______________________________________________

            
OAuth mailing list
=

            
OAuth@ietf.org

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

            
 

            
_______________________________________________

            
OAuth mailing list
=

            
OAuth@ietf.org

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

          

          
 


            

            

            

          
_______________________________________________

          
OAuth mailing list

          
OAuth@ietf.org

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

        


          

          

        
-- 

        
Vladimir Dzhuvinov :: vladimir@connect2id.com

      

      

      

      

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


    

    

  


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

=

--Apple-Mail=_5206E4BE-D692-465F-B1E6-6FC5C5B32109--


From nobody Fri Feb 26 18:47:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84081B334C for ; Fri, 26 Feb 2016 18:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs5z7xiOMHS5 for ; Fri, 26 Feb 2016 18:47:54 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11FA1B3340 for ; Fri, 26 Feb 2016 18:47:53 -0800 (PST)
X-AuditID: 1209190c-283ff7000000185e-75-56d10e58a47a
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 17.F6.06238.85E01D65; Fri, 26 Feb 2016 21:47:52 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u1R2lpOD025205; Fri, 26 Feb 2016 21:47:52 -0500
Received: from [172.27.5.37] (75-104-65-21.mobility.exede.net [75.104.65.21]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1R2lfAR028073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Feb 2016 21:47:49 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_B992E04C-D34B-4E4C-884D-BB75837BCD7A"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <008201d170a4$f5216910$df643b30$@gmail.com>
Date: Fri, 26 Feb 2016 21:47:40 -0500
Message-Id: <69709F83-8D24-44DE-9A3B-D3BF8F70C201@mit.edu>
References: <008201d170a4$f5216910$df643b30$@gmail.com>
To: Brock Allen 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixG6nrhvBdzHMYONnaYsZP46yW5x8+4rN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4eeweW8FHrYr1Dy+xNDB2qXYxcnJICJhI 7F7+lrGLkYtDSKCNSeLFim1MEM5GRokJr3+xQTinmCSOftzCDtLCLJAg8XbHcVYQm1dAT+LV rctANgeHsICxxLSPqSBhNgFVielrWphAbE4BC4lDr9uZQWwWoPiZfZfZQMqZBdQl5q6MgJhi JbHtwkMWEFtIwFzi1oKtbCC2iICaxMLp85khDpWV2P37EdMERv5ZSI6YheQIiLi2xLKFr5kh bE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyMo rDkleXYwnnnjdYhRgINRiYc3Y82FMCHWxLLiytxDjJIcTEqivBkfgUJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeEOWAeV4UxIrq1KL8mFS0hwsSuK8hftPhwkJpCeWpGanphakFsFkZTg4lCR4 BXkvhgkJFqWmp1akZeaUIKSZODhBhvMADV/GA1TDW1yQmFucmQ6RP8VozPHj4L21TBxXjgJJ IZa8/LxUKXHetyClAiClGaV5cNNAqck7w1H0FaM40HPCvIEgS3mAaQ1u3iugVUxAq2ZuOAey qiQRISXVwHjW9sGz5lUM7NdfhJ3w0WZesmVpp80Wdltm/nWdDd5bJ238x584ZfppxU0PUj0X 99hem7PuewVHcYxPuPtW/Tfyp0KypRvULm1JKeL337d7atWWU/J7vn9aOdmdmXttypI5mrNa fqw5fejb6lWzDP7PDgh/f12hqfTvQs7S1y8/fOy7cCWs/au/EktxRqKhFnNRcSIAjuOkWigD AAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP signing spec and nonce
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 02:47:56 -0000

--Apple-Mail=_B992E04C-D34B-4E4C-884D-BB75837BCD7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99d be glad to add in a nonce if there=E2=80=99s a compelling =
reason for it, such as closing a security attack vector.

What=E2=80=99s the proposed purpose of the nonce? Is it just to add =
randomness to the signing base? Or is it to prevent replay at the RS? If =
the former, the timestamp should add enough of that and it can be =
verified to be within a reasonable window by the RS by comparing it with =
the time the request was made. If the latter, the RS is going to have to =
track previously used nonces for some amount of time.=20

There was a small discussion of just signing an outgoing =E2=80=9CDate:=E2=
=80=9D header instead of the separate timestamp, but the timestamp =
seemed to be more robust. I forget the full reasoning though.

 =E2=80=94 Justin

> On Feb 26, 2016, at 9:49 AM, Brock Allen  wrote:
>=20
> Question about the HTTP signing spec =E2=80=93 why is there no nonce =
(and just a timestamp)?
> =20
> TIA
> =20
> -Brock
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_B992E04C-D34B-4E4C-884D-BB75837BCD7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I=E2=80=99d be glad to add in a nonce if =
there=E2=80=99s a compelling reason for it, such as closing a security =
attack vector.

What=E2=80=99s =
the proposed purpose of the nonce? Is it just to add randomness to the =
signing base? Or is it to prevent replay at the RS? If the former, the =
timestamp should add enough of that and it can be verified to be within =
a reasonable window by the RS by comparing it with the time the request =
was made. If the latter, the RS is going to have to track previously =
used nonces for some amount of time. 

There was a small discussion of just =
signing an outgoing =E2=80=9CDate:=E2=80=9D header instead of the =
separate timestamp, but the timestamp seemed to be more robust. I forget =
the full reasoning though.

 =E2=80=94 Justin

On Feb 26, 2016, at 9:49 AM, Brock Allen <brockallen@gmail.com> wrote:



Question about the HTTP signing spec =E2=80=93 why is there =
no nonce (and just a timestamp)?
 
TIA
 
-Brock
 
_________________________________=
______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_B992E04C-D34B-4E4C-884D-BB75837BCD7A--


From nobody Fri Feb 26 23:06:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D8C1B3693 for ; Fri, 26 Feb 2016 23:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVPZxWwIXXMm for ; Fri, 26 Feb 2016 23:06:38 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61E61B361B for ; Fri, 26 Feb 2016 23:06:37 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id p65so11066476wmp.1 for ; Fri, 26 Feb 2016 23:06:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=gdDsjHXa/KK/DAQNSCLyGRhfvjPShunveIl7jW3c9ak=; b=kp05ILhFqYR1buIX9ycGl82LmiDh1998tzZ+powuHMdiSph0gEdOwwMnNwFaSz0bxA +LTkORMJl3vF/9W1e9lSi858bCvDdlZJGkUbeGOz49Dazft9fJgesuz3kA3nbC4nn2b3 RaMtEzMd92u9cAn1/La0gCyQXr5f4tnLuuf2ZXFn7pWZgUuvaXaIJ/zB0imO5j7NXOaP 2dTB90wURg/NQi7VD79keXByTWU7Z3Uiq4q0eFxs5B9QNBKcu1zkk+jTPTgbesIer9ha PDPIcYV/9XZHIfZ0+kLfdpbAmU/eb71YTSBUch5Lc9igRvqlHuRcQyoJulbZNniwlbAk siuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=gdDsjHXa/KK/DAQNSCLyGRhfvjPShunveIl7jW3c9ak=; b=WvP5wskaQa1eY0SShZiqQo9f7Gdpy2BxFhliL6bumcSjPN6g0Nrrdplvt77ApSjGGL zxMnBwEIpXgXGj3XxsHvSG6Ia1zLqu3pGetxTbgw9ssyJU1VEj4tSBayrlMmfkqLFasp XU9rICzUCKNSrdaLz0eimS+SqokPsy9MIazFvUMROxaQBaVjwjI1FzQrgoezYZBdxmxe GFQtjsu+3eqcu3i5MfQ1YBEe2flnW8c7W0B3bBPQNirwEBqJg3hMoYeVL9HzMlKjR+B5 IPe2VqNPDgiApAS7y8UogCk8j4Kw4PSMrXt7PMt2ClsfNeszGHslo2n72lk5HVIeroA2 o0SQ==
X-Gm-Message-State: AD7BkJLfMVIgkntTjPHpBEorX/d4EEnrtFm6JcjCafA6YEbmaaYXbLS+TIGgbNn83V7lZw==
X-Received: by 10.28.73.66 with SMTP id w63mr1694811wma.53.1456556796331; Fri, 26 Feb 2016 23:06:36 -0800 (PST)
Received: from dombp.fritz.box (p5087A4AF.dip0.t-ipconnect.de. [80.135.164.175]) by smtp.gmail.com with ESMTPSA id xx3sm15445379wjc.32.2016.02.26.23.06.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 23:06:34 -0800 (PST)
Date: Sat, 27 Feb 2016 08:06:33 +0100
From: Dominick Baier 
To: Justin Richer , Brock Allen 
Message-ID: 
In-Reply-To: <69709F83-8D24-44DE-9A3B-D3BF8F70C201@mit.edu>
References: <008201d170a4$f5216910$df643b30$@gmail.com> <69709F83-8D24-44DE-9A3B-D3BF8F70C201@mit.edu>
X-Mailer: Airmail (351)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56d14afa_62750943_12e86"
Archived-At: 
Cc: "=?utf-8?Q??=" 
Subject: Re: [OAUTH-WG] HTTP signing spec and nonce
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 07:06:40 -0000

--56d14afa_62750943_12e86
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The nonce would allow to build a replay cache, the timestamp to trim that=
 cache and reject messages that are too old.

Similar protocols have a nonce for the above reasons (ws-sec msg security=
, hawk)...

=E2=80=94=C2=A0
cheers
Dominick Baier

On 27 =46ebruary 2016 at 03:48:00, Justin Richer (jricher=40mit.edu) wrot=
e:

I=E2=80=99d be glad to add in a nonce if there=E2=80=99s a compelling rea=
son for it, such as closing a security attack vector.

What=E2=80=99s the proposed purpose of the nonce=3F Is it just to add ran=
domness to the signing base=3F Or is it to prevent replay at the RS=3F If=
 the former, the timestamp should add enough of that and it can be verifi=
ed to be within a reasonable window by the RS by comparing it with the ti=
me the request was made. If the latter, the RS is going to have to track =
previously used nonces for some amount of time.=C2=A0

There was a small discussion of just signing an outgoing =E2=80=9CDate:=E2=
=80=9D header instead of the separate timestamp, but the timestamp seemed=
 to be more robust. I forget the full reasoning though.

=C2=A0=E2=80=94 Justin

On =46eb 26, 2016, at 9:49 AM, Brock Allen  wrote=
:

Question about the HTTP signing spec =E2=80=93 why is there no nonce (and=
 just a timestamp)=3F
=C2=A0
TIA
=C2=A0
-Brock
=C2=A0
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20
OAuth mailing list =20
OAuth=40ietf.org =20
https://www.ietf.org/mailman/listinfo/oauth =20

--56d14afa_62750943_12e86
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


+1
 
Best =
regards,
Don
Donald F. =
Coffin
Founder/CTO<=
/p>
 
REMI =
Networks
2335 Dunwoody Xing =
#E
Dunwoody, GA =
30338-8221
 
Phone:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (949) 636-8571
Email:=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 donald.coffin@reminetworks.com
 
From:<=
/b> =
Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: =
Friday, February 26, 2016 5:28 PM
To: Hannes Tschofenig =
<hannes.tschofenig@gmx.net>
Cc: oauth =
<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fixing the =
Authorization Server Mix-Up: Call for Adoption
 
My preference is for =
Option A. 
The mix-up attack, in all it's =
variations, relies on there being no means in OAuth for the AS to =
identify itself to the client when it returns the user's browser to the =
client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation' addresses that =
fundamental missing piece by including the 'iss' authorization response =
parameter. 
During the course of the discussions in =
Darmstadt Hans and I independently implemented and successfully interop =
tested the 'iss' and 'client_id' authorization response parameters, =
which is what was anticipated to be in the mitigation draft. Doing so =
was very simple and straightforward. And it addresses the vulnerability. =
We decided, unfortunately, to pull that functionality out of a looming a =
product release due to the churn in this WG and the perceived risk of =
changes in what would eventually become the standard solution. Of =
course, that kind of risk is always present with draft standards but =
it's been very frustrating in this case to have worked towards a simple =
solution to a known problem only to have progress get hung up in lack of =
agreement in this WG.     
I'll also say that in many/most cases the AS doesn't =
explicitly know all of the resources that tokens it issues can or will =
be used at (and there are often more than one). So the ruri/Resource URI =
parameter isn't really a workable option. 
 
 
 
On Thu, =
Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> =
wrote:
Vladimir,

yes, we could do a formal analysis =
and it would be a very good idea.
It would even go faster if a few of =
us work together on it. Anyone
interested?

This would be a =
good contribution for the workshop in July, btw.

Ciao
Hannes

On 02/23/2016 10:09 =
AM, Vladimir Dzhuvinov wrote:
> Hi Mike,
>
> You =
mention that you spent considerable time in research. I wonder =
if
> there is existing theory, in communications or information =
theory, that
> can be used to formally establish and prove (or =
disprove) the security
> of the proposed OAuth measures? Perhaps =
some work that is totally
> unrelated to identity and the web =
protocols, but could well apply here?
>
> My reasoning is =
that we have a closed system that is fairly simple, so
> formal =
analysis must be entirely possible.
>
> 1. We have 5 parties =
(client, AS, RS, user, user agent).
>
> 2. The OAuth =
protocol follows a simple and well-defined pattern of
> messages =
between the parties.
>
> 3. The points and the number of =
ways by which an adversary may break
> into OAuth must therefore =
be finite.
>
> 4. The security requirement is essentially to =
guarantee the precedence
> and authenticity of the messages from =
discovery endpoint to RS, and the
> preferred way to do that is by =
establishing a binding between the
> messages, which can be =
forward or backward binding.
>
>
> Right now the WG =
concern is whether all possible attacks have been
> recognised, =
and then taken care of. If we can have a formal model that
> can =
reliably reveal and prove that, this will be a huge =
breakthrough.
>
> Cheers,
>
> =
Vladimir
>
>
>
> On 20/02/16 12:41, Mike Jones =
wrote:
>> Suggesting that they be read is of course, the right =
long-term approach.  But as someone who spent 20+ years as a =
researcher before switching to digital identity, I was sensitive to not =
wanting to upstage their work by copying too much of their material into =
our draft before their publications were widely known.  I'll of =
course commit to working the researchers and the working group to create =
a self-contained concise description of the threats and mitigations in =
the working group document.
>>
>>      =
                    =
    Cheers,
>>          =
                    -- =
Mike
>>
>> -----Original Message-----
>> =
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]<=
br>>> Sent: Saturday, February 20, 2016 2:25 AM
>> To: =
Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com>; Phil =
Hunt (IDM) <phil.hunt@oracle.com>
>=
> Cc: oauth@ietf.org
>> Subject: =
Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for =
Adoption
>>
>> Hi Mike,
>>
>> On =
02/20/2016 10:52 AM, Mike Jones wrote:
>>> Have you read =
both of their publications?  If not, do yourself a =
favor
>>> and do.  They're actually both very readable =
and quite informative.
>> I have read both documents. In =
context of this discussion the question is whether =
we
>>
>> (a) require them to be read (in which case =
they should be a normative reference), or
>> (b) suggest them =
to be read (since they provide additional background information). In =
this case they are an informative reference.
>>
>> I =
believe believe we want (b) for the OAuth WG document. While I encourage =
everyone to read the publications I also believe that there is lots of =
material in there that goes beyond the information our audience =
typically reads (such as the text about the formal =
analysis).
>>
>> There is probably also a =
middle-ground where we either copy relevant text from the papers into =
the draft or reference specific sections that are =
"must-read".
>>
>> One other issue: I =
actually thought that the threat that is outlined in the research paper =
is sufficiently well described but the second threat, which is called =
'cut-and-paste attack', requires more work.
>> I noted this in =
my summary mail to the list, see http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5697.html
>>
>> Ciao
>> =
Hannes
>>
>>
>> =
_______________________________________________
>> OAuth =
mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=

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


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

------=_NextPart_000_039B_01D17157.E0C734A0--


From nobody Sat Feb 27 09:48:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871DB1AD0B3 for ; Sat, 27 Feb 2016 09:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyzfrVfbyhZd for ; Sat, 27 Feb 2016 09:48:24 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E371AD0AF for ; Sat, 27 Feb 2016 09:48:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HEtRfNnPNJuDcV+6M5O61SVR9wXVC7HS5fEO025bqYk=; b=iWV5imgbVPpPYr5sgE3LBBECW/Azw0+eRiU3NVu5p0sXdWIJrAA+f5E7Zu8CwGXhqt6Z4m9sc07pu83uUOeEU0uDaG9V6W8QSENhKkfcJ6fSdLmrmcaXD4Qc8hfJIcopZdUQ7yCdkS9Zd5KwY3NAj3M1S+dGtjWKjm7OaGLwlJg=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 27 Feb 2016 17:48:21 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Sat, 27 Feb 2016 17:48:21 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKwgAAD14CAABMcsIAACLCAgAAAzOCAAAh3AIAAj3QAgACntWCAAt4rAIAAMjbQ
Date: Sat, 27 Feb 2016 17:48:21 +0000
Message-ID: 
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: 0745f1a7-eb9c-47dc-5054-08d33f9e2f02
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:PYHjOJcZCcPROIEZyaA/wj9xExSstUvUZSqxkTBsWLKvjCRzSXdFKnHw+G+3Abk/FIkTyVKCG6Sn58oLSkfjVYSHZiDuR7Auj34k1EY0SfWnUc97yfd5PbnwdD1jxx6Ph3Vt2ui4+n2y+u6Ile/EOA==; 24:J3tDP3E5GHTu4//1r5b/wbeiW5MiWsYfhLunGzmmT3jA4fOFF6E/Pvz+z9kzRvCOeLot9eQa8LBDvIWPhG0MLyWJN3pZh5t+ms6MeXd0coI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(169139582196971);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(479174004)(24454002)(51914003)(19580405001)(19580395003)(93886004)(74316001)(3846002)(3660700001)(1220700001)(33656002)(586003)(66066001)(19625215002)(3280700002)(5008740100001)(2900100001)(15975445007)(2906002)(2950100001)(16601075003)(122556002)(3900700001)(77096005)(19609705001)(11100500001)(10400500002)(450100001)(1730700002)(1096002)(6116002)(107886002)(5002640100001)(5005710100001)(40100003)(87936001)(19300405004)(92566002)(76176999)(76576001)(2351001)(99286002)(106116001)(189998001)(110136002)(54356999)(50986999)(5001960100002)(102836003)(10290500002)(790700001)(5003600100002)(5004730100002)(10090500001)(86362001)(19617315012)(2501003)(15395725005)(16236675004)(579004)(336705003)(184035003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442FFEDAA5B8ED7A8FAAD9BF5B80BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2016 17:48:21.4185 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 17:48:33 -0000

--_000_BY2PR03MB442FFEDAA5B8ED7A8FAAD9BF5B80BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXTigJlzIGNsZWFyIHRoYXQgcGVvcGxlIHdhbnQgdXMgdG8gbW92ZSB0byB0aGUgbmFtZSDigJxP
QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ54oCdLiAgVGhlIGVkaXRvcnMg
d2lsbCBwbGFuIHRvIG1ha2UgdGhhdCBjaGFuZ2UgaW4gdGhlIGRyYWZ0IGFkZHJlc3NpbmcgV29y
a2luZyBHcm91cCBMYXN0IENhbGwgY29tbWVudHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWxsLA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN
Cg0KRnJvbTogU2FtdWVsIEVyZHRtYW4gW21haWx0bzpzYW11ZWxAZXJkdG1hbi5zZV0NClNlbnQ6
IFNhdHVyZGF5LCBGZWJydWFyeSAyNywgMjAxNiA2OjQ3IEFNDQpUbzogTWlrZSBKb25lcyA8TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGlt
aXJAY29ubmVjdDJpZC5jb20+OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1X
R10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQorMSBmb3Ig4oCcT0F1dGggMi4wIEF1
dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeeKAnQ0KDQovL1NhbXVlbA0KDQpPbiBUaHUsIEZl
YiAyNSwgMjAxNiBhdCA4OjEwIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhhbmtz
IGZvciB5b3VyIHRob3VnaHRzLCBWbGFkaW1pci4gIEnigJltIGluY3JlYXNpbmdseSBpbmNsaW5l
ZCB0byBhY2NlcHQgeW91ciBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgdGl0bGUgZnJvbSDigJxP
QXV0aCAyLjAgRGlzY292ZXJ54oCdIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZl
ciBEaXNjb3ZlcnnigJ0uICBXaGlsZSB0aGUgYWJzdHJhY3QgYWxyZWFkeSBtYWtlcyBpdCBjbGVh
ciB0aGF0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgQVMgZGlzY292ZXJ5LCBkb2luZyBz
byBpbiB0aGUgdGl0bGUgc2VlbXMgbGlrZSBpdCBjb3VsZCBoZWxwIGNsYXJpZnkgdGhpbmdzLCBn
aXZlbiB0aGF0IGEgbG90IG9mIHRoZSBkaXNjdXNzaW9uIHNlZW1zIHRvIGJlIGFib3V0IHJlc291
cmNlIGRpc2NvdmVyeSwgd2hpY2ggaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4NCg0K
SeKAmW0gbm90IHNheWluZyB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBpc27igJl0IGltcG9ydGFu
dCDigJMgaXQgaXMg4oCTIGJ1dCB1bmxpa2UgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlzY292ZXJ5
LCB3aGVyZSB0aGVyZeKAmXMgbG90cyBvZiBleGlzdGluZyBwcmFjdGljZSwgaW5jbHVkaW5nIHVz
aW5nIHRoZSBleGlzdGluZyBkYXRhIGZvcm1hdCBmb3IgZGVzY3JpYmluZyBPQXV0aCBpbXBsZW1l
bnRhdGlvbnMgdGhhdCBhcmVu4oCZdCBiZWluZyB1c2VkIHdpdGggT3BlbklEIENvbm5lY3QsIHRo
ZXJl4oCZcyBubyBleGlzdGluZyBwcmFjdGljZSB0byBzdGFuZGFyZGl6ZSBmb3IgcmVzb3VyY2Ug
ZGlzY292ZXJ5LiAgVGhlIHRpbWUgdG8gY3JlYXRlIGEgc3RhbmRhcmQgZm9yIHRoYXQgc2VlbXMg
dG8gYmUgYWZ0ZXIgZXhpc3RpbmcgcHJhY3RpY2UgaGFzIGVtZXJnZWQuICBJdCAqbWlnaHQqIG9y
IG1pZ2h0IG5vdCB1c2UgbmV3IG1ldGFkYXRhIHZhbHVlcyBpbiB0aGUgQVMgZGlzY292ZXJ5IGRv
Y3VtZW50LCBidXQgdGhhdOKAmXMgc3RpbGwgdG8gYmUgZGV0ZXJtaW5lZC4gIFRoZSBvbmUgcmVh
c29uIHRvIGxlYXZlIHRoZSB0aXRsZSBhcy1pcyBpcyB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBt
aWdodCBlbmQgdXAgaW52b2x2aW5nIGV4dGVuc2lvbnMgdG8gdGhpcyBtZXRhZGF0YSBmb3JtYXQg
aW4gc29tZSBjYXNlcy4NCg0KSSB0aGluayBhbiBhbmFsb2d5IHRvIHRoZSBjb3JlIE9BdXRoIGRv
Y3VtZW50cyBSRkMgNjc0OSBhbmQgUkZDIDY3NTAgYXBwbGllcy4gIDY3NDkgaXMgYWJvdXQgdGhl
IEFTLiAgNjc1MCBpcyBhYm91dCB0aGUgUlMuICBUaGUgZGlzY292ZXJ5IGRvY3VtZW50IGlzIGFi
b3V0IHRoZSBBUy4gIFdlIGRvbuKAmXQgeWV0IGhhdmUgYSBzcGVjaWZpY2F0aW9uIG9yIGV4aXN0
aW5nIHByYWN0aWNlIGZvciBSUyBkaXNjb3ZlcnksIHdoaWNoIHdvdWxkIGJlIHRoZSA2NzUwIGFu
YWxvZ3kuDQoNCkluIHN1bW1hcnksIHdoaWNoIHRpdGxlIGRvIHBlb3BsZSBwcmVmZXI/DQoNCuKA
oiAgICAgICDigJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdDQoNCuKAoiAgICAgICDigJxPQXV0aCAy
LjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ54oCdDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206
IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBWbGFkaW1pciBEemh1dmlub3YNClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAyNSwgMjAxNiAxMjo1OSBBTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERp
c2NvdmVyeSBMb2NhdGlvbg0KDQpJbiBPSURDIHRoZSBkaXNjb3ZlcnkgZG9jIGlzIG9mIGdyZWF0
IHV0aWxpdHkgdG8gZGV2ZWxvcGVycyBhbmQgaW50ZWdyYXRvcnMuIERldmVsb3BlcnMgYWxzbyB0
ZW5kIHRvIGZpbmQgaXQgYSBtb3JlIGFjY3VyYXRlIGFuZCBjb21wbGV0ZSBkZXNjcmlwdGlvbiBv
ZiBob3cgdG8gc2V0IHVwIGEgY2xpZW50IGZvciBhIHBhcnRpY3VsYXIgZGVwbG95bWVudCwgY29t
cGFyZWQgdG8gdHJhZGl0aW9uYWwgb25saW5lIGRvY3MsIHdoaWNoIG1heSBiZSBub3QgYmUgdXAg
dG8gZGF0ZSwgb3IgZXZlbiBtaXNzaW5nLiBWZXJ5IG11Y2ggbGlrZSBhdXRvLWdlbmVyYXRlZCBT
d2FnZ2VyIGFuZCBKYXZhRG9jcy4NCg0KSGVyZSBhcmUgc29tZSBleGFtcGxlIE9JREMgZGlzY292
ZXJ5IGRvY3M6DQoNCmh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9vcGVu
aWQtY29uZmlndXJhdGlvbg0KDQpodHRwczovL3d3dy5wYXlwYWxvYmplY3RzLmNvbS8ud2VsbC1r
bm93bi9vcGVuaWQtY29uZmlndXJhdGlvbg0KDQpodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGlu
ZS5jb20vZmFicmlrYW1iMmMub25taWNyb3NvZnQuY29tL3YyLjAvLndlbGwta25vd24vb3Blbmlk
LWNvbmZpZ3VyYXRpb24NCg0KDQpXaXRoIHRoaXMgZGlzY292ZXJ5IGRvY3VtZW50IGluIHBsYWNl
IHNldHVwIG9mIGlkZW50aXR5IGZlZGVyYXRpb24gY2FuIHRoZW4gYmUgZWFzaWx5IHNjcmlwdGVk
LiBGb3IgZXhhbXBsZToNCg0KaHR0cDovL2RvY3MuYXdzLmFtYXpvbi5jb20vSUFNL2xhdGVzdC9V
c2VyR3VpZGUvaWRfcm9sZXNfcHJvdmlkZXJzX2NyZWF0ZV9vaWRjX3ZlcmlmeS10aHVtYnByaW50
Lmh0bWwNCg0KDQpOb3csIGRvZXMgdGhhdCBkaWN0YXRlIGFueSBwYXJ0aWN1bGFyIGFwcCBhcmNo
aXRlY3R1cmU/IE15IHJlYWRpbmcgb2YgdGhlIHNwZWMgaXMgdGhhdCBpdCBkb2Vzbid0LCBhbmQg
aXQgc2hvdWxkbid0IGVpdGhlci4gQnkgc3RheWluZyBuZXV0cmFsIG9uIHRoZSB0b3BpY3Mgb2Yg
UlMgZGlzY292ZXJ5IGFuZCByZWdpc3RlcmluZyBSUHMgd2l0aCBSU3MuIEFuZCBob3cgb25lIGFy
cml2ZXMgYXQgdGhlICIud2VsbC1rbm93bi8uLi4iLiBJJ20gbm90IGV2ZW4gc3VyZSB0aGF0IHJl
c291cmNlIGRpc2NvdmVyeSBzaG91bGQgYmUgYSB0b3BpYyBvZiB0aGlzIFdHLiBQZXJoYXBzIHRv
IHRoaXMgZW5kLCBhbmQgdG8gcHJldmVudCBjb25mdXNpb24gdGhhdCB0aGUgc3BlYyBpcyB0cnlp
bmcgdG8gZG8gc29tZXRoaW5nIG1vcmUsIGEgbW9yZSBzcGVjaWZpYyB0aXRsZSB3b3VsZCBzdWl0
IGl0IGJldHRlci4gRS5nLiAiQVMgRGlzY292ZXJ5Ii4NCg0KQ2hlZXJzLA0KDQpWbGFkaW1pcg0K
DQoNCk9uIDI1LzAyLzE2IDAyOjI1LCBQaGlsIEh1bnQgKElETSkgd3JvdGU6DQoNCkFuZCBzbyBk
b2VzIG9yYWNsZSBhbmQgc28gZG9lcyBnb29nbGUuIEVhY2ggZGlmZmVyZW50Lg0KDQoNCg0KU28g
aG93IGNhbiBhbiBhcHAgZGljdGF0ZSBpdCB0aGVuIHVubGVzcyB3ZSBhbGwgZ28gdG8gYSBjb21t
b24gYXJjaGl0ZWN0dXJlPw0KDQoNCg0KUGhpbA0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAx
NjowNCwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KDQoNCkF6dXJlIGRlZmluZXMgd2F5
cyBmb3IgcmVzb3VyY2Ugc2VydmVycyB0byBiZSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIGNs
aWVudCBhbmQgZm9yIGNsaWVudHMgdG8gZHluYW1pY2FsbHkgcmVxdWVzdCBhbiBhY2Nlc3MgdG9r
ZW4gZm9yIHVzZSBhdCBhIHBhcnRpY3VsYXIgcmVzb3VyY2Ugc2VydmVyLiAgWW91IGNhbiBjYWxs
IHRoYXQgY3VzdG9tIGFyY2hpdGVjdHVyZSBpZiB5b3Ugd2FudC4gIEl04oCZcyB3ZWxsLWRlZmlu
ZWQgYnV0IGl04oCZcyBub3QgY3VycmVudGx5IGluIHRoZSBzdGFuZGFyZHMgcmVhbG0uICBJIGtu
b3cgdGhhdCBHb29nbGUgaGFzIHN5bnRheCBmb3IgZG9pbmcgdGhlIHNhbWUsIGFzIEnigJltIHN1
cmUgZG8gYSBsb3Qgb2Ygb3RoZXIgY2xvdWQgT0F1dGggZGVwbG95bWVudHMsIHN1Y2ggYXMgT3Jh
Y2xl4oCZcy4gIEZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIHdvcmtpbmcgZ3JvdXAgdGFsa2Vk
IGFib3V0IHBvc3NpYmx5IHByb2R1Y2luZyBhIHN0YW5kYXJkIHZlcnNpb24gb2Ygc3ludGF4IGZv
ciBtYWtpbmcgdGhlc2Uga2luZHMgb2YgcmVxdWVzdHMgZHVyaW5nIG91ciBkaXNjdXNzaW9ucyBp
biBQcmFndWUgKGR1cmluZyB0aGUgVG9rZW4gRXhjaGFuZ2UgZGlzY3Vzc2lvbikgYnV0IG5vYm9k
eSBoYXMgcnVuIHdpdGggdGhpcyB5ZXQuDQoNCg0KDQpJbiB0aGlzIHNlbnNlLCB5ZXMsIEF6dXJl
IGlzIGFuIGFwcGxpY2F0aW9uIG9mIHRoZSBraW5kIHdl4oCZcmUgdGFsa2luZyBhYm91dC4gIEF6
dXJlIGFscmVhZHkgZG9lcyBkZWZpbmUgc3BlY2lmaWMgbmV3IE9BdXRoIDIuMCBkaXNjb3Zlcnkg
bWV0YWRhdGEgdmFsdWVzIHRoYXQgYXJlIHVzZWQgaW4gcHJvZHVjdGlvbi4gIEEgcmVnaXN0cnkg
anVzdCBkb2VzbuKAmXQgeWV0IGV4aXN0IGluIHdoaWNoIGl0IGNhbiByZWdpc3RlciB0aG9zZSB0
aGF0IGFyZSBvZiBnZW5lcmFsIGFwcGxpY2FiaWxpdHkuDQoNCg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K
DQoNCg0KRnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21d
DQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMzo1MiBQTQ0KDQpUbzogTWlr
ZSBKb25lcw0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoN
ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0K
DQoNCk1pa2UNCg0KDQoNClRha2UgYSBsb29rIGF0IHRoZSBhc3N1bXB0aW9ucyB5b3UgYXJlIG1h
a2luZy4NCg0KDQoNCllvdSBzZWVtIHRvIGJlIGFzc3VtaW5nIGFwcGxpY2F0aW9uIHNvZnR3YXJl
IGRpY3RhdGVzIG9hdXRoIGluZnJhc3RydWN0dXJlIGFyY2hpdGVjdHVyZSBieSBzdWdnZXN0aW5n
IHRoYXQgYXBwcyByZWdpc3RlciBpbiBpYW5hLg0KDQoNCg0KV291bGQgbXMgYXp1cmUgYWxsb3cg
Y3VzdG9tIGFyY2g/DQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDE1OjI4
LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVs
LkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQoNCg0KVGhlIFVzZXJJbmZvIEVuZHBvaW50
IHBhdGggaXNu4oCZdCBmaXhlZCBhbmQgc28gaGFzIHRvIGJlIGRpc2NvdmVyZWQuDQoNCg0KDQpJ
IGFncmVlIHRoYXQgZm9yIHNvbWUgT0F1dGggcHJvZmlsZXMsIG9uZSBvciBtb3JlIHJlc291cmNl
IHNlcnZlcnMgd2lsbCBoYXZlIHRvIGJlIGRpc2NvdmVyZWQgc3RhcnRpbmcgZnJvbSB0aGUgYXV0
aG9yaXphdGlvbiBzZXJ2ZXIuICBXb3JraW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSBhbHNvIGRlc2Ny
aWJlZCB3YW50aW5nIHRvIGRpc2NvdmVyIGF1dGhvcml6YXRpb24gc2VydmVycyBzdGFydGluZyBm
cm9tIHJlc291cmNlIHNlcnZlcnMuICBUaGVyZSBpc27igJl0IGEgc3RhbmRhcmQgcHJhY3RpY2Ug
Zm9yIGFueSBvZiB0aGlzLCB3aGljaCBpcyB3aHkgaXTigJlzIGludGVudGlvbmFsbHkgbGVmdCBv
dXQgb2YgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbi4NCg0KDQoNCk9uY2UgdGhlIElBTkEgT0F1
dGggRGlzY292ZXJ5IE1ldGFkYXRhIFJlZ2lzdHJ5IGhhcyBiZWVuIGVzdGFibGlzaGVkLCB3aGlj
aCB3aWxsIGhhcHBlbiBhZnRlciB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFw
cHJvdmVkLCBpdCB3aWxsIGJlIGVhc3kgZm9yIHN1YnNlcXVlbnQgc3BlY2lmaWNhdGlvbnMgdG8g
ZG9jdW1lbnQgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIGRpZmZlcmVudCBPQXV0aCBwcm9maWxlcyBh
bmQgcmVnaXN0ZXIgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyBzdXBwb3J0aW5nIHRoZW0uICBT
b21lIG9mIHRob3NlIHZhbHVlcyB3aWxsIGxpa2VseSBkZWZpbmUgd2F5cyB0byBkaXNjb3ZlciBy
ZXNvdXJjZSBzZXJ2ZXJzLCB3aGVuIGFwcGxpY2FibGUuDQoNCg0KDQpCdXQgZmlyc3QsIHdlIG5l
ZWQgdG8gZmluaXNoIHRoZSBleGlzdGluZyBzcGVjLCBzbyB0aGF0IHRoZSByZWdpc3RyeSBlbmFi
bGluZyB0aGVzZSBleHRlbnNpb25zIGdldHMgZXN0YWJsaXNoZWQgaW4gdGhlIGZpcnN0IHBsYWNl
Lg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCkZyb206IFBoaWwgSHVudCAoSURNKSBbbWFp
bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0
LCAyMDE2IDI6MTMgUE0NCg0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCg0KQ2M6IDxvYXV0aEBp
ZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpv
YXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2Nv
dmVyeSBMb2NhdGlvbg0KDQoNCg0KWXVwLiBBbmQgYmVjYXVzZSB0aGVyZSBtYW55IHJlbGF0aW9u
cyB0aGUgY2xpZW50IG1pc3QgYmUgYWJsZSB0byBkaXNjb3ZlciBpdC4gVGhlIGNsaWVudCBkb2Vz
IG5vdCBrbm93IGlmIHRoZSByZXMgc2VydmVyIGlzIGxlZ2l0Lg0KDQoNCg0KVGhlIHVzZXJpbmZv
IGlzIGFsd2F5cyBmaXggYW5kIHNvIHUgZG9udCBuZWVkIGRpc2NvdmVyeS4NCg0KDQoNClBoaWwN
Cg0KDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTQ6MDUsIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3Jv
dGU6DQoNCg0KDQpJbiBPcGVuSUQgQ29ubmVjdCwgdGhlcmXigJlzIGEgcmVzb3VyY2Ugc2VydmVy
IGNhbGxlZCB0aGUgVXNlckluZm8gRW5kcG9pbnQgdGhhdCByZXR1cm5zIGNsYWltcyBhYm91dCB0
aGUgYXV0aGVudGljYXRlZCB1c2VyIGFzIGEgSlNPTiBkYXRhIHN0cnVjdHVyZS4gIEl0cyBsb2Nh
dGlvbiBpcyBwdWJsaXNoZWQgaW4gT3BlbklEIENvbm5lY3QgZGlzY292ZXJ5IG1ldGFkYXRhIGFz
IHRoZSDigJx1c2VyaW5mb19lbmRwb2ludOKAnSBtZXRhZGF0YSB2YWx1ZSwgd2hpY2ggaXMgZGVm
aW5lZCBhdCBodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3Zlcnkt
MV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YS4NCg0KDQoNCldlIGRpZG7igJl0IGluY2x1ZGUgdGhl
IFVzZXJJbmZvIEVuZHBvaW50IGluIHRoZSBnZW5lcmljIE9BdXRoIGRpc2NvdmVyeSBzcGVjIHNp
bmNlIGluIE9BdXRoLCB0aGVyZSBhcmUgbG90cyBvZiBwb3NzaWJsZSByZWxhdGlvbnNoaXBzIGJl
dHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZCByZXNvdXJjZSBzZXJ2ZXJzIGFuZCB0aGV5
IG5lZWRu4oCZdCBiZSBvbmUtdG8tb25lLCBhcyBpcyBiZWluZyBhY3RpdmVseSBkaXNjdXNzZWQg
YnkgdGhlIHdvcmtpbmcgZ3JvdXAuICBGb3IgaW5zdGFuY2UsIHNlZSBHZW9yZ2UgRmxldGNoZXLi
gJlzIHJlY2VudCBjb250cmlidXRpb24uDQoNCg0KDQpUaGFua3MgZm9yIHRoZSBnb29kIGRpc2N1
c3Npb24sIFBoaWwuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KRnJvbTogUGhpbCBIdW50
IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQoNClNlbnQ6IFdlZG5lc2RheSwg
RmVicnVhcnkgMjQsIDIwMTYgMToyNSBQTQ0KDQpUbzogTWlrZSBKb25lcw0KDQpDYzogPG9hdXRo
QGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgt
V0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KDQoNCldoZXJlIGlzIHRoZSBwcm9m
aWxlIGVuZHBvaW50IChvaWRjJ3MgcmVzb3VyY2Ugc2VydmVyKSBwdWJsaXNoZWQ/IChGb3IgdGhl
IG5vbiBPSURDIHBlb3BsZSBvbiB0aGUgbGlzdCkuDQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIg
MjQsIDIwMTYsIGF0IDEzOjA5LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQoNCg0KVG8g
dGhlIGV4dGVudCB0aGF0IGdlbmVyaWMgT0F1dGggMi4wIG5lZWRzIHRvIHB1Ymxpc2ggc29tZSBv
ZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBPcGVuSUQgQ29ubmVjdCDigJMgd2hpY2ggaXMgYnVp
bHQgb24gZ2VuZXJpYyBPQXV0aCAyLjAg4oCTIGl0IG1ha2VzIHNlbnNlIHRvIHB1Ymxpc2ggdGhh
dCBpbmZvcm1hdGlvbiB1c2luZyBleGFjdGx5IHRoZSBzYW1lIHN5bnRheCwgc2luY2UgdGhhdCBz
eW50YXggaXMgYWxyZWFkeSBpbiB3aWRlc3ByZWFkIHVzZS4gIFRoYXQgd2hhdCB0aGlzIGRyYWZ0
IGFjY29tcGxpc2hlcy4NCg0KDQoNClRoZXJl4oCZcyBub3RoaW5nIENvbm5lY3Qtc3BlY2lmaWMg
YWJvdXQgdXNpbmcgbWV0YWRhdGEgcmVzcG9uc2UgdmFsdWVzIGxpa2U6DQoNCg0KDQogICAiYXV0
aG9yaXphdGlvbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9hdXRob3Jp
emUiPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGhvcml6ZT4sDQoNCiAgICJ0b2tlbl9l
bmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiI8aHR0cHM6Ly9zZXJ2
ZXIuZXhhbXBsZS5jb20vdG9rZW4+LA0KDQogICAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2Rz
X3N1cHBvcnRlZCI6IFsiY2xpZW50X3NlY3JldF9iYXNpYyIsICJwcml2YXRlX2tleV9qd3QiXSwN
Cg0KICAgInJlZ2lzdHJhdGlvbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNv
bS9yZWdpc3RlciI8aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0ZXI+LA0KDQogICAi
cmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkIjogIFsiY29kZSIsICJ0b2tlbiJdLA0KDQogICAic2Vy
dmljZV9kb2N1bWVudGF0aW9uIjogImh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vc2VydmljZV9k
b2N1bWVudGF0aW9uLmh0bWwiPGh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vc2VydmljZV9kb2N1
bWVudGF0aW9uLmh0bWw+LA0KDQoNCg0KSXMgdGhlcmUgYSByZWFzb24gdGhhdCB5b3Ugd291bGQg
bGlrZSB0aGUgc3ludGF4IGZvciBhbnkgb2YgdGhlc2Ugb3IgdGhlIG90aGVyIGdlbmVyYWxseSBh
cHBsaWNhYmxlIE9BdXRoIDIuMCBtZXRhZGF0YSB2YWx1ZXMgdG8gYmUgZGlmZmVyZW50PyAgSSBk
b27igJl0IHNlZSBhbnkgZ29vZCByZWFzb24gZm9yIHVubmVjZXNzYXJ5IGRpZmZlcmVuY2VzIHRv
IGJlIGludHJvZHVjZWQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KRnJvbTogUGhpbCBI
dW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQoNClNlbnQ6IFdlZG5lc2Rh
eSwgRmVicnVhcnkgMjQsIDIwMTYgMTI6NDUgUE0NCg0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9u
eW5hZEBtaWNyb3NvZnQuY29tPjxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KDQpDYzog
TWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tPjsgPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5v
cmc+IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpNaWtlDQoN
Cg0KDQpQdWJsaXNoaW5nIG9uIGRldiBwYWdlcyBkb2VzIG5vdCB3b3JrIGZvciBzb2Z0d2FyZSAo
ZXNwIG9wZW4gc291cmNlKSB0aGF0IGlzIGRlcGxveWVkIGJvdGggaW4gZW50ZXJwcmlzZXMgYW5k
IG9uIFBhYVMgY2xvdWQgcHJvdmlkZXJzLg0KDQoNCg0KVGhlIGN1cnJlbnQgZHJhZnQgaXMgbWF5
IGNvZGlmeSBjdXJyZW50IE9JREMgcHJhY3RpY2UgYW5kIGJlIGFwcHJvcHJpYXRlIGZvciBvaWRj
IGJ1dCBpdCBpcyBub3QgcmVhZHkgZm9yIGdlbmVyaWMgb2F1dGguIFRoZXJlIGlzIG5vIGdlbmVy
aWMgb2F1dGggZXhwZXJpZW5jZSBhdCB0aGlzIHRpbWUuDQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBG
ZWIgMjQsIDIwMTYsIGF0IDEwOjI1LCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0
LmNvbT48bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCg0KDQpTdXJlIHRo
ZXJlIGlzLCBpdCBpcyBhcyB5b3UgaGF2ZSBub3cgbWFkZSBpdCBmYXIgZWFzaWVyIGFuZCB0aGUg
c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9lcyBub3QgZXZlbiBhZGRyZXNzIHRoaXMNCg0KDQoN
CkZyb206IE1pa2UgSm9uZXMNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAx
MDoyMiBBTQ0KDQpUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+PG1h
aWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+DQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
DQoNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24N
Cg0KDQoNCkFzIHdl4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZmZWN0
aXZlIHNlY3VyaXR5IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gYmVp
bmcgcHVibGlzaGVkIGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBhbmQg
aXQgYmVpbmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiAg4oCcU2VjdXJpdHkgYnkg
b2JzY3VyaXR54oCdIGFkZHMgbm8gcmVhbCBzZWN1cml0eSBhdCBhbGwuDQoNCg0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr
ZQ0KDQoNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh
cnkgMjQsIDIwMTYgMTA6MDEgQU0NCg0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IFBoaWwgSHVu
dCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bT47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11cmFAZ21h
aWwuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxv
YXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW09B
VVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpUaGUgcG9pbnQgb2Yg
dGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1
bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuDQoNCg0KDQpUaGF0
IG1heSBiZSB3aWRlbHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQg
Zm9yIE9BdXRoLiBUaGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292
ZXJ5IGZvciBlbmRwb2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90IGJlIGluIGFuIE9BdXRoIHN0
YW5kYXJkIHNpbmNlIGl04oCZcyByZWFsbHkgbm90IGRlYWx0IHdpdGguIE5vdyB0aGF0IGFsbCB0
aGlzIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpdCBtYWtlcyBwb2tpbmcgYXJvdW5kIHRoZSBl
bmRwb2ludCBtb3JlIGZvY3VzZWQgZm9yIHBlb3BsZSB0aGF0IHdhbnQgdG8gZGlzcnVwdCB5b3Vy
IGVuZHBvaW50cywgdGhhdCBpcyByZWFsbHkgbm90IGFkZHJlc3NlZCBpbiB0aGUgc2VjdXJpdHkg
Y29uc2lkZXJhdGlvbnMgIHNlY3Rpb24gYXQgYWxsDQoNCg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQoNClNlbnQ6
IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTQ0KDQpUbzogUGhpbCBIdW50IChJ
RE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjsg
TmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20+DQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRo
QGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbT0FVVEgt
V0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KDQoNClRoZSBwb2ludCBvZiB0aGUg
V0dMQyBpcyB0byBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rp
b25hbGl0eSB0aGF04oCZcyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC4NCg0KDQoNCk5vbmUgb2Yg
TmF0IG9yIEpvaG4gb3IgSSBhcmUgc3VnZ2VzdGluZyB0aGF0IGFkZGl0aW9uYWwgcmVsYXRlZCBm
dW5jdGlvbmFsaXR5IHdvbuKAmXQgYmUgY3JlYXRlZC4gIEnigJltIHN1cmUgaXQgd2lsbCBiZS4g
IFNvbWUgYXBwbGljYXRpb25zIHdpbGwgdXNlIFdlYkZpbmdlciB0byBsb2NhdGUgdGhlIGRpc2Nv
dmVyeSBtZXRhZGF0YS4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJzLiAgU29t
ZSB3aWxsIHBvc3NpYmx5IHVzZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyAud2VsbC1rbm93biB2YWx1
ZXMuICBJ4oCZbSBzdXJlIHRoZXJl4oCZcyBvdGhlciB0aGluZ3MgSSBoYXZlbuKAmXQgZXZlbiB0
aG91Z2h0IGFib3V0LiAgQWxsIG9mIHRoZXNlIGRlcGVuZCB1cG9uIGhhdmluZyBhIGRpc2NvdmVy
eSBtZXRhZGF0YSBkb2N1bWVudCBmb3JtYXQgYW5kIG5vbmUgb2YgdGhlbSBjaGFuZ2UgaXQg4oCT
IG90aGVyIHRoYW4gcG9zc2libHkgdG8gcmVnaXN0ZXIgYWRkaXRpb25hbCBkaXNjb3ZlcnkgbWV0
YWRhdGEgdmFsdWVzLg0KDQoNCg0KU28gYnkgYWxsIG1lYW5zLCB0aGUgd29ya2luZyBncm91cCBz
aG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9zc2libGUgbmV3IHJlbGF0ZWQg
bWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250ZXh0cy4gIEF0IHRoZSBzYW1l
IHRpbWUsIHdlIGNhbiBmaW5pc2ggc3RhbmRhcmRpemluZyB0aGUgYWxyZWFkeSB3aWRlbHkgZGVw
bG95ZWQgY29yZSBmdW5jdGlvbmFsaXR5IHRoYXQgYWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgd2ls
bCBuZWVkLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudCAoSURNKQ0KDQpTZW50OiBX
ZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDg6MzkgQU0NCg0KVG86IE5hdCBTYWtpbXVyYSA8
c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPg0KDQpDYzogPG9h
dXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz48bWFp
bHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAg
RGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpJIGFtIHN1Z2dlc3RpbmcgdGhhdCBwYXJ0IG9mIHRo
ZSBkaXNjb3Zlcnkgc29sdXRpb24gaGFzIHRvIGJlIHRoZSBjbGllbnQgaW5kaWNhdGluZyB3aGF0
IHJlc291cmNlIGVuZHBvaW50IGl0IHdhbnRzIHRoZSBvYXV0aCBjb25maWd1cmF0aW9uIGRhdGEg
Zm9yLg0KDQoNCg0KU28gaWYgcmVzLmV4YW1wbGUuZXZpbC5jb208aHR0cDovL3Jlcy5leGFtcGxl
LmV2aWwuY29tPiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgYXMuZXhhbXBs
ZS5jb208aHR0cDovL2FzLmV4YW1wbGUuY29tPiB0aGUgYXV0aHogZGlzY292ZXJ5IHNob3VsZCBm
YWlsIGluIHNvbWUgd2F5IChlZyByZXR1cm4gbm90aGluZykuDQoNCg0KDQpUaGVyZSBtYXkgYmUg
YmV0dGVyIHdheXMgdG8gZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3ZlcnkuIE9yIGNoYW5nZSB0
aGUgb3JkZXIgb2YgZGlzY292ZXJ5Lg0KDQoNCg0KT25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBh
bmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJl
c291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBj
bGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAg
YmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5IHBoYXNlIHJl
Z2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhhdCB0
aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5kcG9pbnRzIGV0
Yy4NCg0KDQoNClRoaXMgaXMgd2h5IEkgd2FzIGRpc2FwcG9pbnRlZCBhYm91dCB3Z2xjIG9uIGRp
c2NvdmVyeS4gV2UgaGFkIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGdyb3VwIGFkb3B0aW9uIGJ1dCB3
ZSBoYXZlbid0IHJlYWxseSBkZWZpbmVkIHRoZSBmdWxsIHJlcXVpcmVtZW50cyBJTU8uDQoNCg0K
DQpJIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0IHNvbWUgdGhvdWdodCBpbnRvIHNvbWUg
ZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBhcG9sb2dpemUgSSBjYW4ndCBkbyBpdCBu
b3cuDQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEyLCBOYXQgU2Fr
aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4gd3Jv
dGU6DQoNCg0KDQpIaSBQaGlsLA0KDQoNCg0KQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhlIEFT
IG1ldGFkYXRhIHNob3VsZCBpbmNsdWRlIHRoZSBSUyBVUklzPyBDdXJyZW50bHksIGl0IGRvZXMg
bm90LCBidXQgaXQgY2FuIGJlIGRvbmUsIEkgZ3Vlc3MuDQoNCg0KDQpUaGUgd2F5IG9hdXRoLW1l
dGEgd29ya3MgaXMgdGhhdA0KDQoNCg0KMS4gUlMgdGVsbHMgdGhlIGNsaWVudCB3aGVyZSB0aGUg
QVMgaXMuDQoNCjIuIEFTIHRlbGxzIHRoZSBjbGllbnQgd2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0
b2tlbiBjYW4gYmUgdXNlZC4NCg0KDQoNCkV2ZW4gaWYgdGhlcmUgaXMgYSBiYWQgQVMgd2l0aCBh
IHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBSUywgdGhlIGNsaWVudCB3aWxs
IG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHogc2VydmVyIHdpbGwgc2F5IHRo
YXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50IHRvIHNlbmQgdGhlIHRva2Vu
IHRvLg0KDQoNCg0KTmF0DQoNCg0KDQoyMDE25bm0MuaciDI05pelKOawtCkgMjM6NTkgUGhpbCBI
dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjoN
Cg0KTmF0LA0KDQoNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNl
cnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNl
Y3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlv
biBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhl
ciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNvdXJjZSBhbmQvb3Ig
dGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KDQoNCklmIGEgY2xpZW50IGRpc2NvdmVy
cyBhIGZha2UgcmVzb3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9yIGEgcmVhbCByZXNv
dXJjZSBzZXJ2ZXIgdGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBub3QgbGVhZCB0aGUg
Y2xpZW50IHRvIHVuZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJjZSBzZXJ2ZXIuIFJh
dGhlciB0aGUgZmFrZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZlIGEgZmFrZSBkaXNj
b3Zlcnkgc2VydmljZS4gVGhlIGhhY2tlciBjYW4gbm93IGludGVyY2VwdCByZXNvdXJjZSBwYXls
b2FkIGFzIHdlbGwgYXMgdG9rZW5zIGJlY2F1c2UgdGhleSB3ZXJlIGFibGUgdG8gY29udmluY2Ug
dGhlIGNsaWVudCB0byB1c2UgdGhlIGxlZ2l0IGF1dGhvcml6YXRpb24gc2VydmljZSBidXQgdXNl
IHRoZSB0b2tlbiBhZ2FpbnN0IHRoZSBoYWNrZXJzIHByb3h5Lg0KDQoNCg0KVGhlIE9BdXRoIERp
c2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0aGF0IHRoZSBz
ZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291cmNlIGVuZHBv
aW50Lg0KDQoNCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3Vs
ZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KDQoNClBoaWwNCg0KDQoN
CkBpbmRlcGVuZGVudGlkDQoNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVw
ZW5kZW50aWQuY29tPg0KDQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAzOjU0
IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdt
YWlsLmNvbT4gd3JvdGU6DQoNCg0KDQoNCg0KSGkgVGhvbWFzLA0KDQoNCg0KaW5saW5lOg0KDQoN
Cg0KMjAxNuW5tDLmnIgyMuaXpSjmnIgpIDE4OjQ0IFRob21hcyBCcm95ZXIgPHQuYnJveWVyQGdt
YWlsLmNvbT48bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT46DQoNCkNvdWxkbid0IHRoZSBkb2N1
bWVudCBvbmx5IGRlc2NyaWJlIHRoZSBtZXRhZGF0YT8NCg0KSSBxdWl0ZSBsaWtlIHRoZSBpZGVh
IG9mIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRp
c2NvdmVyeSwgYW5kIGxlYXZlIGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3Bl
Y3MgdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJMIGZvciAiYXV0by1jb25maWd1cmF0aW9uIi4N
Cg0KVGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJlIHVzZWQg
YXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEg
bWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBtZXRhZGF0YSBzcGVj
cyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuDQoNCldpdGggZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0
YSdzICJkdXJpIiBhbmQgdGhlICJzY29wZSIgYXR0cmlidXRlIG9mIFdXVy1BdXRoZW50aWNhdGUg
cmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlvdSBuZWVkIHRvIHByb2NlZWQN
Cg0KDQoNCll1cC4gVGhhdCdzIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHRvIGJlIFJFU1RmdWws
IGlzIGl0IG5vdD8NCg0KDQoNCkluIE9BdXRoJ3MgY2FzZSwgdGhlIHJlc291cmNlIGFuZCB0aGUg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIHVzdWFsbHkgdGlnaHRseSBjb3VwbGVkLiAoT3RoZXJ3
aXNlLCB5b3UgbmVlZCBhbm90aGVyIHNwZWNzIGxpa2UgVU1BLikNCg0KU28sIHRoZSByZXNvdXJj
ZSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRo
ZSBhdXRoeiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3Vy
Y2UgbWF5IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogc2VydmVyIGNv
bmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNp
ZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZl
bG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBX
ZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBw
b3NzaWJsZS4NCg0KDQoNCih3ZWxsLCBleGNlcHQgaWYgdGhlcmUgYXJlIHNldmVyYWwgQVNzIGVh
Y2ggd2l0aCBkaWZmZXJlbnQgc2NvcGVzOyBzb3VuZHMgbGlrZSBhbiBlZGdlLWNhc2UgdG8gbWUg
dGhvdWdoOyBtYXliZSBSRkM2NzUwIHNob3VsZCBpbnN0ZWFkIGJlIHVwZGF0ZWQgd2l0aCBzdWNo
IGEgcGFyYW1ldGVyIHN1Y2ggdGhhdCBhbiBSUyBjb3VsZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0
aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBpdHMgb3duICJzY29wZSIgYW5kICJkdXJpIiB2
YWx1ZT8pDQoNCg0KDQpZZWFoLCBJIGd1ZXNzIGl0IGlzIGFuIGVkZ2UgY2FzZS4gSSB3b3VsZCBy
YXRoZXIgbGlrZSB0byBzZWUgdGhlc2UgYXV0aHogc2VydmVycyB0byBkZXZlbG9wIGEgdHJ1c3Qg
ZnJhbWV3b3JrIHVuZGVyIHdoaWNoIHRoZXkgY2FuIGFncmVlIG9uIGEgc2luZ2xlIHNldCBvZiBj
b21tb24gc2NvcGUgcGFyYW1ldGVyIHZhbHVlcy4NCg0KDQoNCkNoZWVycywNCg0KDQoNCk5hdA0K
DQoNCg0KDQoNCg0KDQpPbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAxMDo1OSBQTSBKdXN0aW4gUmlj
aGVyIDxqcmljaGVyQG1pdC5lZHU+PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KDQpU
aGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBhbmQg
bW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxsIGhh
dmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9uZSBp
c3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNlIG9mIOKA
nC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292ZXJ5IHBv
cnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBPcGVuSUQg
Q29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFzb24gdG8g
dGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlzbS4NCg0KDQoNCkkgcHJv
cG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2
ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxvY2F0aW9uLCBhbmQgc3RhdGUgdGhhdCB0
aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxlIGZyb20g4oCcLy53ZWxsLWtub3duL29w
ZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2ZXIgYWxzbyBwcm92aWRlcyBPcGVuSUQg
Q29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVyIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNl
IHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBPQXV0aCBlbmRwb2ludHMgYW5k
IGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1l
bnQuDQoNCg0KDQog4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
T0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGgg
bWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h
aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLQ0KDQpWbGFk
aW1pciBEemh1dmlub3YgOjogdmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWly
QGNvbm5lY3QyaWQuY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
DQoNCg==

--_000_BY2PR03MB442FFEDAA5B8ED7A8FAAD9BF5B80BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290
aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw
Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt
YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg
TmV3IFJvbWFuIixzZXJpZjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K
CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ
bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t
bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMi
LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+SXTigJlzIGNsZWFyIHRoYXQgcGVvcGxlIHdhbnQgdXMgdG8gbW92ZSB0byB0aGUgbmFtZQ0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPuKAnE9BdXRoIDIuMCBBdXRob3Jp
emF0aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MDIwNjAiPi4mbmJzcDsgVGhlIGVkaXRvcnMgd2lsbCBwbGFuIHRvIG1ha2UgdGhhdCBjaGFuZ2Ug
aW4gdGhlIGRyYWZ0IGFkZHJlc3NpbmcgV29ya2luZyBHcm91cCBMYXN0IENhbGwNCiBjb21tZW50
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWxs
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4gU2FtdWVsIEVyZHRtYW4gW21haWx0bzpzYW11ZWxAZXJkdG1hbi5zZV0NCjxicj4NCjxi
PlNlbnQ6PC9iPiBTYXR1cmRheSwgRmVicnVhcnkgMjcsIDIwMTYgNjo0NyBBTTxicj4NCjxiPlRv
OjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4N
CjxiPkNjOjwvYj4gVmxhZGltaXIgRHpodXZpbm92ICZsdDt2bGFkaW1pckBjb25uZWN0MmlkLmNv
bSZndDs7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd
IE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mIzQzOzEgZm9yIOKAnE9B
dXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ08L3NwYW4+PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuNXB0Ij4vL1NhbXVlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMjUsIDIwMTYgYXQgODoxMCBQTSwg
TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzIGZvciB5
b3VyIHRob3VnaHRzLCBWbGFkaW1pci4mbmJzcDsgSeKAmW0gaW5jcmVhc2luZ2x5IGluY2xpbmVk
IHRvIGFjY2VwdCB5b3VyIHN1Z2dlc3Rpb24gdG8gY2hhbmdlDQogdGhlIHRpdGxlIGZyb20g4oCc
T0F1dGggMi4wIERpc2NvdmVyeeKAnSB0byDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2
ZXIgRGlzY292ZXJ54oCdLiZuYnNwOyBXaGlsZSB0aGUgYWJzdHJhY3QgYWxyZWFkeSBtYWtlcyBp
dCBjbGVhciB0aGF0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgQVMgZGlzY292ZXJ5LCBk
b2luZyBzbyBpbiB0aGUgdGl0bGUgc2VlbXMgbGlrZSBpdCBjb3VsZCBoZWxwIGNsYXJpZnkgdGhp
bmdzLCBnaXZlbiB0aGF0IGEgbG90IG9mDQogdGhlIGRpc2N1c3Npb24gc2VlbXMgdG8gYmUgYWJv
dXQgcmVzb3VyY2UgZGlzY292ZXJ5LCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRvY3Vt
ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJlt
IG5vdCBzYXlpbmcgdGhhdCByZXNvdXJjZSBkaXNjb3ZlcnkgaXNu4oCZdCBpbXBvcnRhbnQg4oCT
IGl0IGlzIOKAkyBidXQgdW5saWtlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpc2NvdmVyeSwNCiB3
aGVyZSB0aGVyZeKAmXMgbG90cyBvZiBleGlzdGluZyBwcmFjdGljZSwgaW5jbHVkaW5nIHVzaW5n
IHRoZSBleGlzdGluZyBkYXRhIGZvcm1hdCBmb3IgZGVzY3JpYmluZyBPQXV0aCBpbXBsZW1lbnRh
dGlvbnMgdGhhdCBhcmVu4oCZdCBiZWluZyB1c2VkIHdpdGggT3BlbklEIENvbm5lY3QsIHRoZXJl
4oCZcyBubyBleGlzdGluZyBwcmFjdGljZSB0byBzdGFuZGFyZGl6ZSBmb3IgcmVzb3VyY2UgZGlz
Y292ZXJ5LiZuYnNwOyBUaGUgdGltZSB0byBjcmVhdGUgYSBzdGFuZGFyZA0KIGZvciB0aGF0IHNl
ZW1zIHRvIGJlIGFmdGVyIGV4aXN0aW5nIHByYWN0aWNlIGhhcyBlbWVyZ2VkLiZuYnNwOyBJdCAq
PGI+bWlnaHQ8L2I+KiBvciBtaWdodCBub3QgdXNlIG5ldyBtZXRhZGF0YSB2YWx1ZXMgaW4gdGhl
IEFTIGRpc2NvdmVyeSBkb2N1bWVudCwgYnV0IHRoYXTigJlzIHN0aWxsIHRvIGJlIGRldGVybWlu
ZWQuJm5ic3A7IFRoZSBvbmUgcmVhc29uIHRvIGxlYXZlIHRoZSB0aXRsZSBhcy1pcyBpcyB0aGF0
IHJlc291cmNlIGRpc2NvdmVyeSBtaWdodCBlbmQNCiB1cCBpbnZvbHZpbmcgZXh0ZW5zaW9ucyB0
byB0aGlzIG1ldGFkYXRhIGZvcm1hdCBpbiBzb21lIGNhc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkgdGhpbmsgYW4gYW5hbG9neSB0byB0aGUgY29y
ZSBPQXV0aCBkb2N1bWVudHMgUkZDIDY3NDkgYW5kIFJGQyA2NzUwIGFwcGxpZXMuJm5ic3A7IDY3
NDkgaXMgYWJvdXQgdGhlIEFTLiZuYnNwOw0KIDY3NTAgaXMgYWJvdXQgdGhlIFJTLiZuYnNwOyBU
aGUgZGlzY292ZXJ5IGRvY3VtZW50IGlzIGFib3V0IHRoZSBBUy4mbmJzcDsgV2UgZG9u4oCZdCB5
ZXQgaGF2ZSBhIHNwZWNpZmljYXRpb24gb3IgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIFJTIGRpc2Nv
dmVyeSwgd2hpY2ggd291bGQgYmUgdGhlIDY3NTAgYW5hbG9neS48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JbiBzdW1tYXJ5LCB3aGljaCB0aXRsZSBkbyBw
ZW9wbGUgcHJlZmVyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj7Ctzwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy
MDYwIj7igJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMw
MDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBE
aXNjb3ZlcnnigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGEgbmFtZT0iNzM2Nzg5Nzg0X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOjxh
IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1
dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlZsYWRpbWlyIER6
aHV2aW5vdjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgMTI6
NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JbiBP
SURDIHRoZSBkaXNjb3ZlcnkgZG9jIGlzIG9mIGdyZWF0IHV0aWxpdHkgdG8gZGV2ZWxvcGVycyBh
bmQgaW50ZWdyYXRvcnMuIERldmVsb3BlcnMgYWxzbyB0ZW5kIHRvIGZpbmQgaXQgYSBtb3JlIGFj
Y3VyYXRlIGFuZCBjb21wbGV0ZSBkZXNjcmlwdGlvbiBvZiBob3cgdG8gc2V0IHVwIGEgY2xpZW50
IGZvciBhIHBhcnRpY3VsYXINCiBkZXBsb3ltZW50LCBjb21wYXJlZCB0byB0cmFkaXRpb25hbCBv
bmxpbmUgZG9jcywgd2hpY2ggbWF5IGJlIG5vdCBiZSB1cCB0byBkYXRlLCBvciBldmVuIG1pc3Np
bmcuIFZlcnkgbXVjaCBsaWtlIGF1dG8tZ2VuZXJhdGVkIFN3YWdnZXIgYW5kIEphdmFEb2NzLjxi
cj4NCjxicj4NCkhlcmUgYXJlIHNvbWUgZXhhbXBsZSBPSURDIGRpc2NvdmVyeSBkb2NzOjxicj4N
Cjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9v
cGVuaWQtY29uZmlndXJhdGlvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYWNjb3VudHMuZ29v
Z2xlLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbjwvYT48YnI+DQo8YnI+DQo8
YSBocmVmPSJodHRwczovL3d3dy5wYXlwYWxvYmplY3RzLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQt
Y29uZmlndXJhdGlvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnBheXBhbG9iamVjdHMu
Y29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPC9hPjxicj4NCjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbS9mYWJyaWthbWIyYy5vbm1pY3Jv
c29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbS9mYWJyaWthbWIyYy5vbm1p
Y3Jvc29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbjwvYT48YnI+
DQo8YnI+DQo8YnI+DQpXaXRoIHRoaXMgZGlzY292ZXJ5IGRvY3VtZW50IGluIHBsYWNlIHNldHVw
IG9mIGlkZW50aXR5IGZlZGVyYXRpb24gY2FuIHRoZW4gYmUgZWFzaWx5IHNjcmlwdGVkLiBGb3Ig
ZXhhbXBsZTo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9J
QU0vbGF0ZXN0L1VzZXJHdWlkZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5
LXRodW1icHJpbnQuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kb2NzLmF3cy5hbWF6b24u
Y29tL0lBTS9sYXRlc3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVyc19jcmVhdGVfb2lkY192
ZXJpZnktdGh1bWJwcmludC5odG1sPC9hPjxicj4NCjxicj4NCjxicj4NCk5vdywgZG9lcyB0aGF0
IGRpY3RhdGUgYW55IHBhcnRpY3VsYXIgYXBwIGFyY2hpdGVjdHVyZT8gTXkgcmVhZGluZyBvZiB0
aGUgc3BlYyBpcyB0aGF0IGl0IGRvZXNuJ3QsIGFuZCBpdCBzaG91bGRuJ3QgZWl0aGVyLiBCeSBz
dGF5aW5nIG5ldXRyYWwgb24gdGhlIHRvcGljcyBvZiBSUyBkaXNjb3ZlcnkgYW5kIHJlZ2lzdGVy
aW5nIFJQcyB3aXRoIFJTcy4gQW5kIGhvdyBvbmUgYXJyaXZlcyBhdCB0aGUgJnF1b3Q7LndlbGwt
a25vd24vLi4uJnF1b3Q7LiBJJ20gbm90DQogZXZlbiBzdXJlIHRoYXQgcmVzb3VyY2UgZGlzY292
ZXJ5IHNob3VsZCBiZSBhIHRvcGljIG9mIHRoaXMgV0cuIFBlcmhhcHMgdG8gdGhpcyBlbmQsIGFu
ZCB0byBwcmV2ZW50IGNvbmZ1c2lvbiB0aGF0IHRoZSBzcGVjIGlzIHRyeWluZyB0byBkbyBzb21l
dGhpbmcgbW9yZSwgYSBtb3JlIHNwZWNpZmljIHRpdGxlIHdvdWxkIHN1aXQgaXQgYmV0dGVyLiBF
LmcuICZxdW90O0FTIERpc2NvdmVyeSZxdW90Oy48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJy
Pg0KVmxhZGltaXI8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPk9uIDI1LzAyLzE2IDAyOjI1LCBQaGlsIEh1bnQgKElETSkgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5BbmQgc28gZG9lcyBvcmFjbGUgYW5k
IHNvIGRvZXMgZ29vZ2xlLiBFYWNoIGRpZmZlcmVudC4gPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+U28gaG93IGNhbiBhbiBhcHAgZGljdGF0ZSBp
dCB0aGVuIHVubGVzcyB3ZSBhbGwgZ28gdG8gYSBjb21tb24gYXJjaGl0ZWN0dXJlPzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPk9uIEZlYiAy
NCwgMjAxNiwgYXQgMTY6MDQsIE1pa2UgSm9uZXMgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5BenVyZSBkZWZpbmVzIHdheXMgZm9yIHJlc291cmNlIHNlcnZl
cnMgdG8gYmUgcmVnaXN0ZXJlZCBmb3IgdXNlIHdpdGggYSBjbGllbnQgYW5kIGZvciBjbGllbnRz
IHRvIGR5bmFtaWNhbGx5IHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIGZvciB1c2UgYXQgYSBwYXJ0
aWN1bGFyIHJlc291cmNlIHNlcnZlci4mbmJzcDsgWW91IGNhbiBjYWxsIHRoYXQgY3VzdG9tIGFy
Y2hpdGVjdHVyZSBpZiB5b3Ugd2FudC4mbmJzcDsgSXTigJlzIHdlbGwtZGVmaW5lZCBidXQgaXTi
gJlzIG5vdCBjdXJyZW50bHkgaW4gdGhlIHN0YW5kYXJkcyByZWFsbS4mbmJzcDsgSSBrbm93IHRo
YXQgR29vZ2xlIGhhcyBzeW50YXggZm9yIGRvaW5nIHRoZSBzYW1lLCBhcyBJ4oCZbSBzdXJlIGRv
IGEgbG90IG9mIG90aGVyIGNsb3VkIE9BdXRoIGRlcGxveW1lbnRzLCBzdWNoIGFzIE9yYWNsZeKA
mXMuJm5ic3A7IEZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIHdvcmtpbmcgZ3JvdXAgdGFsa2Vk
IGFib3V0IHBvc3NpYmx5IHByb2R1Y2luZyBhIHN0YW5kYXJkIHZlcnNpb24gb2Ygc3ludGF4IGZv
ciBtYWtpbmcgdGhlc2Uga2luZHMgb2YgcmVxdWVzdHMgZHVyaW5nIG91ciBkaXNjdXNzaW9ucyBp
biBQcmFndWUgKGR1cmluZyB0aGUgVG9rZW4gRXhjaGFuZ2UgZGlzY3Vzc2lvbikgYnV0IG5vYm9k
eSBoYXMgcnVuIHdpdGggdGhpcyB5ZXQuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkluIHRoaXMgc2Vuc2UsIHllcywgQXp1cmUgaXMgYW4gYXBwbGljYXRp
b24gb2YgdGhlIGtpbmQgd2XigJlyZSB0YWxraW5nIGFib3V0LiZuYnNwOyBBenVyZSBhbHJlYWR5
IGRvZXMgZGVmaW5lIHNwZWNpZmljIG5ldyBPQXV0aCAyLjAgZGlzY292ZXJ5IG1ldGFkYXRhIHZh
bHVlcyB0aGF0IGFyZSB1c2VkIGluIHByb2R1Y3Rpb24uJm5ic3A7IEEgcmVnaXN0cnkganVzdCBk
b2VzbuKAmXQgeWV0IGV4aXN0IGluIHdoaWNoIGl0IGNhbiByZWdpc3RlciB0aG9zZSB0aGF0IGFy
ZSBvZiBnZW5lcmFsIGFwcGxpY2FiaWxpdHkuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOy0tIE1pa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+RnJvbTogUGhpbCBIdW50IChJRE0pIFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+XSA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2
IDM6NTIgUE08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogTWlrZSBKb25lczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+TWlrZTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UYWtlIGEgbG9vayBhdCB0
aGUgYXNzdW1wdGlvbnMgeW91IGFyZSBtYWtpbmcuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPllvdSBzZWVtIHRvIGJlIGFzc3VtaW5nIGFwcGxp
Y2F0aW9uIHNvZnR3YXJlIGRpY3RhdGVzIG9hdXRoIGluZnJhc3RydWN0dXJlIGFyY2hpdGVjdHVy
ZSBieSBzdWdnZXN0aW5nIHRoYXQgYXBwcyByZWdpc3RlciBpbiBpYW5hLiZuYnNwOyA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Xb3VsZCBtcyBh
enVyZSBhbGxvdyBjdXN0b20gYXJjaD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5QaGlsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAxNToyOCwgTWlrZSBKb25l
cyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i
bGFuayI+Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBVc2Vy
SW5mbyBFbmRwb2ludCBwYXRoIGlzbuKAmXQgZml4ZWQgYW5kIHNvIGhhcyB0byBiZSBkaXNjb3Zl
cmVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGFn
cmVlIHRoYXQgZm9yIHNvbWUgT0F1dGggcHJvZmlsZXMsIG9uZSBvciBtb3JlIHJlc291cmNlIHNl
cnZlcnMgd2lsbCBoYXZlIHRvIGJlIGRpc2NvdmVyZWQgc3RhcnRpbmcgZnJvbSB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIuJm5ic3A7IFdvcmtpbmcgZ3JvdXAgbWVtYmVycyBoYXZlIGFsc28gZGVz
Y3JpYmVkIHdhbnRpbmcgdG8gZGlzY292ZXIgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHN0YXJ0aW5n
IGZyb20gcmVzb3VyY2Ugc2VydmVycy4mbmJzcDsgVGhlcmUgaXNu4oCZdCBhIHN0YW5kYXJkIHBy
YWN0aWNlIGZvciBhbnkgb2YgdGhpcywgd2hpY2ggaXMgd2h5IGl04oCZcyBpbnRlbnRpb25hbGx5
IGxlZnQgb3V0IG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3ByZT4N
CjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uY2UgdGhlIElBTkEgT0F1dGggRGlzY292
ZXJ5IE1ldGFkYXRhIFJlZ2lzdHJ5IGhhcyBiZWVuIGVzdGFibGlzaGVkLCB3aGljaCB3aWxsIGhh
cHBlbiBhZnRlciB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFwcHJvdmVkLCBp
dCB3aWxsIGJlIGVhc3kgZm9yIHN1YnNlcXVlbnQgc3BlY2lmaWNhdGlvbnMgdG8gZG9jdW1lbnQg
ZXhpc3RpbmcgcHJhY3RpY2UgZm9yIGRpZmZlcmVudCBPQXV0aCBwcm9maWxlcyBhbmQgcmVnaXN0
ZXIgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyBzdXBwb3J0aW5nIHRoZW0uJm5ic3A7IFNvbWUg
b2YgdGhvc2UgdmFsdWVzIHdpbGwgbGlrZWx5IGRlZmluZSB3YXlzIHRvIGRpc2NvdmVyIHJlc291
cmNlIHNlcnZlcnMsIHdoZW4gYXBwbGljYWJsZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86
cD48L286cD48L3ByZT4NCjxwcmU+QnV0IGZpcnN0LCB3ZSBuZWVkIHRvIGZpbmlzaCB0aGUgZXhp
c3Rpbmcgc3BlYywgc28gdGhhdCB0aGUgcmVnaXN0cnkgZW5hYmxpbmcgdGhlc2UgZXh0ZW5zaW9u
cyBnZXRzIGVzdGFibGlzaGVkIGluIHRoZSBmaXJzdCBwbGFjZS48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5Gcm9tOiBQaGlsIEh1bnQgKElETSkgWzxhIGhyZWY9Im1haWx0bzpwaGls
Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbTwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVh
cnkgMjQsIDIwMTYgMjoxMyBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBNaWtlIEpvbmVz
IDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js
YW5rIj4mbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5DYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292
ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPll1cC4gQW5kIGJlY2F1c2UgdGhlcmUgbWFueSByZWxhdGlvbnMgdGhlIGNsaWVudCBtaXN0
IGJlIGFibGUgdG8gZGlzY292ZXIgaXQuIFRoZSBjbGllbnQgZG9lcyBub3Qga25vdyBpZiB0aGUg
cmVzIHNlcnZlciBpcyBsZWdpdC4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+VGhlIHVzZXJpbmZvIGlzIGFsd2F5cyBmaXggYW5kIHNvIHUgZG9u
dCBuZWVkIGRpc2NvdmVyeS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxwcmU+UGhpbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9uIEZlYiAyNCwgMjAxNiwgYXQgMTQ6MDUsIE1pa2UgSm9uZXMgPGEg
aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JbiBPcGVuSUQgQ29u
bmVjdCwgdGhlcmXigJlzIGEgcmVzb3VyY2Ugc2VydmVyIGNhbGxlZCB0aGUgVXNlckluZm8gRW5k
cG9pbnQgdGhhdCByZXR1cm5zIGNsYWltcyBhYm91dCB0aGUgYXV0aGVudGljYXRlZCB1c2VyIGFz
IGEgSlNPTiBkYXRhIHN0cnVjdHVyZS4mbmJzcDsgSXRzIGxvY2F0aW9uIGlzIHB1Ymxpc2hlZCBp
biBPcGVuSUQgQ29ubmVjdCBkaXNjb3ZlcnkgbWV0YWRhdGEgYXMgdGhlIOKAnHVzZXJpbmZvX2Vu
ZHBvaW504oCdIG1ldGFkYXRhIHZhbHVlLCB3aGljaCBpcyBkZWZpbmVkIGF0IDxhIGhyZWY9Imh0
dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCNQ
cm92aWRlck1ldGFkYXRhIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mv
b3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0YWRhdGE8L2E+Ljxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XZSBkaWRu4oCZ
dCBpbmNsdWRlIHRoZSBVc2VySW5mbyBFbmRwb2ludCBpbiB0aGUgZ2VuZXJpYyBPQXV0aCBkaXNj
b3Zlcnkgc3BlYyBzaW5jZSBpbiBPQXV0aCwgdGhlcmUgYXJlIGxvdHMgb2YgcG9zc2libGUgcmVs
YXRpb25zaGlwcyBiZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgcmVzb3VyY2Ugc2Vy
dmVycyBhbmQgdGhleSBuZWVkbuKAmXQgYmUgb25lLXRvLW9uZSwgYXMgaXMgYmVpbmcgYWN0aXZl
bHkgZGlzY3Vzc2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiZuYnNwOyBGb3IgaW5zdGFuY2UsIHNl
ZSBHZW9yZ2UgRmxldGNoZXLigJlzIHJlY2VudCBjb250cmlidXRpb24uPG86cD48L286cD48L3By
ZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyBmb3IgdGhlIGdvb2QgZGlz
Y3Vzc2lvbiwgUGhpbC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBQaGls
IEh1bnQgKElETSkgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvYT5dIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMToyNSBQTTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBNaWtlIEpvbmVzPG86cD48L286cD48L3ByZT4NCjxwcmU+
Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtv
YXV0aEBpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6
IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XaGVyZSBpcyB0aGUgcHJvZmlsZSBlbmRw
b2ludCAob2lkYydzIHJlc291cmNlIHNlcnZlcikgcHVibGlzaGVkPyAoRm9yIHRoZSBub24gT0lE
QyBwZW9wbGUgb24gdGhlIGxpc3QpLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5QaGlsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAxMzowOSwgTWlrZSBKb25l
cyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i
bGFuayI+Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvIHRoZSBl
eHRlbnQgdGhhdCBnZW5lcmljIE9BdXRoIDIuMCBuZWVkcyB0byBwdWJsaXNoIHNvbWUgb2YgdGhl
IHNhbWUgaW5mb3JtYXRpb24gYXMgT3BlbklEIENvbm5lY3Qg4oCTIHdoaWNoIGlzIGJ1aWx0IG9u
IGdlbmVyaWMgT0F1dGggMi4wIOKAkyBpdCBtYWtlcyBzZW5zZSB0byBwdWJsaXNoIHRoYXQgaW5m
b3JtYXRpb24gdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBzeW50YXgsIHNpbmNlIHRoYXQgc3ludGF4
IGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UuJm5ic3A7IFRoYXQgd2hhdCB0aGlzIGRyYWZ0
IGFjY29tcGxpc2hlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4N
CjxwcmU+VGhlcmXigJlzIG5vdGhpbmcgQ29ubmVjdC1zcGVjaWZpYyBhYm91dCB1c2luZyBtZXRh
ZGF0YSByZXNwb25zZSB2YWx1ZXMgbGlrZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7YXV0aG9yaXphdGlvbl9l
bmRwb2ludCZxdW90OzogPGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9y
aXplIiB0YXJnZXQ9Il9ibGFuayI+JnF1b3Q7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0
aG9yaXplJnF1b3Q7PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1
b3Q7dG9rZW5fZW5kcG9pbnQmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUu
Y29tL3Rva2VuIiB0YXJnZXQ9Il9ibGFuayI+JnF1b3Q7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5j
b20vdG9rZW4mcXVvdDs8L2E+LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAm
cXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkJnF1b3Q7OiBbJnF1b3Q7
Y2xpZW50X3NlY3JldF9iYXNpYyZxdW90OywgJnF1b3Q7cHJpdmF0ZV9rZXlfand0JnF1b3Q7XSw8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1b3Q7cmVnaXN0cmF0aW9uX2Vu
ZHBvaW50JnF1b3Q7OiA8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdpc3Rl
ciIgdGFyZ2V0PSJfYmxhbmsiPiZxdW90O2h0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lz
dGVyJnF1b3Q7PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1b3Q7
cmVzcG9uc2VfdHlwZXNfc3VwcG9ydGVkJnF1b3Q7OiZuYnNwOyBbJnF1b3Q7Y29kZSZxdW90Oywg
JnF1b3Q7dG9rZW4mcXVvdDtdLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyAmbmJzcDsm
cXVvdDtzZXJ2aWNlX2RvY3VtZW50YXRpb24mcXVvdDs6IDxhIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIu
ZXhhbXBsZS5jb20vc2VydmljZV9kb2N1bWVudGF0aW9uLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4m
cXVvdDtodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1s
JnF1b3Q7PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+SXMgdGhlcmUgYSByZWFzb24gdGhhdCB5b3Ugd291bGQgbGlrZSB0aGUgc3ludGF4IGZvciBh
bnkgb2YgdGhlc2Ugb3IgdGhlIG90aGVyIGdlbmVyYWxseSBhcHBsaWNhYmxlIE9BdXRoIDIuMCBt
ZXRhZGF0YSB2YWx1ZXMgdG8gYmUgZGlmZmVyZW50PyZuYnNwOyBJIGRvbuKAmXQgc2VlIGFueSBn
b29kIHJlYXNvbiBmb3IgdW5uZWNlc3NhcnkgZGlmZmVyZW5jZXMgdG8gYmUgaW50cm9kdWNlZC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBQaGlsIEh1bnQgKElETSkgWzxh
IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0
bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6
IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMTI6NDUgUE08bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5UbzogQW50aG9ueSBOYWRhbGluIDxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29m
dC5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0OzwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogTWlrZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O01pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPiA8YSBocmVmPSJtYWls
dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRo
IDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286
cD48L3ByZT4NCjxwcmU+TWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5QdWJsaXNoaW5nIG9uIGRldiBwYWdlcyBkb2VzIG5vdCB3b3JrIGZvciBzb2Z0
d2FyZSAoZXNwIG9wZW4gc291cmNlKSB0aGF0IGlzIGRlcGxveWVkIGJvdGggaW4gZW50ZXJwcmlz
ZXMgYW5kIG9uIFBhYVMgY2xvdWQgcHJvdmlkZXJzLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgY3VycmVudCBkcmFmdCBpcyBtYXkgY29k
aWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBhbmQgYmUgYXBwcm9wcmlhdGUgZm9yIG9pZGMgYnV0
IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJpYyBvYXV0aC4gVGhlcmUgaXMgbm8gZ2VuZXJpYyBv
YXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGltZS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+UGhpbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uIEZlYiAyNCwgMjAxNiwgYXQgMTA6MjUsIEFu
dGhvbnkgTmFkYWxpbiA8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+Jmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1cmUgdGhl
cmUgaXMsIGl0IGlzIGFzIHlvdSBoYXZlIG5vdyBtYWRlIGl0IGZhciBlYXNpZXIgYW5kIHRoZSBz
ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBldmVuIGFkZHJlc3MgdGhpczxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBNaWtlIEpvbmVz
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIw
MTYgMTA6MjIgQU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogQW50aG9ueSBOYWRhbGluIDxh
IGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7
dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzog
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O29hdXRo
QGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5TdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86
cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIHdl4oCZZCBk
aXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZmZWN0aXZlIHNlY3VyaXR5IGRpZmZl
cmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gYmVpbmcgcHVibGlzaGVkIGluIGFu
IGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBhbmQgaXQgYmVpbmcgcHVibGlzaGVk
IGluIGEgc3RhbmRhcmQgZm9ybWF0LiAmbmJzcDvigJxTZWN1cml0eSBieSBvYnNjdXJpdHnigJ0g
YWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBBbnRob255IE5hZGFsaW4gPG86cD48L286
cD48L3ByZT4NCjxwcmU+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMDowMSBB
TTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7TWljaGFlbC5K
b25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT47IFBoaWwgSHVudCAoSURNKSA8YSBocmVmPSJtYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7cGhpbC5odW50QG9y
YWNsZS5jb20mZ3Q7PC9hPjsgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0
OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0
aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9v
OnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFu
ZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVh
ZHkgd2lkZWx5IGRlcGxveWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGF0IG1heSBiZSB3aWRlbHkgZGVwbG95ZWQgZm9y
IE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQgZm9yIE9BdXRoLiBUaGVyZSBhcmUgc29tZSBh
dXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292ZXJ5IGZvciBlbmRwb2ludCB0aGF0IHJlYWxs
eSBzaG91bGQgbm90IGJlIGluIGFuIE9BdXRoIHN0YW5kYXJkIHNpbmNlIGl04oCZcyByZWFsbHkg
bm90IGRlYWx0IHdpdGguIE5vdyB0aGF0IGFsbCB0aGlzIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJs
ZSBpdCBtYWtlcyBwb2tpbmcgYXJvdW5kIHRoZSBlbmRwb2ludCBtb3JlIGZvY3VzZWQgZm9yIHBl
b3BsZSB0aGF0IHdhbnQgdG8gZGlzcnVwdCB5b3VyIGVuZHBvaW50cywgdGhhdCBpcyByZWFsbHkg
bm90IGFkZHJlc3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMmbmJzcDsgc2VjdGlv
biBhdCBhbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+
RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg
T2YgTWlrZSBKb25lczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVi
cnVhcnkgMjQsIDIwMTYgOTo1NCBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBQaGlsIEh1
bnQgKElETSkgPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9i
bGFuayI+Jmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OzwvYT47IE5hdCBTYWtpbXVyYSA8YSBo
cmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3Nha2lt
dXJhQGdtYWlsLmNvbSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9
Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtvYXV0aEBpZXRmLm9y
ZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVj
dDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgcG9pbnQgb2YgdGhlIFdH
TEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9u
YWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuPG86cD48L286cD48L3ByZT4N
CjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5vbmUgb2YgTmF0IG9yIEpvaG4gb3IgSSBh
cmUgc3VnZ2VzdGluZyB0aGF0IGFkZGl0aW9uYWwgcmVsYXRlZCBmdW5jdGlvbmFsaXR5IHdvbuKA
mXQgYmUgY3JlYXRlZC4mbmJzcDsgSeKAmW0gc3VyZSBpdCB3aWxsIGJlLiZuYnNwOyBTb21lIGFw
cGxpY2F0aW9ucyB3aWxsIHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0
YWRhdGEuJm5ic3A7IFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgbGluayBoZWFkZXJzLiZuYnNwOyBT
b21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0aW9uLXNwZWNpZmljIC53ZWxsLWtub3duIHZh
bHVlcy4mbmJzcDsgSeKAmW0gc3VyZSB0aGVyZeKAmXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0
IGV2ZW4gdGhvdWdodCBhYm91dC4mbmJzcDsgQWxsIG9mIHRoZXNlIGRlcGVuZCB1cG9uIGhhdmlu
ZyBhIGRpc2NvdmVyeSBtZXRhZGF0YSBkb2N1bWVudCBmb3JtYXQgYW5kIG5vbmUgb2YgdGhlbSBj
aGFuZ2UgaXQg4oCTIG90aGVyIHRoYW4gcG9zc2libHkgdG8gcmVnaXN0ZXIgYWRkaXRpb25hbCBk
aXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5TbyBieSBhbGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3VwIHNob3Vs
ZCBjb250aW51ZSBkaXNjdXNzaW5nIGludmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRlZCBtZWNo
YW5pc21zIHRoYXQgbWFrZSBzZW5zZSBpbiBzb21lIGNvbnRleHRzLiZuYnNwOyBBdCB0aGUgc2Ft
ZSB0aW1lLCB3ZSBjYW4gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGFscmVhZHkgd2lkZWx5IGRl
cGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0aGF0IGFsbCBvZiB0aGVzZSBtZWNoYW5pc21zIHdp
bGwgbmVlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5Gcm9tOiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl
aGFsZiBPZiBQaGlsIEh1bnQgKElETSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBXZWRu
ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDg6MzkgQU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5U
bzogTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdl
dD0iX2JsYW5rIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5DYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5
IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkkgYW0gc3VnZ2VzdGluZyB0aGF0IHBhcnQgb2YgdGhlIGRpc2NvdmVyeSBzb2x1dGlvbiBoYXMg
dG8gYmUgdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoYXQgcmVzb3VyY2UgZW5kcG9pbnQgaXQgd2Fu
dHMgdGhlIG9hdXRoIGNvbmZpZ3VyYXRpb24gZGF0YSBmb3IuIDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvIGlmIDxhIGhyZWY9Imh0dHA6Ly9y
ZXMuZXhhbXBsZS5ldmlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJlcy5leGFtcGxlLmV2aWwuY29t
PC9hPiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgPGEgaHJlZj0iaHR0cDov
L2FzLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXMuZXhhbXBsZS5jb208L2E+IHRoZSBh
dXRoeiBkaXNjb3Zlcnkgc2hvdWxkIGZhaWwgaW4gc29tZSB3YXkgKGVnIHJldHVybiBub3RoaW5n
KS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
VGhlcmUgbWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlzY292ZXJ5
LiBPciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgn
cyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhl
IHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRo
ZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNo
aXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5IHBoYXNl
IHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhh
dCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5kcG9pbnRz
IGV0Yy4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmU+VGhpcyBpcyB3aHkgSSB3YXMgZGlzYXBwb2ludGVkIGFib3V0IHdnbGMgb24gZGlzY292ZXJ5
LiBXZSBoYWQgYSBzdGFydGluZyBwb2ludCBmb3IgZ3JvdXAgYWRvcHRpb24gYnV0IHdlIGhhdmVu
J3QgcmVhbGx5IGRlZmluZWQgdGhlIGZ1bGwgcmVxdWlyZW1lbnRzIElNTy4gPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SSBhbSBvbiB2YWNhdGlv
biBvciBJIHdvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBzb21lIGRyYWZ0IGNoYW5nZXMgb3Ig
YSBuZXcgZHJhZnQuIEkgYXBvbG9naXplIEkgY2FuJ3QgZG8gaXQgbm93LiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QaGlsPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2
LCBhdCAwODoxMiwgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT4gd3JvdGU6
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SGkg
UGhpbCwgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmU+QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhlIEFTIG1ldGFkYXRhIHNob3VsZCBpbmNsdWRl
IHRoZSBSUyBVUklzPyBDdXJyZW50bHksIGl0IGRvZXMgbm90LCBidXQgaXQgY2FuIGJlIGRvbmUs
IEkgZ3Vlc3MuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPlRoZSB3YXkgb2F1dGgtbWV0YSB3b3JrcyBpcyB0aGF0IDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjEuIFJTIHRlbGxzIHRoZSBjbGll
bnQgd2hlcmUgdGhlIEFTIGlzLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4yLiBBUyB0ZWxscyB0
aGUgY2xpZW50IHdoaWNoIFJTIGVuZHBvaW50cyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuIDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkV2ZW4gaWYg
dGhlcmUgaXMgYSBiYWQgQVMgd2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUg
Z29vZCBSUywgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUg
YXV0aHogc2VydmVyIHdpbGwgc2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1h
eSB3YW50IHRvIHNlbmQgdGhlIHRva2VuIHRvLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5OYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86
cD48L286cD48L3ByZT4NCjxwcmU+MjAxNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN
YWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDwvc3Bhbj4yPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pyIPC9zcGFu
PjI0PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fu
cy1zZXJpZiI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3Vu
IEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7msLQ8L3NwYW4+KSAyMzo1OSBQaGlsIEh1bnQgPGEg
aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3Bo
aWwuaHVudEBvcmFjbGUuY29tJmd0OzwvYT46PG86cD48L286cD48L3ByZT4NCjxwcmU+TmF0LDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5J4oCZbSBub3Qg
c3VyZSB0aGF0IGhhdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIHRlbGwgdGhlIGNsaWVudCB3aGVy
ZSBpdHMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgc2VjdXJlIGJ5IGl0c2VsZi4gVGhlIHJlbGF0
aW9uc2hpcCBiZXR3ZWVuIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBhbmQgdGhlIFJlc291cmNl
IHNlcnZlciBuZWVkIHRvIGJlIGJvdW5kIHRvZ2V0aGVyIGluIG9uZSBvZiB0aGUgZGlzY292ZXJ5
IGVuZHBvaW50cyAodGhlIHJlc291cmNlIGFuZC9vciB0aGUgb2F1dGggc2VydmljZSBkaXNjb3Zl
cnkpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiBh
IGNsaWVudCBkaXNjb3ZlcnMgYSBmYWtlIHJlc291cmNlIHNlcnZlciB0aGF0IGlzIHByb3h5aW5n
IGZvciBhIHJlYWwgcmVzb3VyY2Ugc2VydmVyIHRoZSBjdXJyZW50IGRpc2NvdmVyeSBzcGVjIHdp
bGwgbm90IGxlYWQgdGhlIGNsaWVudCB0byB1bmRlcnN0YW5kIGl0IGhhcyB0aGUgd3JvbmcgcmVz
b3VyY2Ugc2VydmVyLiBSYXRoZXIgdGhlIGZha2UgcmVzb3VyY2Ugc2VydmljZSB3aWxsIGp1c3Qg
aGF2ZSBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRlcmNl
cHQgcmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2VyZSBh
YmxlIHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0aW9u
IHNlcnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIE9BdXRoIERp
c2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0aGF0IHRoZSBz
ZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291cmNlIGVuZHBv
aW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlz
IG5vdCBvbmx5IHdvcmtzIGluIG5vcm1hbCBPQXV0aCBidXQgc2hvdWxkIGFkZCBzZWN1cml0eSBl
dmVuIHRvIFVNQSBzaXR1YXRpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5QaGlsPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i
aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVu
ZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86cGhp
bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uIEZl
YiAyNCwgMjAxNiwgYXQgMzo1NCBBTSwgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtp
bXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0
OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhpIFRob21hcywgPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+aW5saW5lOiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4yMDE2PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+
5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx
dW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaciDwv
c3Bhbj4pIDE4OjQ0IFRob21hcyBCcm95ZXIgPGEgaHJlZj0ibWFpbHRvOnQuYnJveWVyQGdtYWls
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDt0LmJyb3llckBnbWFpbC5jb20mZ3Q7PC9hPjo8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5Db3VsZG4ndCB0aGUgZG9jdW1lbnQgb25seSBkZXNjcmliZSB0
aGUgbWV0YWRhdGE/PG86cD48L286cD48L3ByZT4NCjxwcmU+SSBxdWl0ZSBsaWtlIHRoZSBpZGVh
IG9mIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgaWYgeW91IHJlYWxseSB3YW50IHRvIGRvIGRp
c2NvdmVyeSwgYW5kIGxlYXZlIGl0IG9wZW4gdG8gaW1wbGVtZW50ZXJzIC8gdG8gb3RoZXIgc3Bl
Y3MgdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJMIGZvciAmcXVvdDthdXRvLWNvbmZpZ3VyYXRp
b24mcXVvdDsuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBo
ZXJlIHdvdWxkIHRoZW4gZWl0aGVyIGJlIHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVk
IGFzIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEgbWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBh
IGJhc2lzIGZvciBvdGhlciBtZXRhZGF0YSBzcGVjcyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuIDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPldpdGggZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSdzICZx
dW90O2R1cmkmcXVvdDsgYW5kIHRoZSAmcXVvdDtzY29wZSZxdW90OyBhdHRyaWJ1dGUgb2YgV1dX
LUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIsIHlvdSBoYXZlIGV2ZXJ5dGhpbmcgeW91IG5l
ZWQgdG8gcHJvY2VlZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5ZdXAuIFRoYXQncyBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyB0byBiZSBSRVNU
ZnVsLCBpcyBpdCBub3Q/Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkluIE9BdXRoJ3MgY2FzZSwgdGhlIHJlc291cmNlIGFuZCB0aGUg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIHVzdWFsbHkgdGlnaHRseSBjb3VwbGVkLiAoT3RoZXJ3
aXNlLCB5b3UgbmVlZCBhbm90aGVyIHNwZWNzIGxpa2UgVU1BLikgPG86cD48L286cD48L3ByZT4N
CjxwcmU+U28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gdGVsbCBlaXRo
ZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2ludC4gSW4gc29tZSB0cnVzdGVkIGVu
dmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwgcmV0dXJuIHRoZSBsb2NhdGlvbiBv
ZiB0aGUgYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4gdGhlc2UgY2FzZXMsIHlv
dSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93biB1cmkgYXMgeW91IHNh
eS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJhdGlvbiBmaWxlIGxvY2F0
aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0byBwb2xsdXRlIHRoZSB1
cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+KHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUgc2V2
ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVkZ2Ut
Y2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBkYXRl
ZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3VjaCB0aGF0IGFuIFJTIGNvdWxkIHJldHVybiBzZXZl
cmFsIFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciwgZWFjaCB3aXRoIGl0cyBvd24gJnF1b3Q7c2Nv
cGUmcXVvdDsgYW5kICZxdW90O2R1cmkmcXVvdDsgdmFsdWU/KTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ZZWFoLCBJIGd1ZXNzIGl0IGlzIGFuIGVkZ2Ug
Y2FzZS4gSSB3b3VsZCByYXRoZXIgbGlrZSB0byBzZWUgdGhlc2UgYXV0aHogc2VydmVycyB0byBk
ZXZlbG9wIGEgdHJ1c3QgZnJhbWV3b3JrIHVuZGVyIHdoaWNoIHRoZXkgY2FuIGFncmVlIG9uIGEg
c2luZ2xlIHNldCBvZiBjb21tb24gc2NvcGUgcGFyYW1ldGVyIHZhbHVlcy4gPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hlZXJzLCA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5OYXQ8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T24gRnJpLCBGZWIg
MTksIDIwMTYgYXQgMTA6NTkgUE0gSnVzdGluIFJpY2hlciA8YSBocmVmPSJtYWlsdG86anJpY2hl
ckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8L2E+IHdy
b3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBuZXdseS10cmltbWVkIE9BdXRoIERpc2Nv
dmVyeSBkb2N1bWVudCBpcyBoZWxwZnVsIGFuZCBtb3ZpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlv
bi4gSXQgZG9lcywgaG93ZXZlciwgc3RpbGwgaGF2ZSB0b28gbWFueSB2ZXN0aWdlcyBvZiBpdHMg
T3BlbklEIENvbm5lY3Qgb3JpZ2lucy4gT25lIGlzc3VlIGluIHBhcnRpY3VsYXIgc3RpbGwgcmVh
bGx5IGJvdGhlcnMgbWU6IHRoZSB1c2Ugb2Yg4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1
cmF0aW9u4oCdIGluIHRoZSBkaXNjb3ZlcnkgcG9ydGlvbi4gSXMgdGhpcyBhbiBPQXV0aCBkaXNj
b3ZlcnkgZG9jdW1lbnQsIG9yIGFuIE9wZW5JRCBDb25uZWN0IG9uZT8gVGhlcmUgaXMgYWJzb2x1
dGVseSBubyBjb21wZWxsaW5nIHJlYXNvbiB0byB0aWUgdGhlIFVSTCB0byB0aGUgT0lEQyBkaXNj
b3ZlcnkgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24vb2F1dGgt
YXV0aG9yaXphdGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxvY2F0aW9u
LCBhbmQgc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxlIGZyb20g
4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2ZXIgYWxz
byBwcm92aWRlcyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVyIGFwcGxp
Y2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBP
QXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZp
YyBkaXNjb3ZlcnkgZG9jdW1lbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+IOKAlCBKdXN0aW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48
L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5v
cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxp
c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0
aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+VmxhZGltaXIgRHpodXZpbm92IDo6IDxh
IGhyZWY9Im1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZs
YWRpbWlyQGNvbm5lY3QyaWQuY29tPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BY2PR03MB442FFEDAA5B8ED7A8FAAD9BF5B80BY2PR03MB442namprd_--


From nobody Sat Feb 27 10:10:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FBA1ADBFE for ; Sat, 27 Feb 2016 10:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWhOiIFKzo11 for ; Sat, 27 Feb 2016 10:10:21 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E04B1AD37B for ; Sat, 27 Feb 2016 10:10:21 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1RIAJgB022862 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Feb 2016 18:10:19 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1RIAI3V025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 27 Feb 2016 18:10:18 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1RIAHrG009657; Sat, 27 Feb 2016 18:10:17 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Feb 2016 10:10:16 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E7A807A-7B20-4C3F-8C8E-E82E249B326E"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Sat, 27 Feb 2016 10:10:19 -0800
Message-Id: 
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>  
To: Samuel Erdtman 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 18:10:29 -0000

--Apple-Mail=_8E7A807A-7B20-4C3F-8C8E-E82E249B326E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The name change seems appropriate given that the WG members have decided =
not to address the issue of resource discovery as part of this =
specification.

If the consensus is to limit the scope of the specification, then I =
suggest the following security considerations text.

Resource Discovery

Secure discovery of resource endpoints is out-of-scope of this =
specification. This specification assumes that the client has already =
securely discovered the correct resource endpoint and that the client =
has correctly selected the correct corresponding discovery for OAuth =
Authorization server. Implementers MUST consider that if an incorrect =
resource endpoint was discovered by the client that an attacker will be =
able to set up a man-in-the-middle proxy to a real resource server =
without detection by the authorization server or the client.=20

It may be more appropriate to even include this text in the introduction =
as a cautionary "red flag" to implementers.

Once again, I strongly urge the WG to actually include a method for the =
client to discovery that the oauth cliet has correctly discovered an =
authorization server that is willing and able to issue access tokens for =
a given resource endpoint. I believe this relationship is critical to =
security of OAuth in cases where resource endpoints are discovered =
dynamically.  Of course willing and able means that the AS believes that =
the endpoint is legitimate.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman  wrote:
>=20
> +1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
>=20
> //Samuel
>=20
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones =
> =
wrote:
> Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined =
to accept your suggestion to change the title from =E2=80=9COAuth 2.0 =
Discovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D.  While the abstract already makes it clear that the =
scope of the document is AS discovery, doing so in the title seems like =
it could help clarify things, given that a lot of the discussion seems =
to be about resource discovery, which is out of scope of the document.
>=20
> =20
>=20
> I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93 but unlike authorization server discovery, =
where there=E2=80=99s lots of existing practice, including using the =
existing data format for describing OAuth implementations that aren=E2=80=99=
t being used with OpenID Connect, there=E2=80=99s no existing practice =
to standardize for resource discovery.  The time to create a standard =
for that seems to be after existing practice has emerged.  It *might* or =
might not use new metadata values in the AS discovery document, but =
that=E2=80=99s still to be determined.  The one reason to leave the =
title as-is is that resource discovery might end up involving extensions =
to this metadata format in some cases.
>=20
> =20
>=20
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  The discovery =
document is about the AS.  We don=E2=80=99t yet have a specification or =
existing practice for RS discovery, which would be the 6750 analogy.
>=20
> =20
>=20
> In summary, which title do people prefer?
>=20
> =C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
>=20
> =C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
>=20
> =20
>=20
>                                                           -- Mike
>=20
> =C2=A0 <>
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: oauth@ietf.org 
>=20
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>=20
> =20
>=20
> In OIDC the discovery doc is of great utility to developers and =
integrators. Developers also tend to find it a more accurate and =
complete description of how to set up a client for a particular =
deployment, compared to traditional online docs, which may be not be up =
to date, or even missing. Very much like auto-generated Swagger and =
JavaDocs.
>=20
> Here are some example OIDC discovery docs:
>=20
> https://accounts.google.com/.well-known/openid-configuration =

>=20
> https://www.paypalobjects.com/.well-known/openid-configuration =

>=20
> =
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-k=
nown/openid-configuration =

>=20
>=20
> With this discovery document in place setup of identity federation can =
then be easily scripted. For example:
>=20
> =
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_=
oidc_verify-thumbprint.html =

>=20
>=20
> Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one =
arrives at the ".well-known/...". I'm not even sure that resource =
discovery should be a topic of this WG. Perhaps to this end, and to =
prevent confusion that the spec is trying to do something more, a more =
specific title would suit it better. E.g. "AS Discovery".
>=20
> Cheers,
>=20
> Vladimir
>=20
>=20
>=20
>=20
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>=20
> And so does oracle and so does google. Each different.=20
> =20
> So how can an app dictate it then unless we all go to a common =
architecture?
> =20
> Phil
> =20
> On Feb 24, 2016, at 16:04, Mike Jones  =
 wrote:
> =20
> Azure defines ways for resource servers to be registered for use with =
a client and for clients to dynamically request an access token for use =
at a particular resource server.  You can call that custom architecture =
if you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently =
in the standards realm.  I know that Google has syntax for doing the =
same, as I=E2=80=99m sure do a lot of other cloud OAuth deployments, =
such as Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working =
group talked about possibly producing a standard version of syntax for =
making these kinds of requests during our discussions in Prague (during =
the Token Exchange discussion) but nobody has run with this yet.
> =20
> In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 =
discovery metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Take a look at the assumptions you are making.=20
> =20
> You seem to be assuming application software dictates oauth =
infrastructure architecture by suggesting that apps register in iana. =20=

> =20
> Would ms azure allow custom arch?
> =20
> Phil
> =20
> On Feb 24, 2016, at 15:28, Mike Jones  =
 wrote:
> =20
> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be =
discovered.
> =20
> I agree that for some OAuth profiles, one or more resource servers =
will have to be discovered starting from the authorization server.  =
Working group members have also described wanting to discover =
authorization servers starting from resource servers.  There isn=E2=80=99t=
 a standard practice for any of this, which is why it=E2=80=99s =
intentionally left out of the current specification.
> =20
> Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it =
will be easy for subsequent specifications to document existing practice =
for different OAuth profiles and register discovery metadata values =
supporting them.  Some of those values will likely define ways to =
discover resource servers, when applicable.
> =20
> But first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones  =

> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Yup. And because there many relations the client mist be able to =
discover it. The client does not know if the res server is legit.=20
> =20
> The userinfo is always fix and so u dont need discovery.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 14:05, Mike Jones  =
 wrote:
> =20
> In OpenID Connect, there=E2=80=99s a resource server called the =
UserInfo Endpoint that returns claims about the authenticated user as a =
JSON data structure.  Its location is published in OpenID Connect =
discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata =
value, which is defined at =
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata=
 =
.
> =20
> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they needn=E2=80=99=
t be one-to-one, as is being actively discussed by the working group.  =
For instance, see George Fletcher=E2=80=99s recent contribution.
> =20
> Thanks for the good discussion, Phil.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Where is the profile endpoint (oidc's resource server) published? (For =
the non OIDC people on the list).=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 13:09, Mike Jones  =
 wrote:
> =20
> To the extent that generic OAuth 2.0 needs to publish some of the same =
information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly =
the same syntax, since that syntax is already in widespread use.  That =
what this draft accomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response =
values like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize" =
,
>    "token_endpoint": "https://server.example.com/token" =
,
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register" =
,
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": =
"http://server.example.com/service_documentation.html" =
,
> =20
> Is there a reason that you would like the syntax for any of these or =
the other generally applicable OAuth 2.0 metadata values to be =
different?  I don=E2=80=99t see any good reason for unnecessary =
differences to be introduced.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin  =

> Cc: Mike Jones  =
;  =
  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) =
that is deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be =
appropriate for oidc but it is not ready for generic oauth. There is no =
generic oauth experience at this time.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  =
 wrote:
> =20
> Sure there is, it is as you have now made it far easier and the =
security considerations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin  =

> Cc:    =

> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective =
security difference between discovery information being published in an =
ad-hoc fashion on developer pages and it being published in a standard =
format.  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security =
at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones  =
; Phil Hunt (IDM) =
 ; Nat Sakimura =
 
> Cc:    =

> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for =
OAuth. There are some authentication mechanism discovery for endpoint =
that really should not be in an OAuth standard since it=E2=80=99s really =
not dealt with. Now that all this information is available it makes =
poking around the endpoint more focused for people that want to disrupt =
your endpoints, that is really not addressed in the security =
considerations  section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM)  =
; Nat Sakimura  =

> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related =
functionality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  =
Some applications will use WebFinger to locate the discovery metadata.  =
Some will possibly use link headers.  Some will possibly use =
application-specific .well-known values.  I=E2=80=99m sure there=E2=80=99s=
 other things I haven=E2=80=99t even thought about.  All of these depend =
upon having a discovery metadata document format and none of them change =
it =E2=80=93 other than possibly to register additional discovery =
metadata values.
> =20
> So by all means, the working group should continue discussing =
inventing possible new related mechanisms that make sense in some =
contexts.  At the same time, we can finish standardizing the already =
widely deployed core functionality that all of these mechanisms will =
need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura  
> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the =
client indicating what resource endpoint it wants the oauth =
configuration data for.=20
> =20
> So if res.example.evil.com  is not a =
valid resource endpoint for as.example.com  the =
authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change =
the order of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of =
authorization (the resource) is never specified. It is often bound up in =
the client registration and an often implied 1:1 relationship between =
resource and as. Given that in discovery phase registration has not yet =
occurred it seems important that the client know it has a valid =
combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a =
starting point for group adoption but we haven't really defined the full =
requirements IMO.=20
> =20
> I am on vacation or I would put some thought into some draft changes =
or a new draft. I apologize I can't do it now.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 08:12, Nat Sakimura  =
 wrote:
> =20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? =
Currently, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will =
say that is not the place the client may want to send the token to.=20
> =20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt =
 :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client =
where its authorization server is secure by itself. The relationship =
between the Authorization Server and the Resource server need to be =
bound together in one of the discovery endpoints (the resource and/or =
the oauth service discovery).
> =20
> If a client discovers a fake resource server that is proxying for a =
real resource server the current discovery spec will not lead the client =
to understand it has the wrong resource server. Rather the fake resource =
service will just have a fake discovery service. The hacker can now =
intercept resource payload as well as tokens because they were able to =
convince the client to use the legit authorization service but use the =
token against the hackers proxy.
> =20
> The OAuth Discovery service needs to confirm to the client that the =
server is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to =
UMA situations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
> =20
> =20
> =20
> =20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  =
 wrote:
> =20
> =20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
 :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any =
URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a =
basis for other metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually =
tightly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as =
well return the location of the authz server configuration data. In =
these cases, you do not have to decide on what .well-known uri as you =
say. This frees up developers from configuration file location =
collisions etc. We should strive not to pollute the uri space as much as =
possible.=20
> =20
> (well, except if there are several ASs each with different scopes; =
sounds like an edge-case to me though; maybe RFC6750 should instead be =
updated with such a parameter such that an RS could return several =
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these =
authz servers to develop a trust framework under which they can agree on =
a single set of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
> =20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  =
 wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
> =20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery =
document.
> =20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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

>=20
>=20
> --=20
> Vladimir Dzhuvinov :: vladimir@connect2id.com =

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

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


--Apple-Mail=_8E7A807A-7B20-4C3F-8C8E-E82E249B326E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


The name change seems appropriate given that =
the WG members have decided not to address the issue of resource =
discovery as part of this specification.

If the consensus is to limit the scope =
of the specification, then I suggest the following security =
considerations text.

Resource =
Discovery

Secure discovery of resource endpoints =
is out-of-scope of this specification. This specification assumes that =
the client has already securely discovered the correct resource endpoint =
and that the client has correctly selected the correct corresponding =
discovery for OAuth Authorization server. Implementers MUST consider =
that if an incorrect resource endpoint was discovered by the client that =
an attacker will be able to set up a man-in-the-middle proxy to a real =
resource server without detection by the authorization server or the =
client. 

It may be more appropriate to even include this text in the =
introduction as a cautionary "red flag" to implementers.

Once again, I strongly =
urge the WG to actually include a method for the client to discovery =
that the oauth cliet has correctly discovered an authorization server =
that is willing and able to issue access tokens for a given resource =
endpoint. I believe this relationship is critical to security of OAuth =
in cases where resource endpoints are discovered dynamically.  Of =
course willing and able means that the AS believes that the endpoint is =
legitimate.
=

--Apple-Mail=_8E7A807A-7B20-4C3F-8C8E-E82E249B326E--


From nobody Sat Feb 27 10:16:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604801B29BC for ; Sat, 27 Feb 2016 10:16:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN5RbRngyBmh for ; Sat, 27 Feb 2016 10:16:11 -0800 (PST)
Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088031B29B7 for ; Sat, 27 Feb 2016 10:16:10 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-03.prod.phx3.secureserver.net with  id PWG81s00215ZTut01WG84f; Sat, 27 Feb 2016 11:16:10 -0700
To: Brian Campbell , Hannes Tschofenig 
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net> 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56D1E7E7.7070200@connect2id.com>
Date: Sat, 27 Feb 2016 20:16:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000301010209030502030709"
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 18:16:13 -0000

This is a cryptographically signed message in MIME format.

--------------ms000301010209030502030709
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,

On 27/02/16 00:27, Brian Campbell wrote:
> My preference is for Option A.
>
> The mix-up attack, in all it's variations, relies on there being no mea=
ns
> in OAuth for the AS to identify itself to the client when it returns th=
e
> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigati=
on'
> addresses that fundamental missing piece by including the 'iss'
> authorization response parameter.

This fundamental piece is indeed missing. I'm not sure measure "A" can
also cover dynamic discovery and registration though. The mixup attack
was originally described there, with OpenID Connect.

How about this variation:

Suppose the malicious IdP:

1. Registers the client under attack for
a) malicious authz endpoint
b) malicious token endpoint (optional)

=2E.. while also acting as proxy, where there are two variants:
a) repeats the client registration with the honest IdP to obtain
client_id + credentials that it keeps for itself; or
b) is already registered as a client with the honest IdP

Then:

1. When the authz request is made to the malicious authz endpoint, the
request is rewritten with the client_id and redirect_uri which the
malicious IdP has with the honest IdP. The state may or may not be replac=
ed.

2. The browser is then given a second redirect with the rewritten
parameters to the authz endpoint of the honest IdP.

3. The user doesn't notice this double redirect, and logs in / gives
consent.

4. The honest IdP sends the browser back to the registered malicious
redirect_uri. The attacker receives the code or tokens (depending on the
response type)

5. A second redirect is made back to the redirect_uri of the client,
with rewritten state, iss, client_id


What is your take on this?

The ideal fix for me would be one that covers dynamic discovery and
registration as well. I'm not convinced option A does that.

Cheers,

Vladimir

> During the course of the discussions in Darmstadt Hans and I independen=
tly
> implemented and successfully interop tested the 'iss' and 'client_id'
> authorization response parameters, which is what was anticipated to be =
in
> the mitigation draft. Doing so was very simple and straightforward. And=
 it
> addresses the vulnerability. We decided, unfortunately, to pull that
> functionality out of a looming a product release due to the churn in th=
is
> WG and the perceived risk of changes in what would eventually become th=
e
> standard solution. Of course, that kind of risk is always present with
> draft standards but it's been very frustrating in this case to have wor=
ked
> towards a simple solution to a known problem only to have progress get =
hung
> up in lack of agreement in this WG.
>
> I'll also say that in many/most cases the AS doesn't explicitly know al=
l of
> the resources that tokens it issues can or will be used at (and there a=
re
> often more than one). So the ruri/Resource URI parameter isn't really a=

> workable option.
>
>
>
> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
>> Vladimir,
>>
>> yes, we could do a formal analysis and it would be a very good idea.
>> It would even go faster if a few of us work together on it. Anyone
>> interested?
>>
>> This would be a good contribution for the workshop in July, btw.
>>
>> Ciao
>> Hannes
>>
>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>>> Hi Mike,
>>>
>>> You mention that you spent considerable time in research. I wonder if=

>>> there is existing theory, in communications or information theory, th=
at
>>> can be used to formally establish and prove (or disprove) the securit=
y
>>> of the proposed OAuth measures? Perhaps some work that is totally
>>> unrelated to identity and the web protocols, but could well apply her=
e?
>>>
>>> My reasoning is that we have a closed system that is fairly simple, s=
o
>>> formal analysis must be entirely possible.
>>>
>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>
>>> 2. The OAuth protocol follows a simple and well-defined pattern of
>>> messages between the parties.
>>>
>>> 3. The points and the number of ways by which an adversary may break
>>> into OAuth must therefore be finite.
>>>
>>> 4. The security requirement is essentially to guarantee the precedenc=
e
>>> and authenticity of the messages from discovery endpoint to RS, and t=
he
>>> preferred way to do that is by establishing a binding between the
>>> messages, which can be forward or backward binding.
>>>
>>>
>>> Right now the WG concern is whether all possible attacks have been
>>> recognised, and then taken care of. If we can have a formal model tha=
t
>>> can reliably reveal and prove that, this will be a huge breakthrough.=

>>>
>>> Cheers,
>>>
>>> Vladimir
>>>
>>>
>>>
>>> On 20/02/16 12:41, Mike Jones wrote:
>>>> Suggesting that they be read is of course, the right long-term
>> approach.  But as someone who spent 20+ years as a researcher before
>> switching to digital identity, I was sensitive to not wanting to upsta=
ge
>> their work by copying too much of their material into our draft before=

>> their publications were widely known.  I'll of course commit to workin=
g the
>> researchers and the working group to create a self-contained concise
>> description of the threats and mitigations in the working group docume=
nt.
>>>>                              Cheers,
>>>>                              -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>> To: Mike Jones ; William Denniss <
>> wdenniss@google.com>; Phil Hunt (IDM) 
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call=

>> for Adoption
>>>> Hi Mike,
>>>>
>>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>>> Have you read both of their publications?  If not, do yourself a fa=
vor
>>>>> and do.  They're actually both very readable and quite informative.=

>>>> I have read both documents. In context of this discussion the questi=
on
>> is whether we
>>>> (a) require them to be read (in which case they should be a normativ=
e
>> reference), or
>>>> (b) suggest them to be read (since they provide additional backgroun=
d
>> information). In this case they are an informative reference.
>>>> I believe believe we want (b) for the OAuth WG document. While I
>> encourage everyone to read the publications I also believe that there =
is
>> lots of material in there that goes beyond the information our audienc=
e
>> typically reads (such as the text about the formal analysis).
>>>> There is probably also a middle-ground where we either copy relevant=

>> text from the papers into the draft or reference specific sections tha=
t are
>> "must-read".
>>>> One other issue: I actually thought that the threat that is outlined=
 in
>> the research paper is sufficiently well described but the second threa=
t,
>> which is called 'cut-and-paste attack', requires more work.
>>>> I noted this in my summary mail to the list, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>



--------------ms000301010209030502030709
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjcxODE2MDdaMC8GCSqGSIb3DQEJBDEiBCB7rSBB9hSt186mah42vYgIEKqZqZSg
nOVVh8XLFJ3p+jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQAfK/mi6ViM
wIf7CnO4OcTEgTOOWuLtuJVTWVjG3omhF2KMOzxWSUP1G4F4lUyA8Y4GVvescZJsTLkXYntD
DYPshh9GwVkLS2yrpU1aC3Af6Euc6ZTF8AiBppe7hbUG8EhF7o8VeGL7W0qy5288niiVz29W
tSs5ndTnJWDu7bkHMl+Ar6b45sRjD7s1DhDmoqijdgvL+EA5Y/7Ml7LxyHrgQSW5zFi4LXNb
34Jp/Bv5t4jP7q6O0uWjcTOEPvmpcpL/ORu/ekDqrOtZIUKd27X/RqruKjN6z/mGv8F7SEnP
fa7GpHsS/tRWUyRe4CgIaD04eKChs1P3UWfWjWrOCkWFAAAAAAAA
--------------ms000301010209030502030709--


From nobody Sat Feb 27 10:32:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA891B2A06 for ; Sat, 27 Feb 2016 10:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owHQ6ljc_QGS for ; Sat, 27 Feb 2016 10:32:39 -0800 (PST)
Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013331B2A05 for ; Sat, 27 Feb 2016 10:32:38 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa11-01.prod.phx3.secureserver.net with  id PWYc1s00615ZTut01WYdl4; Sat, 27 Feb 2016 11:32:38 -0700
To: oauth@ietf.org
References:    <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>   
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56D1EBC4.4040907@connect2id.com>
Date: Sat, 27 Feb 2016 20:32:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090609010004000102040507"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 18:32:47 -0000

This is a cryptographically signed message in MIME format.

--------------ms090609010004000102040507
Content-Type: multipart/alternative;
 boundary="------------060005070105060002070009"

This is a multi-part message in MIME format.
--------------060005070105060002070009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On 27/02/16 20:10, Phil Hunt wrote:
> The name change seems appropriate given that the WG members have decide=
d not to address the issue of resource discovery as part of this specific=
ation.
>
> If the consensus is to limit the scope of the specification, then I sug=
gest the following security considerations text.
>
> Resource Discovery
>
> Secure discovery of resource endpoints is out-of-scope of this specific=
ation. This specification assumes that the client has already securely di=
scovered the correct resource endpoint and that the client has correctly =
selected the correct corresponding discovery for OAuth Authorization serv=
er. Implementers MUST consider that if an incorrect resource endpoint was=
 discovered by the client that an attacker will be able to set up a man-i=
n-the-middle proxy to a real resource server without detection by the aut=
horization server or the client.=20

I support that. This was the primary concern of everyone who felt
uncomfortable with the original draft with WebFinger-based discovery in
it, so it should be included.



> It may be more appropriate to even include this text in the introductio=
n as a cautionary "red flag" to implementers.
+1

>
> Once again, I strongly urge the WG to actually include a method for the=
 client to discovery that the oauth cliet has correctly discovered an aut=
horization server that is willing and able to issue access tokens for a g=
iven resource endpoint. I believe this relationship is critical to securi=
ty of OAuth in cases where resource endpoints are discovered dynamically.=
  Of course willing and able means that the AS believes that the endpoint=
 is legitimate.

The more I think about this topic, the more pessimistic I get that there
is a good solution to this :)

Vladimir


>
> Phil
>
> @independentid
> www.independentid.com phil.hunt@oracle.c=
om 
>
>
>
>
>
>> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman  wrote:=

>>
>> +1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
>>
>> //Samuel
>>
>> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones > wrote:
>> Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined=
 to accept your suggestion to change the title from =E2=80=9COAuth 2.0 Di=
scovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=
=9D.  While the abstract already makes it clear that the scope of the doc=
ument is AS discovery, doing so in the title seems like it could help cla=
rify things, given that a lot of the discussion seems to be about resourc=
e discovery, which is out of scope of the document.
>>
>> =20
>>
>> I=E2=80=99m not saying that resource discovery isn=E2=80=99t important=
 =E2=80=93 it is =E2=80=93 but unlike authorization server discovery, whe=
re there=E2=80=99s lots of existing practice, including using the existin=
g data format for describing OAuth implementations that aren=E2=80=99t be=
ing used with OpenID Connect, there=E2=80=99s no existing practice to sta=
ndardize for resource discovery.  The time to create a standard for that =
seems to be after existing practice has emerged.  It *might* or might not=
 use new metadata values in the AS discovery document, but that=E2=80=99s=
 still to be determined.  The one reason to leave the title as-is is that=
 resource discovery might end up involving extensions to this metadata fo=
rmat in some cases.
>>
>> =20
>>
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 a=
pplies.  6749 is about the AS.  6750 is about the RS.  The discovery docu=
ment is about the AS.  We don=E2=80=99t yet have a specification or exist=
ing practice for RS discovery, which would be the 6750 analogy.
>>
>> =20
>>
>> In summary, which title do people prefer?
>>
>> =C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
>>
>> =C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D=

>>
>> =20
>>
>>                                                           -- Mike
>>
>>   <>
>> From: OAuth [mailto:oauth-bounces@ietf.org ] On Behalf Of Vladimir Dzhuvinov
>> Sent: Thursday, February 25, 2016 12:59 AM
>> To: oauth@ietf.org 
>>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> =20
>>
>> In OIDC the discovery doc is of great utility to developers and integr=
ators. Developers also tend to find it a more accurate and complete descr=
iption of how to set up a client for a particular deployment, compared to=
 traditional online docs, which may be not be up to date, or even missing=
=2E Very much like auto-generated Swagger and JavaDocs.
>>
>> Here are some example OIDC discovery docs:
>>
>> https://accounts.google.com/.well-known/openid-configuration 
>>
>> https://www.paypalobjects.com/.well-known/openid-configuration 
>>
>> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.we=
ll-known/openid-configuration 
>>
>>
>> With this discovery document in place setup of identity federation can=
 then be easily scripted. For example:
>>
>> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_cre=
ate_oidc_verify-thumbprint.html 
>>
>>
>> Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one a=
rrives at the ".well-known/...". I'm not even sure that resource discover=
y should be a topic of this WG. Perhaps to this end, and to prevent confu=
sion that the spec is trying to do something more, a more specific title =
would suit it better. E.g. "AS Discovery".
>>
>> Cheers,
>>
>> Vladimir
>>
>>
>>
>>
>> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>>
>> And so does oracle and so does google. Each different.=20
>> =20
>> So how can an app dictate it then unless we all go to a common archite=
cture?
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 16:04, Mike Jones   wrote:
>> =20
>> Azure defines ways for resource servers to be registered for use with =
a client and for clients to dynamically request an access token for use a=
t a particular resource server.  You can call that custom architecture if=
 you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in t=
he standards realm.  I know that Google has syntax for doing the same, as=
 I=E2=80=99m sure do a lot of other cloud OAuth deployments, such as Orac=
le=E2=80=99s.  For what it=E2=80=99s worth, the working group talked abou=
t possibly producing a standard version of syntax for making these kinds =
of requests during our discussions in Prague (during the Token Exchange d=
iscussion) but nobody has run with this yet.
>> =20
>> In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 discover=
y metadata values that are used in production.  A registry just doesn=E2=80=
=99t yet exist in which it can register those that are of general applica=
bility.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com ]=20
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Mike
>> =20
>> Take a look at the assumptions you are making.=20
>> =20
>> You seem to be assuming application software dictates oauth infrastruc=
ture architecture by suggesting that apps register in iana. =20
>> =20
>> Would ms azure allow custom arch?
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 15:28, Mike Jones   wrote:
>> =20
>> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be discov=
ered.
>> =20
>> I agree that for some OAuth profiles, one or more resource servers wil=
l have to be discovered starting from the authorization server.  Working =
group members have also described wanting to discover authorization serve=
rs starting from resource servers.  There isn=E2=80=99t a standard practi=
ce for any of this, which is why it=E2=80=99s intentionally left out of t=
he current specification.
>> =20
>> Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it w=
ill be easy for subsequent specifications to document existing practice f=
or different OAuth profiles and register discovery metadata values suppor=
ting them.  Some of those values will likely define ways to discover reso=
urce servers, when applicable.
>> =20
>> But first, we need to finish the existing spec, so that the registry e=
nabling these extensions gets established in the first place.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com ]=20
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones  
>> Cc:    
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Yup. And because there many relations the client mist be able to disco=
ver it. The client does not know if the res server is legit.=20
>> =20
>> The userinfo is always fix and so u dont need discovery.=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 14:05, Mike Jones   wrote:
>> =20
>> In OpenID Connect, there=E2=80=99s a resource server called the UserIn=
fo Endpoint that returns claims about the authenticated user as a JSON da=
ta structure.  Its location is published in OpenID Connect discovery meta=
data as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is =
defined at http://openid.net/specs/openid-connect-discovery-1_0.html#Prov=
iderMetadata .
>> =20
>> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth d=
iscovery spec since in OAuth, there are lots of possible relationships be=
tween authorization servers and resource servers and they needn=E2=80=99t=
 be one-to-one, as is being actively discussed by the working group.  For=
 instance, see George Fletcher=E2=80=99s recent contribution.
>> =20
>> Thanks for the good discussion, Phil.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com ]=20
>> Sent: Wednesday, February 24, 2016 1:25 PM
>> To: Mike Jones
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Where is the profile endpoint (oidc's resource server) published? (For=
 the non OIDC people on the list).=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 13:09, Mike Jones   wrote:
>> =20
>> To the extent that generic OAuth 2.0 needs to publish some of the same=
 information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly th=
e same syntax, since that syntax is already in widespread use.  That what=
 this draft accomplishes.
>> =20
>> There=E2=80=99s nothing Connect-specific about using metadata response=
 values like:
>> =20
>>    "authorization_endpoint": "https://server.example.com/authorize" ,
>>    "token_endpoint": "https://server.example.com/token" ,
>>    "token_endpoint_auth_methods_supported": ["client_secret_basic", "p=
rivate_key_jwt"],
>>    "registration_endpoint": "https://server.example.com/register" ,
>>    "response_types_supported":  ["code", "token"],
>>    "service_documentation": "http://server.example.com/service_documen=
tation.html" ,
>> =20
>> Is there a reason that you would like the syntax for any of these or t=
he other generally applicable OAuth 2.0 metadata values to be different? =
 I don=E2=80=99t see any good reason for unnecessary differences to be in=
troduced.
>> =20
>>                                                                 -- Mik=
e
>> =20
>> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com ]=20
>> Sent: Wednesday, February 24, 2016 12:45 PM
>> To: Anthony Nadalin  
>> Cc: Mike Jones  ;    
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> Mike
>> =20
>> Publishing on dev pages does not work for software (esp open source) t=
hat is deployed both in enterprises and on PaaS cloud providers.=20
>> =20
>> The current draft is may codify current OIDC practice and be appropria=
te for oidc but it is not ready for generic oauth. There is no generic oa=
uth experience at this time.=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 10:25, Anthony Nadalin   wrote:
>> =20
>> Sure there is, it is as you have now made it far easier and the securi=
ty considerations does not even address this
>> =20
>> From: Mike Jones=20
>> Sent: Wednesday, February 24, 2016 10:22 AM
>> To: Anthony Nadalin  
>> Cc:    
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> As we=E2=80=99d discussed in person, there=E2=80=99s no effective secu=
rity difference between discovery information being published in an ad-ho=
c fashion on developer pages and it being published in a standard format.=
  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security at all.
>> =20
>>                                                           -- Mike
>> =20
>> From: Anthony Nadalin=20
>> Sent: Wednesday, February 24, 2016 10:01 AM
>> To: Mike Jones  ; Phil Hunt (IDM)  ; Nat Sakimura  
>> Cc:    
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> The point of the WGLC is to finish standardizing the core discovery fu=
nctionality that=E2=80=99s already widely deployed.
>> =20
>> That may be widely deployed for OIDC but not widely deployed for OAuth=
=2E There are some authentication mechanism discovery for endpoint that r=
eally should not be in an OAuth standard since it=E2=80=99s really not de=
alt with. Now that all this information is available it makes poking arou=
nd the endpoint more focused for people that want to disrupt your endpoin=
ts, that is really not addressed in the security considerations  section =
at all
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org ] On Behalf Of Mike Jones
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Phil Hunt (IDM)  ; Nat Sakimura  
>> Cc:    
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> The point of the WGLC is to finish standardizing the core discovery fu=
nctionality that=E2=80=99s already widely deployed.
>> =20
>> None of Nat or John or I are suggesting that additional related functi=
onality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some app=
lications will use WebFinger to locate the discovery metadata.  Some will=
 possibly use link headers.  Some will possibly use application-specific =
=2Ewell-known values.  I=E2=80=99m sure there=E2=80=99s other things I ha=
ven=E2=80=99t even thought about.  All of these depend upon having a disc=
overy metadata document format and none of them change it =E2=80=93 other=
 than possibly to register additional discovery metadata values.
>> =20
>> So by all means, the working group should continue discussing inventin=
g possible new related mechanisms that make sense in some contexts.  At t=
he same time, we can finish standardizing the already widely deployed cor=
e functionality that all of these mechanisms will need.
>> =20
>>                                                           -- Mike
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org ] On Behalf Of Phil Hunt (IDM)
>> Sent: Wednesday, February 24, 2016 8:39 AM
>> To: Nat Sakimura  
>> Cc:    
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> =20
>> I am suggesting that part of the discovery solution has to be the clie=
nt indicating what resource endpoint it wants the oauth configuration dat=
a for.=20
>> =20
>> So if res.example.evil.com  is not a val=
id resource endpoint for as.example.com  the auth=
z discovery should fail in some way (eg return nothing).=20
>> =20
>> There may be better ways to do this. Eg combine discovery. Or change t=
he order of discovery.=20
>> =20
>> One of OAuth's strength's and weaknesses is that the target of authori=
zation (the resource) is never specified. It is often bound up in the cli=
ent registration and an often implied 1:1 relationship between resource a=
nd as. Given that in discovery phase registration has not yet occurred it=
 seems important that the client know it has a valid combination of endpo=
ints etc.=20
>> =20
>> This is why I was disappointed about wglc on discovery. We had a start=
ing point for group adoption but we haven't really defined the full requi=
rements IMO.=20
>> =20
>> I am on vacation or I would put some thought into some draft changes o=
r a new draft. I apologize I can't do it now.=20
>> =20
>> Phil
>> =20
>> On Feb 24, 2016, at 08:12, Nat Sakimura   wrote:
>> =20
>> Hi Phil,=20
>> =20
>> Are you suggesting that the AS metadata should include the RS URIs? Cu=
rrently, it does not, but it can be done, I guess.=20
>> =20
>> The way oauth-meta works is that=20
>> =20
>> 1. RS tells the client where the AS is.=20
>> 2. AS tells the client which RS endpoints the token can be used.=20
>> =20
>> Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will say=
 that is not the place the client may want to send the token to.=20
>> =20
>> Nat
>> =20
>> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt  :
>> Nat,
>> =20
>> I=E2=80=99m not sure that having the resource server tell the client w=
here its authorization server is secure by itself. The relationship betwe=
en the Authorization Server and the Resource server need to be bound toge=
ther in one of the discovery endpoints (the resource and/or the oauth ser=
vice discovery).
>> =20
>> If a client discovers a fake resource server that is proxying for a re=
al resource server the current discovery spec will not lead the client to=
 understand it has the wrong resource server. Rather the fake resource se=
rvice will just have a fake discovery service. The hacker can now interce=
pt resource payload as well as tokens because they were able to convince =
the client to use the legit authorization service but use the token again=
st the hackers proxy.
>> =20
>> The OAuth Discovery service needs to confirm to the client that the se=
rver is able to issue tokens for a stated resource endpoint.
>> =20
>> This not only works in normal OAuth but should add security even to UM=
A situations.
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>> =20
>> =20
>> =20
>> =20
>> =20
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura   wrote:
>> =20
>> =20
>> Hi Thomas,=20
>> =20
>> inline:=20
>> =20
>> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer  :
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to de=
fine a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any UR=
L, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basi=
s for other metadata specs (like OpenID Connect).=20
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of W=
WW-Authenticate response header, you have everything you need to proceed =

>> =20
>> Yup. That's one of the requirements to be RESTful, is it not? =20
>> =20
>> In OAuth's case, the resource and the authorization server are usually=
 tightly coupled. (Otherwise, you need another specs like UMA.)=20
>> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as well=
 return the location of the authz server configuration data. In these cas=
es, you do not have to decide on what .well-known uri as you say. This fr=
ees up developers from configuration file location collisions etc. We sho=
uld strive not to pollute the uri space as much as possible.=20
>> =20
>> (well, except if there are several ASs each with different scopes; sou=
nds like an edge-case to me though; maybe RFC6750 should instead be updat=
ed with such a parameter such that an RS could return several WWW-Authent=
icate: Bearer, each with its own "scope" and "duri" value?)
>> =20
>> Yeah, I guess it is an edge case. I would rather like to see these aut=
hz servers to develop a trust framework under which they can agree on a s=
ingle set of common scope parameter values.=20
>> =20
>> Cheers,=20
>> =20
>> Nat
>> =20
>> =20
>> =20
>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer   wrote:
>> The newly-trimmed OAuth Discovery document is helpful and moving in th=
e right direction. It does, however, still have too many vestiges of its =
OpenID Connect origins. One issue in particular still really bothers me: =
the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the dis=
covery portion. Is this an OAuth discovery document, or an OpenID Connect=
 one? There is absolutely no compelling reason to tie the URL to the OIDC=
 discovery mechanism.
>> =20
>> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth endpoi=
nts and functions inside their service-specific discovery document.
>> =20
>>  =E2=80=94 Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> =20
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>>
>>
>> --=20
>> Vladimir Dzhuvinov :: vladimir@connect2id.com 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------060005070105060002070009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    

    

    
On 27/02/16 20:10, Phil Hunt wrote:
    

    

      
The name change seems appropriate given that the WG =
members have decided not to address the issue of resource discovery as pa=
rt of this specification.

If the consensus is to limit the scope of the specification, then I sugge=
st the following security considerations text.

Resource Discovery

Secure discovery of resource endpoints is out-of-scope of this specificat=
ion. This specification assumes that the client has already securely disc=
overed the correct resource endpoint and that the client has correctly se=
lected the correct corresponding discovery for OAuth Authorization server=
=2E Implementers MUST consider that if an incorrect resource endpoint was=
 discovered by the client that an attacker will be able to set up a man-i=
n-the-middle proxy to a real resource server without detection by the aut=
horization server or the client.=20


    

    

    I support that. This was the primary concern of everyone who felt
    uncomfortable with the original draft with WebFinger-based discovery
    in it, so it should be included.

    

    

    

    

      
It may be more appropriate to even include this text in the introduction =
as a cautionary "red flag" to implementers.

    

    +1

    

    

      

Once again, I strongly urge the WG to actually include a method for the c=
lient to discovery that the oauth cliet has correctly discovered an autho=
rization server that is willing and able to issue access tokens for a giv=
en resource endpoint. I believe this relationship is critical to security=
 of OAuth in cases where resource endpoints are discovered dynamically.  =
Of course willing and able means that the AS believes that the endpoint i=
s legitimate.

    

    

    The more I think about this topic, the more pessimistic I get that
    there is a good solution to this :)

    

    Vladimir

    

    

    

      

Phil

@independentid
www.independentid.com <http://www.independentid.com/>=
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>







      

        
On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <samuel=
@erdtman.se> wrote:

+1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <Michael.Jones@mi=
crosoft.com <mailto:Michael.Jones@microsoft.com>>=
; wrote:
Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined to=
 accept your suggestion to change the title from =E2=80=9COAuth 2.0 Disco=
very=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D=
=2E  While the abstract already makes it clear that the scope of the docu=
ment is AS discovery, doing so in the title seems like it could help clar=
ify things, given that a lot of the discussion seems to be about resource=
 discovery, which is out of scope of the document.

=20

I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =E2=
=80=93 it is =E2=80=93 but unlike authorization server discovery, where t=
here=E2=80=99s lots of existing practice, including using the existing da=
ta format for describing OAuth implementations that aren=E2=80=99t being =
used with OpenID Connect, there=E2=80=99s no existing practice to standar=
dize for resource discovery.  The time to create a standard for that seem=
s to be after existing practice has emerged.  It *might* or might not use=
 new metadata values in the AS discovery document, but that=E2=80=99s sti=
ll to be determined.  The one reason to leave the title as-is is that res=
ource discovery might end up involving extensions to this metadata format=
 in some cases.

=20

I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 appl=
ies.  6749 is about the AS.  6750 is about the RS.  The discovery documen=
t is about the AS.  We don=E2=80=99t yet have a specification or existing=
 practice for RS discovery, which would be the 6750 analogy.

=20

In summary, which title do people prefer?

=C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D

=C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D

=20

                                                          -- Mike

=C2=A0 <>
From: OAuth [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces=
@ietf.org>] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: =
oauth@ietf.org <mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

=20

In OIDC the discovery doc is of great utility to developers and integrato=
rs. Developers also tend to find it a more accurate and complete descript=
ion of how to set up a client for a particular deployment, compared to tr=
aditional online docs, which may be not be up to date, or even missing. V=
ery much like auto-generated Swagger and JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/o=
penid-configuration <https://accou=
nts.google.com/.well-known/openid-configuration>

https://www.paypalobjects.com/.well-k=
nown/openid-configuration <https=
://www.paypalobjects.com/.well-known/openid-configuration>

ht=
tps://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-kn=
own/openid-configuration <https://login.microsoftonline.com/fabrikam=
b2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>


With this discovery document in place setup of identity federation can th=
en be easily scripted. For example:

=
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create=
_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/=
UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>


Now, does that dictate any particular app architecture? My reading of the=
 spec is that it doesn't, and it shouldn't either. By staying neutral on =
the topics of RS discovery and registering RPs with RSs. And how one arri=
ves at the ".well-known/...". I'm not even sure that resource discovery s=
hould be a topic of this WG. Perhaps to this end, and to prevent confusio=
n that the spec is trying to do something more, a more specific title wou=
ld suit it better. E.g. "AS Discovery".

Cheers,

Vladimir




On 25/02/16 02:25, Phil Hunt (IDM) wrote:

And so does oracle and so does google. Each different.=20
=20
So how can an app dictate it then unless we all go to a common architectu=
re?
=20
Phil
=20
On Feb 24, 2016, at 16:04, Mike Jones <Michael.Jones@microsoft.c=
om> <mailto:Michael.Jones@microsoft.com> wrote:
=20
Azure defines ways for resource servers to be registered for use with a c=
lient and for clients to dynamically request an access token for use at a=
 particular resource server.  You can call that custom architecture if yo=
u want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in the =
standards realm.  I know that Google has syntax for doing the same, as I=E2=
=80=99m sure do a lot of other cloud OAuth deployments, such as Oracle=E2=
=80=99s.  For what it=E2=80=99s worth, the working group talked about pos=
sibly producing a standard version of syntax for making these kinds of re=
quests during our discussions in Prague (during the Token Exchange discus=
sion) but nobody has run with this yet.
=20
In this sense, yes, Azure is an application of the kind we=E2=80=99re tal=
king about.  Azure already does define specific new OAuth 2.0 discovery m=
etadata values that are used in production.  A registry just doesn=E2=80=99=
t yet exist in which it can register those that are of general applicabil=
ity.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com <mailto:phil.hunt=
@oracle.com>]=20
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Mike
=20
Take a look at the assumptions you are making.=20
=20
You seem to be assuming application software dictates oauth infrastructur=
e architecture by suggesting that apps register in iana. =20
=20
Would ms azure allow custom arch?
=20
Phil
=20
On Feb 24, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.c=
om> <mailto:Michael.Jones@microsoft.com> wrote:
=20
The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be discovere=
d.
=20
I agree that for some OAuth profiles, one or more resource servers will h=
ave to be discovered starting from the authorization server.  Working gro=
up members have also described wanting to discover authorization servers =
starting from resource servers.  There isn=E2=80=99t a standard practice =
for any of this, which is why it=E2=80=99s intentionally left out of the =
current specification.
=20
Once the IANA OAuth Discovery Metadata Registry has been established, whi=
ch will happen after the current specification has been approved, it will=
 be easy for subsequent specifications to document existing practice for =
different OAuth profiles and register discovery metadata values supportin=
g them.  Some of those values will likely define ways to discover resourc=
e servers, when applicable.
=20
But first, we need to finish the existing spec, so that the registry enab=
ling these extensions gets established in the first place.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com <mailto:phil.hunt=
@oracle.com>]=20
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones <Michael.Jones@microsoft.com> <ma=
ilto:Michael.Jones@microsoft.com>
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailt=
o:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Yup. And because there many relations the client mist be able to discover=
 it. The client does not know if the res server is legit.=20
=20
The userinfo is always fix and so u dont need discovery.=20
=20
Phil
=20
On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.c=
om> <mailto:Michael.Jones@microsoft.com> wrote:
=20
In OpenID Connect, there=E2=80=99s a resource server called the UserInfo =
Endpoint that returns claims about the authenticated user as a JSON data =
structure.  Its location is published in OpenID Connect discovery metadat=
a as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, which is def=
ined at http://openid.net/s=
pecs/openid-connect-discovery-1_0.html#ProviderMetadata <http://openid.net/specs/openid-conne=
ct-discovery-1_0.html#ProviderMetadata>.
=20
We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth disc=
overy spec since in OAuth, there are lots of possible relationships betwe=
en authorization servers and resource servers and they needn=E2=80=99t be=
 one-to-one, as is being actively discussed by the working group.  For in=
stance, see George Fletcher=E2=80=99s recent contribution.
=20
Thanks for the good discussion, Phil.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com <mailto:phil.hunt=
@oracle.com>]=20
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Where is the profile endpoint (oidc's resource server) published? (For th=
e non OIDC people on the list).=20
=20
Phil
=20
On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.c=
om> <mailto:Michael.Jones@microsoft.com> wrote:
=20
To the extent that generic OAuth 2.0 needs to publish some of the same in=
formation as OpenID Connect =E2=80=93 which is built on generic OAuth 2.0=
 =E2=80=93 it makes sense to publish that information using exactly the s=
ame syntax, since that syntax is already in widespread use.  That what th=
is draft accomplishes.
=20
There=E2=80=99s nothing Connect-specific about using metadata response va=
lues like:
=20
   "authorization_endpoint": "https://server.example.com/authoriz=
e" <https://server.example.com/authorize>,
   "token_endpoint": "https://server.example.com/token" <htt=
ps://server.example.com/token>,
   "token_endpoint_auth_methods_supported": ["client_secret_basic", "priv=
ate_key_jwt"],
   "registration_endpoint": "https://server.example.com/register"<=
/a> <https://server.example.com/register>,
   "response_types_supported":  ["code", "token"],
   "service_documentation": "http://server.exampl=
e.com/service_documentation.html" <http://=
server.example.com/service_documentation.html>,
=20
Is there a reason that you would like the syntax for any of these or the =
other generally applicable OAuth 2.0 metadata values to be different?  I =
don=E2=80=99t see any good reason for unnecessary differences to be intro=
duced.
=20
                                                                -- Mike
=20
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com <mailto:phil.hunt=
@oracle.com>]=20
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <tonynad@microsoft.com> <mailto:tonynad@=
microsoft.com>
Cc: Mike Jones <Michael.Jones@microsoft.com> <ma=
ilto:Michael.Jones@microsoft.com>; <oauth@ietf.org> <mailto:oauth@i=
etf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
Mike
=20
Publishing on dev pages does not work for software (esp open source) that=
 is deployed both in enterprises and on PaaS cloud providers.=20
=20
The current draft is may codify current OIDC practice and be appropriate =
for oidc but it is not ready for generic oauth. There is no generic oauth=
 experience at this time.=20
=20
Phil
=20
On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com><=
/a> <mailto:tonynad@microsoft.com> wrote:
=20
Sure there is, it is as you have now made it far easier and the security =
considerations does not even address this
=20
From: Mike Jones=20
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <tonynad@microsoft.com> <mailto:tonynad@=
microsoft.com>
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailt=
o:oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
As we=E2=80=99d discussed in person, there=E2=80=99s no effective securit=
y difference between discovery information being published in an ad-hoc f=
ashion on developer pages and it being published in a standard format.  =E2=
=80=9CSecurity by obscurity=E2=80=9D adds no real security at all.
=20
                                                          -- Mike
=20
From: Anthony Nadalin=20
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones <Michael.Jones@microsoft.com> <ma=
ilto:Michael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@or=
acle.com> <mailto:phil.hunt@oracle.com>; Nat Sakimura <sa=
kimura@gmail.com> <mailto:sakimura@gmail.com>
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailt=
o:oauth@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
The point of the WGLC is to finish standardizing the core discovery funct=
ionality that=E2=80=99s already widely deployed.
=20
That may be widely deployed for OIDC but not widely deployed for OAuth. T=
here are some authentication mechanism discovery for endpoint that really=
 should not be in an OAuth standard since it=E2=80=99s really not dealt w=
ith. Now that all this information is available it makes poking around th=
e endpoint more focused for people that want to disrupt your endpoints, t=
hat is really not addressed in the security considerations  section at al=
l
=20
From: OAuth [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces=
@ietf.org>] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com> <mailto:phil.hunt@o=
racle.com>; Nat Sakimura <sakimura@gmail.com> <mailto:sakimu=
ra@gmail.com>
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailt=
o:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
The point of the WGLC is to finish standardizing the core discovery funct=
ionality that=E2=80=99s already widely deployed.
=20
None of Nat or John or I are suggesting that additional related functiona=
lity won=E2=80=99t be created.  I=E2=80=99m sure it will be.  Some applic=
ations will use WebFinger to locate the discovery metadata.  Some will po=
ssibly use link headers.  Some will possibly use application-specific .we=
ll-known values.  I=E2=80=99m sure there=E2=80=99s other things I haven=E2=
=80=99t even thought about.  All of these depend upon having a discovery =
metadata document format and none of them change it =E2=80=93 other than =
possibly to register additional discovery metadata values.
=20
So by all means, the working group should continue discussing inventing p=
ossible new related mechanisms that make sense in some contexts.  At the =
same time, we can finish standardizing the already widely deployed core f=
unctionality that all of these mechanisms will need.
=20
                                                          -- Mike
=20
From: OAuth [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces=
@ietf.org>] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <sakimura@gmail.com> <mailto:sakimura@gmail.com&g=
t;
Cc: <=
;oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailt=
o:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
=20
I am suggesting that part of the discovery solution has to be the client =
indicating what resource endpoint it wants the oauth configuration data f=
or.=20
=20
So if res.example.evil.com <http://res.example.evil.com/> is no=
t a valid resource endpoint for as.example.com <http://as.example.com/> the authz discovery should fail in some way (eg return nothing).=20
=20
There may be better ways to do this. Eg combine discovery. Or change the =
order of discovery.=20
=20
One of OAuth's strength's and weaknesses is that the target of authorizat=
ion (the resource) is never specified. It is often bound up in the client=
 registration and an often implied 1:1 relationship between resource and =
as. Given that in discovery phase registration has not yet occurred it se=
ems important that the client know it has a valid combination of endpoint=
s etc.=20
=20
This is why I was disappointed about wglc on discovery. We had a starting=
 point for group adoption but we haven't really defined the full requirem=
ents IMO.=20
=20
I am on vacation or I would put some thought into some draft changes or a=
 new draft. I apologize I can't do it now.=20
=20
Phil
=20
On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> <mail=
to:sakimura@gmail.com> wrote:
=20
Hi Phil,=20
=20
Are you suggesting that the AS metadata should include the RS URIs? Curre=
ntly, it does not, but it can be done, I guess.=20
=20
The way oauth-meta works is that=20
=20
1. RS tells the client where the AS is.=20
2. AS tells the client which RS endpoints the token can be used.=20
=20
Even if there is a bad AS with a valid certs that proxies to the good RS,=
 the client will not send the token there as the authz server will say th=
at is not the place the client may want to send the token to.=20
=20
Nat
=20
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hun=
t@oracle.com> <mailto:phil.hunt@oracle.com>:
Nat,
=20
I=E2=80=99m not sure that having the resource server tell the client wher=
e its authorization server is secure by itself. The relationship between =
the Authorization Server and the Resource server need to be bound togethe=
r in one of the discovery endpoints (the resource and/or the oauth servic=
e discovery).
=20
If a client discovers a fake resource server that is proxying for a real =
resource server the current discovery spec will not lead the client to un=
derstand it has the wrong resource server. Rather the fake resource servi=
ce will just have a fake discovery service. The hacker can now intercept =
resource payload as well as tokens because they were able to convince the=
 client to use the legit authorization service but use the token against =
the hackers proxy.
=20
The OAuth Discovery service needs to confirm to the client that the serve=
r is able to issue tokens for a stated resource endpoint.
=20
This not only works in normal OAuth but should add security even to UMA s=
ituations.
=20
Phil
=20
@independentid
www.independentid.com <http://www.independentid.com/>
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
=20
=20
=20
=20
=20
On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> <ma=
ilto:sakimura@gmail.com> wrote:
=20
=20
Hi Thomas,=20
=20
inline:=20
=20
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broy=
er@gmail.com> <mailto:t.broyer@gmail.com>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to =
do discovery, and leave it open to implementers / to other specs to defin=
e a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, =
returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis f=
or other metadata specs (like OpenID Connect).=20
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-=
Authenticate response header, you have everything you need to proceed=20
=20
Yup. That's one of the requirements to be RESTful, is it not? =20
=20
In OAuth's case, the resource and the authorization server are usually ti=
ghtly coupled. (Otherwise, you need another specs like UMA.)=20
So, the resource server should be able to tell either the location of the=
 authz endpoint. In some trusted environment, the resource may as well re=
turn the location of the authz server configuration data. In these cases,=
 you do not have to decide on what .well-known uri as you say. This frees=
 up developers from configuration file location collisions etc. We should=
 strive not to pollute the uri space as much as possible.=20
=20
(well, except if there are several ASs each with different scopes; sounds=
 like an edge-case to me though; maybe RFC6750 should instead be updated =
with such a parameter such that an RS could return several WWW-Authentica=
te: Bearer, each with its own "scope" and "duri" value?)
=20
Yeah, I guess it is an edge case. I would rather like to see these authz =
servers to develop a trust framework under which they can agree on a sing=
le set of common scope parameter values.=20
=20
Cheers,=20
=20
Nat
=20
=20
=20
On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> <mailto=
:jricher@mit.edu> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the r=
ight direction. It does, however, still have too many vestiges of its Ope=
nID Connect origins. One issue in particular still really bothers me: the=
 use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discov=
ery portion. Is this an OAuth discovery document, or an OpenID Connect on=
e? There is absolutely no compelling reason to tie the URL to the OIDC di=
scovery mechanism.
=20
I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document MAY=
 also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D=
 if the server also provides OpenID Connect on the same domain. Other app=
lications SHOULD use the same parameter names to describe OAuth endpoints=
 and functions inside their service-specific discovery document.
=20
 =E2=80=94 Justin
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
=20
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
=20




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


--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com <mailto:vladi=
mir@connect2id.com>
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>


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


      

      



      

      

      

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


    

    

    

  


--------------060005070105060002070009--

--------------ms090609010004000102040507
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjcxODMyMzZaMC8GCSqGSIb3DQEJBDEiBCCZpQiRzhQYTNJLwDT+PU+ujDkuK9Ti
P57+Z5LakuajVTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQB2IgdyJn44
ZZR6xPi9PbIPbHmaT3p+37lToGkPLPsWG5aenkRuUiA5bmfpFk6yOJDdoeR6FmPJLI3EHewL
h+cFQwUhzXHJnh1D9d3EmvtMI3f/9I3vjLJsx357BqCe5ItND2ot1Hh3O9gjIvu9G6XqFHtS
r8P1lcSQmCngvpShMeMQSlr9lXzekTUDMuyTG/rdkVHTIpU8o8RK4ogZVeFoTSqf/dI2bHJC
/G/87LGP0E4x8YsjCnv+U7c+WYsj+vxrWWmRzBmZs4nlguBYnLAU61Pw0O4TP7PTU0EfSqZj
TqP0aWYHqvAOPvIeXRIWQTdfQD4pxVraXxZh5yyihBx5AAAAAAAA
--------------ms090609010004000102040507--


From nobody Sat Feb 27 10:38:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E29A1B2A50 for ; Sat, 27 Feb 2016 10:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnAd3DGT3524 for ; Sat, 27 Feb 2016 10:38:18 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C78E1B2A4D for ; Sat, 27 Feb 2016 10:38:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C3fZUEzi73XS7Ad26EthDRY/UUeqIzPXTD5BaTrrLT4=; b=P+1mpHai6ZFT8idNZabzUHXqm/lHSp+lt665+5UMSkNKqGgef0Sms0JlVCeiSu3VdeckjSQIjQuM+mbYS95KER+hG47qWx7Q2kY2gZvzQbQc2WUSvUp0kPQshLMf2fKcEQ9Jeiez12470jq7yvwRs5VXHaZ+hQIOWQwu8rB0QAo=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 27 Feb 2016 18:38:13 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Sat, 27 Feb 2016 18:38:13 +0000
From: Mike Jones 
To: Vladimir Dzhuvinov , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKwgAAD14CAABMcsIAACLCAgAAAzOCAAAh3AIAAj3QAgACntWCAAt4rAIAAONyAgAAGOgCAAABGEA==
Date: Sat, 27 Feb 2016 18:38:13 +0000
Message-ID: 
References:    <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>    <56D1EBC4.4040907@connect2id.com>
In-Reply-To: <56D1EBC4.4040907@connect2id.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: connect2id.com; dkim=none (message not signed) header.d=none;connect2id.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: 43f03e7d-8bff-44fa-de99-08d33fa52689
x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:NWFyOyjwLd1ck60+k1/yJvKwbCEjubi1XwD1rcs/zf8sj+0RtZ7rzV+c3sk8mDDa1qVvuRqs3Rw9EsGpIp2Pny4woXfT7d1VTzafEGJ1njkP8gDqWWGn9VROWqUxncZp1u/a3S14xpwvaeQx06lAVA==; 24:5IsVJOUzI8ZMdbfZxwp24K6TirGHNnThtuQTW7keQD8plRMcOYjDiNHJ+hUAmWF8jm+zS/JRd9ehX/wP2PAEeN7aWJ91vw9FIZeLdVUHfOs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(169139582196971);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(479174004)(51914003)(24454002)(52604005)(76576001)(87936001)(122556002)(10090500001)(93886004)(76176999)(50986999)(3660700001)(54356999)(189998001)(86362001)(11100500001)(106116001)(19580405001)(99286002)(19617315012)(10400500002)(10290500002)(66066001)(74316001)(5004730100002)(790700001)(586003)(5008740100001)(15395725005)(16236675004)(6116002)(92566002)(102836003)(1220700001)(19625215002)(33656002)(1096002)(3846002)(2900100001)(5003600100002)(3280700002)(107886002)(5001960100002)(40100003)(1680700002)(15975445007)(5001770100001)(3900700001)(2501003)(19300405004)(16601075003)(2950100001)(5002640100001)(2906002)(5005710100001)(19580395003)(77096005)(579004)(184035003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4428901D4BA97135B5AAF47F5B80BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2016 18:38:13.6063 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 18:38:28 -0000

--_000_BY2PR03MB4428901D4BA97135B5AAF47F5B80BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcHJvcG9zZSBzcGVjaWZpYyB0ZXh0LCBQaGls
LiAgVGhhdOKAmXMgcmVhbGx5IGhlbHBmdWwuICBJ4oCZbGwgcGxhbiB0byBpbmNvcnBvcmF0ZSBh
IHZlcnNpb24gb2YgdGhpcyBpbiB0aGUgZHJhZnQgYWRkcmVzc2luZyBXR0xDIGNvbW1lbnRzLg0K
DQpJIGFncmVlIHdpdGggVmxhZGltaXLigJlzIG9ic2VydmF0aW9uIHRoYXQgaXTigJlzIGRpZmZp
Y3VsdCB0byBjb21lIHVwIHdpdGggYSBnZW5lcmFsLXB1cnBvc2UgcmVzb3VyY2UgZGlzY292ZXJ5
IG1lY2hhbmlzbS4gIFRoYXQgaW4gcGFydCwgaXMgYmVjYXVzZSwgYXMgQnJpYW4gcG9pbnRzIG91
dCwgdGhlcmXigJlzIG9mdGVuIG5vdCBhIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhdXRob3Jp
emF0aW9uIHNlcnZlcnMgYW5kIHJlc291cmNlIHNlcnZlcnMuICBBcyBJ4oCZdmUgd3JpdHRlbiBi
ZWZvcmUsIEkgZG8gZW5jb3VyYWdlIHRoZSB3b3JraW5nIGdyb3VwIHRvIHdvcmsgb24gY3JlYXRp
bmcgc29sdXRpb25zIHRvIHJlc291cmNlIGRpc2NvdmVyeSB0aGF0IHdpbGwgd29yayBmb3Igc29t
ZSBjb21tb24gdXNlIGNhc2VzLiAgQnV0IHRoZSBnb29kIG5ld3MgaXMgdGhhdCB3aGlsZSByZXNv
dXJjZSBkaXNjb3ZlcnkgcmVxdWlyZXMgbmV3IGludmVudGlvbiwgYXV0aG9yaXphdGlvbiBzZXJ2
ZXIgZGlzY292ZXJ5IGRvZXMgbm90Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86
b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZsYWRpbWlyIER6aHV2aW5vdg0K
U2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDI3LCAyMDE2IDEwOjMzIEFNDQpUbzogb2F1dGhAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRp
b24NCg0KDQpPbiAyNy8wMi8xNiAyMDoxMCwgUGhpbCBIdW50IHdyb3RlOg0KDQpUaGUgbmFtZSBj
aGFuZ2Ugc2VlbXMgYXBwcm9wcmlhdGUgZ2l2ZW4gdGhhdCB0aGUgV0cgbWVtYmVycyBoYXZlIGRl
Y2lkZWQgbm90IHRvIGFkZHJlc3MgdGhlIGlzc3VlIG9mIHJlc291cmNlIGRpc2NvdmVyeSBhcyBw
YXJ0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KDQoNCklmIHRoZSBjb25zZW5zdXMgaXMgdG8g
bGltaXQgdGhlIHNjb3BlIG9mIHRoZSBzcGVjaWZpY2F0aW9uLCB0aGVuIEkgc3VnZ2VzdCB0aGUg
Zm9sbG93aW5nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQuDQoNCg0KDQpSZXNvdXJjZSBE
aXNjb3ZlcnkNCg0KDQoNClNlY3VyZSBkaXNjb3Zlcnkgb2YgcmVzb3VyY2UgZW5kcG9pbnRzIGlz
IG91dC1vZi1zY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uIFRoaXMgc3BlY2lmaWNhdGlvbiBh
c3N1bWVzIHRoYXQgdGhlIGNsaWVudCBoYXMgYWxyZWFkeSBzZWN1cmVseSBkaXNjb3ZlcmVkIHRo
ZSBjb3JyZWN0IHJlc291cmNlIGVuZHBvaW50IGFuZCB0aGF0IHRoZSBjbGllbnQgaGFzIGNvcnJl
Y3RseSBzZWxlY3RlZCB0aGUgY29ycmVjdCBjb3JyZXNwb25kaW5nIGRpc2NvdmVyeSBmb3IgT0F1
dGggQXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEltcGxlbWVudGVycyBNVVNUIGNvbnNpZGVyIHRoYXQg
aWYgYW4gaW5jb3JyZWN0IHJlc291cmNlIGVuZHBvaW50IHdhcyBkaXNjb3ZlcmVkIGJ5IHRoZSBj
bGllbnQgdGhhdCBhbiBhdHRhY2tlciB3aWxsIGJlIGFibGUgdG8gc2V0IHVwIGEgbWFuLWluLXRo
ZS1taWRkbGUgcHJveHkgdG8gYSByZWFsIHJlc291cmNlIHNlcnZlciB3aXRob3V0IGRldGVjdGlv
biBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgb3IgdGhlIGNsaWVudC4NCg0KSSBzdXBwb3J0
IHRoYXQuIFRoaXMgd2FzIHRoZSBwcmltYXJ5IGNvbmNlcm4gb2YgZXZlcnlvbmUgd2hvIGZlbHQg
dW5jb21mb3J0YWJsZSB3aXRoIHRoZSBvcmlnaW5hbCBkcmFmdCB3aXRoIFdlYkZpbmdlci1iYXNl
ZCBkaXNjb3ZlcnkgaW4gaXQsIHNvIGl0IHNob3VsZCBiZSBpbmNsdWRlZC4NCg0KDQoNCg0KDQoN
Cg0KSXQgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gZXZlbiBpbmNsdWRlIHRoaXMgdGV4dCBp
biB0aGUgaW50cm9kdWN0aW9uIGFzIGEgY2F1dGlvbmFyeSAicmVkIGZsYWciIHRvIGltcGxlbWVu
dGVycy4NCisxDQoNCg0KDQoNCg0KDQoNCk9uY2UgYWdhaW4sIEkgc3Ryb25nbHkgdXJnZSB0aGUg
V0cgdG8gYWN0dWFsbHkgaW5jbHVkZSBhIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBkaXNjb3Zl
cnkgdGhhdCB0aGUgb2F1dGggY2xpZXQgaGFzIGNvcnJlY3RseSBkaXNjb3ZlcmVkIGFuIGF1dGhv
cml6YXRpb24gc2VydmVyIHRoYXQgaXMgd2lsbGluZyBhbmQgYWJsZSB0byBpc3N1ZSBhY2Nlc3Mg
dG9rZW5zIGZvciBhIGdpdmVuIHJlc291cmNlIGVuZHBvaW50LiBJIGJlbGlldmUgdGhpcyByZWxh
dGlvbnNoaXAgaXMgY3JpdGljYWwgdG8gc2VjdXJpdHkgb2YgT0F1dGggaW4gY2FzZXMgd2hlcmUg
cmVzb3VyY2UgZW5kcG9pbnRzIGFyZSBkaXNjb3ZlcmVkIGR5bmFtaWNhbGx5LiAgT2YgY291cnNl
IHdpbGxpbmcgYW5kIGFibGUgbWVhbnMgdGhhdCB0aGUgQVMgYmVsaWV2ZXMgdGhhdCB0aGUgZW5k
cG9pbnQgaXMgbGVnaXRpbWF0ZS4NCg0KVGhlIG1vcmUgSSB0aGluayBhYm91dCB0aGlzIHRvcGlj
LCB0aGUgbW9yZSBwZXNzaW1pc3RpYyBJIGdldCB0aGF0IHRoZXJlIGlzIGEgZ29vZCBzb2x1dGlv
biB0byB0aGlzIDopDQoNClZsYWRpbWlyDQoNCg0KDQoNCg0KDQoNCg0KUGhpbA0KDQoNCg0KQGlu
ZGVwZW5kZW50aWQNCg0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRl
bnRpZC5jb20+IDxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz48aHR0cDovL3d3dy5pbmRl
cGVuZGVudGlkLmNvbS8+cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj
bGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gRmViIDI3LCAyMDE2LCBhdCA2OjQ2
IEFNLCBTYW11ZWwgRXJkdG1hbiA8c2FtdWVsQGVyZHRtYW4uc2U+PG1haWx0bzpzYW11ZWxAZXJk
dG1hbi5zZT4gd3JvdGU6DQoNCg0KDQorMSBmb3Ig4oCcT0F1dGggMi4wIEF1dGhvcml6YXRpb24g
U2VydmVyIERpc2NvdmVyeeKAnQ0KDQoNCg0KLy9TYW11ZWwNCg0KDQoNCk9uIFRodSwgRmViIDI1
LCAyMDE2IGF0IDg6MTAgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiA8bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy
b3RlOg0KDQpUaGFua3MgZm9yIHlvdXIgdGhvdWdodHMsIFZsYWRpbWlyLiAgSeKAmW0gaW5jcmVh
c2luZ2x5IGluY2xpbmVkIHRvIGFjY2VwdCB5b3VyIHN1Z2dlc3Rpb24gdG8gY2hhbmdlIHRoZSB0
aXRsZSBmcm9tIOKAnE9BdXRoIDIuMCBEaXNjb3ZlcnnigJ0gdG8g4oCcT0F1dGggMi4wIEF1dGhv
cml6YXRpb24gU2VydmVyIERpc2NvdmVyeeKAnS4gIFdoaWxlIHRoZSBhYnN0cmFjdCBhbHJlYWR5
IG1ha2VzIGl0IGNsZWFyIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCBpcyBBUyBkaXNj
b3ZlcnksIGRvaW5nIHNvIGluIHRoZSB0aXRsZSBzZWVtcyBsaWtlIGl0IGNvdWxkIGhlbHAgY2xh
cmlmeSB0aGluZ3MsIGdpdmVuIHRoYXQgYSBsb3Qgb2YgdGhlIGRpc2N1c3Npb24gc2VlbXMgdG8g
YmUgYWJvdXQgcmVzb3VyY2UgZGlzY292ZXJ5LCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhl
IGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQpJ4oCZbSBub3Qgc2F5aW5nIHRoYXQgcmVzb3VyY2Ug
ZGlzY292ZXJ5IGlzbuKAmXQgaW1wb3J0YW50IOKAkyBpdCBpcyDigJMgYnV0IHVubGlrZSBhdXRo
b3JpemF0aW9uIHNlcnZlciBkaXNjb3ZlcnksIHdoZXJlIHRoZXJl4oCZcyBsb3RzIG9mIGV4aXN0
aW5nIHByYWN0aWNlLCBpbmNsdWRpbmcgdXNpbmcgdGhlIGV4aXN0aW5nIGRhdGEgZm9ybWF0IGZv
ciBkZXNjcmliaW5nIE9BdXRoIGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZW7igJl0IGJlaW5nIHVz
ZWQgd2l0aCBPcGVuSUQgQ29ubmVjdCwgdGhlcmXigJlzIG5vIGV4aXN0aW5nIHByYWN0aWNlIHRv
IHN0YW5kYXJkaXplIGZvciByZXNvdXJjZSBkaXNjb3ZlcnkuICBUaGUgdGltZSB0byBjcmVhdGUg
YSBzdGFuZGFyZCBmb3IgdGhhdCBzZWVtcyB0byBiZSBhZnRlciBleGlzdGluZyBwcmFjdGljZSBo
YXMgZW1lcmdlZC4gIEl0ICptaWdodCogb3IgbWlnaHQgbm90IHVzZSBuZXcgbWV0YWRhdGEgdmFs
dWVzIGluIHRoZSBBUyBkaXNjb3ZlcnkgZG9jdW1lbnQsIGJ1dCB0aGF04oCZcyBzdGlsbCB0byBi
ZSBkZXRlcm1pbmVkLiAgVGhlIG9uZSByZWFzb24gdG8gbGVhdmUgdGhlIHRpdGxlIGFzLWlzIGlz
IHRoYXQgcmVzb3VyY2UgZGlzY292ZXJ5IG1pZ2h0IGVuZCB1cCBpbnZvbHZpbmcgZXh0ZW5zaW9u
cyB0byB0aGlzIG1ldGFkYXRhIGZvcm1hdCBpbiBzb21lIGNhc2VzLg0KDQoNCg0KDQoNCg0KDQpJ
IHRoaW5rIGFuIGFuYWxvZ3kgdG8gdGhlIGNvcmUgT0F1dGggZG9jdW1lbnRzIFJGQyA2NzQ5IGFu
ZCBSRkMgNjc1MCBhcHBsaWVzLiAgNjc0OSBpcyBhYm91dCB0aGUgQVMuICA2NzUwIGlzIGFib3V0
IHRoZSBSUy4gIFRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQgaXMgYWJvdXQgdGhlIEFTLiAgV2UgZG9u
4oCZdCB5ZXQgaGF2ZSBhIHNwZWNpZmljYXRpb24gb3IgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIFJT
IGRpc2NvdmVyeSwgd2hpY2ggd291bGQgYmUgdGhlIDY3NTAgYW5hbG9neS4NCg0KDQoNCg0KDQoN
Cg0KSW4gc3VtbWFyeSwgd2hpY2ggdGl0bGUgZG8gcGVvcGxlIHByZWZlcj8NCg0KDQoNCsK3ICAg
ICAgIOKAnE9BdXRoIDIuMCBEaXNjb3ZlcnnigJ0NCg0KDQoNCsK3ICAgICAgIOKAnE9BdXRoIDIu
MCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ0NCg0KDQoNCg0KDQoNCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p
a2UNCg0KDQoNCiAgPD4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVmxhZGltaXIgRHpodXZpbm92DQoNClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAyNSwgMjAxNiAxMjo1OSBBTQ0KDQpUbzogb2F1dGhAaWV0Zi5vcmc8bWFp
bHRvOm9hdXRoQGlldGYub3JnPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+DQoNCg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292
ZXJ5IExvY2F0aW9uDQoNCg0KDQoNCg0KDQoNCkluIE9JREMgdGhlIGRpc2NvdmVyeSBkb2MgaXMg
b2YgZ3JlYXQgdXRpbGl0eSB0byBkZXZlbG9wZXJzIGFuZCBpbnRlZ3JhdG9ycy4gRGV2ZWxvcGVy
cyBhbHNvIHRlbmQgdG8gZmluZCBpdCBhIG1vcmUgYWNjdXJhdGUgYW5kIGNvbXBsZXRlIGRlc2Ny
aXB0aW9uIG9mIGhvdyB0byBzZXQgdXAgYSBjbGllbnQgZm9yIGEgcGFydGljdWxhciBkZXBsb3lt
ZW50LCBjb21wYXJlZCB0byB0cmFkaXRpb25hbCBvbmxpbmUgZG9jcywgd2hpY2ggbWF5IGJlIG5v
dCBiZSB1cCB0byBkYXRlLCBvciBldmVuIG1pc3NpbmcuIFZlcnkgbXVjaCBsaWtlIGF1dG8tZ2Vu
ZXJhdGVkIFN3YWdnZXIgYW5kIEphdmFEb2NzLg0KDQoNCg0KSGVyZSBhcmUgc29tZSBleGFtcGxl
IE9JREMgZGlzY292ZXJ5IGRvY3M6DQoNCg0KDQpodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20v
LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24gPGh0dHBzOi8vYWNjb3VudHMuZ29vZ2xl
LmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbj48aHR0cHM6Ly9hY2NvdW50cy5n
b29nbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPg0KDQoNCg0KaHR0cHM6
Ly93d3cucGF5cGFsb2JqZWN0cy5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24g
PGh0dHBzOi8vd3d3LnBheXBhbG9iamVjdHMuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1
cmF0aW9uPjxodHRwczovL3d3dy5wYXlwYWxvYmplY3RzLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQt
Y29uZmlndXJhdGlvbj4NCg0KDQoNCmh0dHBzOi8vbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbS9m
YWJyaWthbWIyYy5vbm1pY3Jvc29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmln
dXJhdGlvbiA8aHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2ZhYnJpa2FtYjJjLm9u
bWljcm9zb2Z0LmNvbS92Mi4wLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPjxodHRw
czovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZmFicmlrYW1iMmMub25taWNyb3NvZnQuY29t
L3YyLjAvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24+DQoNCg0KDQoNCg0KV2l0aCB0
aGlzIGRpc2NvdmVyeSBkb2N1bWVudCBpbiBwbGFjZSBzZXR1cCBvZiBpZGVudGl0eSBmZWRlcmF0
aW9uIGNhbiB0aGVuIGJlIGVhc2lseSBzY3JpcHRlZC4gRm9yIGV4YW1wbGU6DQoNCg0KDQpodHRw
Oi8vZG9jcy5hd3MuYW1hem9uLmNvbS9JQU0vbGF0ZXN0L1VzZXJHdWlkZS9pZF9yb2xlc19wcm92
aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5LXRodW1icHJpbnQuaHRtbCA8aHR0cDovL2RvY3MuYXdz
LmFtYXpvbi5jb20vSUFNL2xhdGVzdC9Vc2VyR3VpZGUvaWRfcm9sZXNfcHJvdmlkZXJzX2NyZWF0
ZV9vaWRjX3ZlcmlmeS10aHVtYnByaW50Lmh0bWw+PGh0dHA6Ly9kb2NzLmF3cy5hbWF6b24uY29t
L0lBTS9sYXRlc3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVyc19jcmVhdGVfb2lkY192ZXJp
ZnktdGh1bWJwcmludC5odG1sPg0KDQoNCg0KDQoNCk5vdywgZG9lcyB0aGF0IGRpY3RhdGUgYW55
IHBhcnRpY3VsYXIgYXBwIGFyY2hpdGVjdHVyZT8gTXkgcmVhZGluZyBvZiB0aGUgc3BlYyBpcyB0
aGF0IGl0IGRvZXNuJ3QsIGFuZCBpdCBzaG91bGRuJ3QgZWl0aGVyLiBCeSBzdGF5aW5nIG5ldXRy
YWwgb24gdGhlIHRvcGljcyBvZiBSUyBkaXNjb3ZlcnkgYW5kIHJlZ2lzdGVyaW5nIFJQcyB3aXRo
IFJTcy4gQW5kIGhvdyBvbmUgYXJyaXZlcyBhdCB0aGUgIi53ZWxsLWtub3duLy4uLiIuIEknbSBu
b3QgZXZlbiBzdXJlIHRoYXQgcmVzb3VyY2UgZGlzY292ZXJ5IHNob3VsZCBiZSBhIHRvcGljIG9m
IHRoaXMgV0cuIFBlcmhhcHMgdG8gdGhpcyBlbmQsIGFuZCB0byBwcmV2ZW50IGNvbmZ1c2lvbiB0
aGF0IHRoZSBzcGVjIGlzIHRyeWluZyB0byBkbyBzb21ldGhpbmcgbW9yZSwgYSBtb3JlIHNwZWNp
ZmljIHRpdGxlIHdvdWxkIHN1aXQgaXQgYmV0dGVyLiBFLmcuICJBUyBEaXNjb3ZlcnkiLg0KDQoN
Cg0KQ2hlZXJzLA0KDQoNCg0KVmxhZGltaXINCg0KDQoNCg0KDQoNCg0KDQoNCk9uIDI1LzAyLzE2
IDAyOjI1LCBQaGlsIEh1bnQgKElETSkgd3JvdGU6DQoNCg0KDQpBbmQgc28gZG9lcyBvcmFjbGUg
YW5kIHNvIGRvZXMgZ29vZ2xlLiBFYWNoIGRpZmZlcmVudC4NCg0KDQoNClNvIGhvdyBjYW4gYW4g
YXBwIGRpY3RhdGUgaXQgdGhlbiB1bmxlc3Mgd2UgYWxsIGdvIHRvIGEgY29tbW9uIGFyY2hpdGVj
dHVyZT8NCg0KDQoNClBoaWwNCg0KDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTY6MDQsIE1pa2Ug
Sm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNA
bWljcm9zb2Z0LmNvbT4gPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQoNCg0KQXp1cmUgZGVmaW5l
cyB3YXlzIGZvciByZXNvdXJjZSBzZXJ2ZXJzIHRvIGJlIHJlZ2lzdGVyZWQgZm9yIHVzZSB3aXRo
IGEgY2xpZW50IGFuZCBmb3IgY2xpZW50cyB0byBkeW5hbWljYWxseSByZXF1ZXN0IGFuIGFjY2Vz
cyB0b2tlbiBmb3IgdXNlIGF0IGEgcGFydGljdWxhciByZXNvdXJjZSBzZXJ2ZXIuICBZb3UgY2Fu
IGNhbGwgdGhhdCBjdXN0b20gYXJjaGl0ZWN0dXJlIGlmIHlvdSB3YW50LiAgSXTigJlzIHdlbGwt
ZGVmaW5lZCBidXQgaXTigJlzIG5vdCBjdXJyZW50bHkgaW4gdGhlIHN0YW5kYXJkcyByZWFsbS4g
IEkga25vdyB0aGF0IEdvb2dsZSBoYXMgc3ludGF4IGZvciBkb2luZyB0aGUgc2FtZSwgYXMgSeKA
mW0gc3VyZSBkbyBhIGxvdCBvZiBvdGhlciBjbG91ZCBPQXV0aCBkZXBsb3ltZW50cywgc3VjaCBh
cyBPcmFjbGXigJlzLiAgRm9yIHdoYXQgaXTigJlzIHdvcnRoLCB0aGUgd29ya2luZyBncm91cCB0
YWxrZWQgYWJvdXQgcG9zc2libHkgcHJvZHVjaW5nIGEgc3RhbmRhcmQgdmVyc2lvbiBvZiBzeW50
YXggZm9yIG1ha2luZyB0aGVzZSBraW5kcyBvZiByZXF1ZXN0cyBkdXJpbmcgb3VyIGRpc2N1c3Np
b25zIGluIFByYWd1ZSAoZHVyaW5nIHRoZSBUb2tlbiBFeGNoYW5nZSBkaXNjdXNzaW9uKSBidXQg
bm9ib2R5IGhhcyBydW4gd2l0aCB0aGlzIHlldC4NCg0KDQoNCkluIHRoaXMgc2Vuc2UsIHllcywg
QXp1cmUgaXMgYW4gYXBwbGljYXRpb24gb2YgdGhlIGtpbmQgd2XigJlyZSB0YWxraW5nIGFib3V0
LiAgQXp1cmUgYWxyZWFkeSBkb2VzIGRlZmluZSBzcGVjaWZpYyBuZXcgT0F1dGggMi4wIGRpc2Nv
dmVyeSBtZXRhZGF0YSB2YWx1ZXMgdGhhdCBhcmUgdXNlZCBpbiBwcm9kdWN0aW9uLiAgQSByZWdp
c3RyeSBqdXN0IGRvZXNu4oCZdCB5ZXQgZXhpc3QgaW4gd2hpY2ggaXQgY2FuIHJlZ2lzdGVyIHRo
b3NlIHRoYXQgYXJlIG9mIGdlbmVyYWwgYXBwbGljYWJpbGl0eS4NCg0KDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN
aWtlDQoNCg0KDQpGcm9tOiBQaGlsIEh1bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbSA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb20+XQ0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDM6NTIgUE0NCg0K
VG86IE1pa2UgSm9uZXMNCg0KQ2M6IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYu
b3JnPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoNClN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KDQoN
Ck1pa2UNCg0KDQoNClRha2UgYSBsb29rIGF0IHRoZSBhc3N1bXB0aW9ucyB5b3UgYXJlIG1ha2lu
Zy4NCg0KDQoNCllvdSBzZWVtIHRvIGJlIGFzc3VtaW5nIGFwcGxpY2F0aW9uIHNvZnR3YXJlIGRp
Y3RhdGVzIG9hdXRoIGluZnJhc3RydWN0dXJlIGFyY2hpdGVjdHVyZSBieSBzdWdnZXN0aW5nIHRo
YXQgYXBwcyByZWdpc3RlciBpbiBpYW5hLg0KDQoNCg0KV291bGQgbXMgYXp1cmUgYWxsb3cgY3Vz
dG9tIGFyY2g/DQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDE1OjI4LCBN
aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb20+IDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxt
YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KDQoNClRoZSBVc2Vy
SW5mbyBFbmRwb2ludCBwYXRoIGlzbuKAmXQgZml4ZWQgYW5kIHNvIGhhcyB0byBiZSBkaXNjb3Zl
cmVkLg0KDQoNCg0KSSBhZ3JlZSB0aGF0IGZvciBzb21lIE9BdXRoIHByb2ZpbGVzLCBvbmUgb3Ig
bW9yZSByZXNvdXJjZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSBkaXNjb3ZlcmVkIHN0YXJ0aW5n
IGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgV29ya2luZyBncm91cCBtZW1iZXJzIGhh
dmUgYWxzbyBkZXNjcmliZWQgd2FudGluZyB0byBkaXNjb3ZlciBhdXRob3JpemF0aW9uIHNlcnZl
cnMgc3RhcnRpbmcgZnJvbSByZXNvdXJjZSBzZXJ2ZXJzLiAgVGhlcmUgaXNu4oCZdCBhIHN0YW5k
YXJkIHByYWN0aWNlIGZvciBhbnkgb2YgdGhpcywgd2hpY2ggaXMgd2h5IGl04oCZcyBpbnRlbnRp
b25hbGx5IGxlZnQgb3V0IG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24uDQoNCg0KDQpPbmNl
IHRoZSBJQU5BIE9BdXRoIERpc2NvdmVyeSBNZXRhZGF0YSBSZWdpc3RyeSBoYXMgYmVlbiBlc3Rh
Ymxpc2hlZCwgd2hpY2ggd2lsbCBoYXBwZW4gYWZ0ZXIgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlv
biBoYXMgYmVlbiBhcHByb3ZlZCwgaXQgd2lsbCBiZSBlYXN5IGZvciBzdWJzZXF1ZW50IHNwZWNp
ZmljYXRpb25zIHRvIGRvY3VtZW50IGV4aXN0aW5nIHByYWN0aWNlIGZvciBkaWZmZXJlbnQgT0F1
dGggcHJvZmlsZXMgYW5kIHJlZ2lzdGVyIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMgc3VwcG9y
dGluZyB0aGVtLiAgU29tZSBvZiB0aG9zZSB2YWx1ZXMgd2lsbCBsaWtlbHkgZGVmaW5lIHdheXMg
dG8gZGlzY292ZXIgcmVzb3VyY2Ugc2VydmVycywgd2hlbiBhcHBsaWNhYmxlLg0KDQoNCg0KQnV0
IGZpcnN0LCB3ZSBuZWVkIHRvIGZpbmlzaCB0aGUgZXhpc3Rpbmcgc3BlYywgc28gdGhhdCB0aGUg
cmVnaXN0cnkgZW5hYmxpbmcgdGhlc2UgZXh0ZW5zaW9ucyBnZXRzIGVzdGFibGlzaGVkIGluIHRo
ZSBmaXJzdCBwbGFjZS4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQpGcm9tOiBQaGlsIEh1
bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSA8bWFpbHRvOnBoaWwuaHVudEBv
cmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+XQ0KDQpTZW50OiBXZWRuZXNk
YXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDI6MTMgUE0NCg0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4g
PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+DQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8b2F1
dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0
aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpZdXAuIEFuZCBiZWNhdXNlIHRoZXJlIG1h
bnkgcmVsYXRpb25zIHRoZSBjbGllbnQgbWlzdCBiZSBhYmxlIHRvIGRpc2NvdmVyIGl0LiBUaGUg
Y2xpZW50IGRvZXMgbm90IGtub3cgaWYgdGhlIHJlcyBzZXJ2ZXIgaXMgbGVnaXQuDQoNCg0KDQpU
aGUgdXNlcmluZm8gaXMgYWx3YXlzIGZpeCBhbmQgc28gdSBkb250IG5lZWQgZGlzY292ZXJ5Lg0K
DQoNCg0KUGhpbA0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAxNDowNSwgTWlrZSBKb25lcyA8
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv
ZnQuY29tPiA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCg0KDQpJbiBPcGVuSUQgQ29ubmVjdCwg
dGhlcmXigJlzIGEgcmVzb3VyY2Ugc2VydmVyIGNhbGxlZCB0aGUgVXNlckluZm8gRW5kcG9pbnQg
dGhhdCByZXR1cm5zIGNsYWltcyBhYm91dCB0aGUgYXV0aGVudGljYXRlZCB1c2VyIGFzIGEgSlNP
TiBkYXRhIHN0cnVjdHVyZS4gIEl0cyBsb2NhdGlvbiBpcyBwdWJsaXNoZWQgaW4gT3BlbklEIENv
bm5lY3QgZGlzY292ZXJ5IG1ldGFkYXRhIGFzIHRoZSDigJx1c2VyaW5mb19lbmRwb2ludOKAnSBt
ZXRhZGF0YSB2YWx1ZSwgd2hpY2ggaXMgZGVmaW5lZCBhdCBodHRwOi8vb3BlbmlkLm5ldC9zcGVj
cy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YSA8aHR0
cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1By
b3ZpZGVyTWV0YWRhdGE+PGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRp
c2NvdmVyeS0xXzAuaHRtbCNQcm92aWRlck1ldGFkYXRhPi4NCg0KDQoNCldlIGRpZG7igJl0IGlu
Y2x1ZGUgdGhlIFVzZXJJbmZvIEVuZHBvaW50IGluIHRoZSBnZW5lcmljIE9BdXRoIGRpc2NvdmVy
eSBzcGVjIHNpbmNlIGluIE9BdXRoLCB0aGVyZSBhcmUgbG90cyBvZiBwb3NzaWJsZSByZWxhdGlv
bnNoaXBzIGJldHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZCByZXNvdXJjZSBzZXJ2ZXJz
IGFuZCB0aGV5IG5lZWRu4oCZdCBiZSBvbmUtdG8tb25lLCBhcyBpcyBiZWluZyBhY3RpdmVseSBk
aXNjdXNzZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuICBGb3IgaW5zdGFuY2UsIHNlZSBHZW9yZ2Ug
RmxldGNoZXLigJlzIHJlY2VudCBjb250cmlidXRpb24uDQoNCg0KDQpUaGFua3MgZm9yIHRoZSBn
b29kIGRpc2N1c3Npb24sIFBoaWwuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KRnJvbTog
UGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20gPG1haWx0bzpwaGls
Lmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPl0NCg0KU2VudDog
V2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxOjI1IFBNDQoNClRvOiBNaWtlIEpvbmVzDQoN
CkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0
aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpXaGVyZSBpcyB0aGUgcHJv
ZmlsZSBlbmRwb2ludCAob2lkYydzIHJlc291cmNlIHNlcnZlcikgcHVibGlzaGVkPyAoRm9yIHRo
ZSBub24gT0lEQyBwZW9wbGUgb24gdGhlIGxpc3QpLg0KDQoNCg0KUGhpbA0KDQoNCg0KT24gRmVi
IDI0LCAyMDE2LCBhdCAxMzowOSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiA8bWFpbHRvOk1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4g
d3JvdGU6DQoNCg0KDQpUbyB0aGUgZXh0ZW50IHRoYXQgZ2VuZXJpYyBPQXV0aCAyLjAgbmVlZHMg
dG8gcHVibGlzaCBzb21lIG9mIHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIE9wZW5JRCBDb25uZWN0
IOKAkyB3aGljaCBpcyBidWlsdCBvbiBnZW5lcmljIE9BdXRoIDIuMCDigJMgaXQgbWFrZXMgc2Vu
c2UgdG8gcHVibGlzaCB0aGF0IGluZm9ybWF0aW9uIHVzaW5nIGV4YWN0bHkgdGhlIHNhbWUgc3lu
dGF4LCBzaW5jZSB0aGF0IHN5bnRheCBpcyBhbHJlYWR5IGluIHdpZGVzcHJlYWQgdXNlLiAgVGhh
dCB3aGF0IHRoaXMgZHJhZnQgYWNjb21wbGlzaGVzLg0KDQoNCg0KVGhlcmXigJlzIG5vdGhpbmcg
Q29ubmVjdC1zcGVjaWZpYyBhYm91dCB1c2luZyBtZXRhZGF0YSByZXNwb25zZSB2YWx1ZXMgbGlr
ZToNCg0KDQoNCiAgICJhdXRob3JpemF0aW9uX2VuZHBvaW50IjogImh0dHBzOi8vc2VydmVyLmV4
YW1wbGUuY29tL2F1dGhvcml6ZSI8aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXpl
PiA8aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplPjxodHRwczovL3NlcnZlci5l
eGFtcGxlLmNvbS9hdXRob3JpemU+LA0KDQogICAidG9rZW5fZW5kcG9pbnQiOiAiaHR0cHM6Ly9z
ZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4iPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2Vu
PiA8aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4+PGh0dHBzOi8vc2VydmVyLmV4YW1w
bGUuY29tL3Rva2VuPiwNCg0KICAgInRva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0
ZWQiOiBbImNsaWVudF9zZWNyZXRfYmFzaWMiLCAicHJpdmF0ZV9rZXlfand0Il0sDQoNCiAgICJy
ZWdpc3RyYXRpb25fZW5kcG9pbnQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0
ZXIiPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyPiA8aHR0cHM6Ly9zZXJ2ZXIu
ZXhhbXBsZS5jb20vcmVnaXN0ZXI+PGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVy
PiwNCg0KICAgInJlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCI6ICBbImNvZGUiLCAidG9rZW4iXSwN
Cg0KICAgInNlcnZpY2VfZG9jdW1lbnRhdGlvbiI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29t
L3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sIjxodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3Nl
cnZpY2VfZG9jdW1lbnRhdGlvbi5odG1sPiA8aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2
aWNlX2RvY3VtZW50YXRpb24uaHRtbD48aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2aWNl
X2RvY3VtZW50YXRpb24uaHRtbD4sDQoNCg0KDQpJcyB0aGVyZSBhIHJlYXNvbiB0aGF0IHlvdSB3
b3VsZCBsaWtlIHRoZSBzeW50YXggZm9yIGFueSBvZiB0aGVzZSBvciB0aGUgb3RoZXIgZ2VuZXJh
bGx5IGFwcGxpY2FibGUgT0F1dGggMi4wIG1ldGFkYXRhIHZhbHVlcyB0byBiZSBkaWZmZXJlbnQ/
ICBJIGRvbuKAmXQgc2VlIGFueSBnb29kIHJlYXNvbiBmb3IgdW5uZWNlc3NhcnkgZGlmZmVyZW5j
ZXMgdG8gYmUgaW50cm9kdWNlZC4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQpGcm9tOiBQ
aGlsIEh1bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSA8bWFpbHRvOnBoaWwu
aHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+XQ0KDQpTZW50OiBX
ZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEyOjQ1IFBNDQoNClRvOiBBbnRob255IE5hZGFs
aW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT48bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4g
PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j
b20+DQoNCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgPG9hdXRoQGll
dGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1h
aWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5v
cmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3Vi
amVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0K
TWlrZQ0KDQoNCg0KUHVibGlzaGluZyBvbiBkZXYgcGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29m
dHdhcmUgKGVzcCBvcGVuIHNvdXJjZSkgdGhhdCBpcyBkZXBsb3llZCBib3RoIGluIGVudGVycHJp
c2VzIGFuZCBvbiBQYWFTIGNsb3VkIHByb3ZpZGVycy4NCg0KDQoNClRoZSBjdXJyZW50IGRyYWZ0
IGlzIG1heSBjb2RpZnkgY3VycmVudCBPSURDIHByYWN0aWNlIGFuZCBiZSBhcHByb3ByaWF0ZSBm
b3Igb2lkYyBidXQgaXQgaXMgbm90IHJlYWR5IGZvciBnZW5lcmljIG9hdXRoLiBUaGVyZSBpcyBu
byBnZW5lcmljIG9hdXRoIGV4cGVyaWVuY2UgYXQgdGhpcyB0aW1lLg0KDQoNCg0KUGhpbA0KDQoN
Cg0KT24gRmViIDI0LCAyMDE2LCBhdCAxMDoyNSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1p
Y3Jvc29mdC5jb20+PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+IDxtYWlsdG86dG9ueW5h
ZEBtaWNyb3NvZnQuY29tPjxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0K
DQoNClN1cmUgdGhlcmUgaXMsIGl0IGlzIGFzIHlvdSBoYXZlIG5vdyBtYWRlIGl0IGZhciBlYXNp
ZXIgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBldmVuIGFkZHJlc3Mg
dGhpcw0KDQoNCg0KRnJvbTogTWlrZSBKb25lcw0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5
IDI0LCAyMDE2IDEwOjIyIEFNDQoNClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9z
b2Z0LmNvbT48bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4gPG1haWx0bzp0b255bmFkQG1p
Y3Jvc29mdC5jb20+PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+DQoNCkNjOiA8b2F1dGhA
aWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48
bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpT
dWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0K
DQpBcyB3ZeKAmWQgZGlzY3Vzc2VkIGluIHBlcnNvbiwgdGhlcmXigJlzIG5vIGVmZmVjdGl2ZSBz
ZWN1cml0eSBkaWZmZXJlbmNlIGJldHdlZW4gZGlzY292ZXJ5IGluZm9ybWF0aW9uIGJlaW5nIHB1
Ymxpc2hlZCBpbiBhbiBhZC1ob2MgZmFzaGlvbiBvbiBkZXZlbG9wZXIgcGFnZXMgYW5kIGl0IGJl
aW5nIHB1Ymxpc2hlZCBpbiBhIHN0YW5kYXJkIGZvcm1hdC4gIOKAnFNlY3VyaXR5IGJ5IG9ic2N1
cml0eeKAnSBhZGRzIG5vIHJlYWwgc2VjdXJpdHkgYXQgYWxsLg0KDQoNCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K
DQoNCkZyb206IEFudGhvbnkgTmFkYWxpbg0KDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0
LCAyMDE2IDEwOjAxIEFNDQoNClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IDxtYWlsdG86TWljaGFl
bC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVu
dEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5o
dW50QG9yYWNsZS5jb20+OyBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRv
OnNha2ltdXJhQGdtYWlsLmNvbT4gPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpz
YWtpbXVyYUBnbWFpbC5jb20+DQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBp
ZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8
b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBP
QXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpUaGUgcG9pbnQgb2YgdGhlIFdHTEMg
aXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxp
dHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQuDQoNCg0KDQpUaGF0IG1heSBiZSB3
aWRlbHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQgZm9yIE9BdXRo
LiBUaGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292ZXJ5IGZvciBl
bmRwb2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90IGJlIGluIGFuIE9BdXRoIHN0YW5kYXJkIHNp
bmNlIGl04oCZcyByZWFsbHkgbm90IGRlYWx0IHdpdGguIE5vdyB0aGF0IGFsbCB0aGlzIGluZm9y
bWF0aW9uIGlzIGF2YWlsYWJsZSBpdCBtYWtlcyBwb2tpbmcgYXJvdW5kIHRoZSBlbmRwb2ludCBt
b3JlIGZvY3VzZWQgZm9yIHBlb3BsZSB0aGF0IHdhbnQgdG8gZGlzcnVwdCB5b3VyIGVuZHBvaW50
cywgdGhhdCBpcyByZWFsbHkgbm90IGFkZHJlc3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJh
dGlvbnMgIHNlY3Rpb24gYXQgYWxsDQoNCg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQoNClNlbnQ6IFdl
ZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTQ0KDQpUbzogUGhpbCBIdW50IChJRE0p
IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFp
bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+OyBO
YXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNv
bT4gPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+
DQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+PG1h
aWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRo
QGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5
IExvY2F0aW9uDQoNCg0KDQpUaGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5k
YXJkaXppbmcgdGhlIGNvcmUgZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFk
eSB3aWRlbHkgZGVwbG95ZWQuDQoNCg0KDQpOb25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1
Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJl
IGNyZWF0ZWQuICBJ4oCZbSBzdXJlIGl0IHdpbGwgYmUuICBTb21lIGFwcGxpY2F0aW9ucyB3aWxs
IHVzZSBXZWJGaW5nZXIgdG8gbG9jYXRlIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEuICBTb21lIHdp
bGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4gIFNvbWUgd2lsbCBwb3NzaWJseSB1c2UgYXBw
bGljYXRpb24tc3BlY2lmaWMgLndlbGwta25vd24gdmFsdWVzLiAgSeKAmW0gc3VyZSB0aGVyZeKA
mXMgb3RoZXIgdGhpbmdzIEkgaGF2ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4gIEFsbCBvZiB0
aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgZm9y
bWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRv
IHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy4NCg0KDQoNClNv
IGJ5IGFsbCBtZWFucywgdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGNvbnRpbnVlIGRpc2N1c3Np
bmcgaW52ZW50aW5nIHBvc3NpYmxlIG5ldyByZWxhdGVkIG1lY2hhbmlzbXMgdGhhdCBtYWtlIHNl
bnNlIGluIHNvbWUgY29udGV4dHMuICBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBjYW4gZmluaXNoIHN0
YW5kYXJkaXppbmcgdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0
eSB0aGF0IGFsbCBvZiB0aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC4NCg0KDQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl
DQoNCg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0
bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5d
IE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElETSkNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy
eSAyNCwgMjAxNiA4OjM5IEFNDQoNClRvOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNv
bT48bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4gPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+
PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+DQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGll
dGYub3JnPiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW09B
VVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpJIGFtIHN1Z2dlc3Rp
bmcgdGhhdCBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnkgc29sdXRpb24gaGFzIHRvIGJlIHRoZSBjbGll
bnQgaW5kaWNhdGluZyB3aGF0IHJlc291cmNlIGVuZHBvaW50IGl0IHdhbnRzIHRoZSBvYXV0aCBj
b25maWd1cmF0aW9uIGRhdGEgZm9yLg0KDQoNCg0KU28gaWYgcmVzLmV4YW1wbGUuZXZpbC5jb20g
PGh0dHA6Ly9yZXMuZXhhbXBsZS5ldmlsLmNvbS8+PGh0dHA6Ly9yZXMuZXhhbXBsZS5ldmlsLmNv
bS8+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBvaW50IGZvciBhcy5leGFtcGxlLmNvbSA8
aHR0cDovL2FzLmV4YW1wbGUuY29tLz48aHR0cDovL2FzLmV4YW1wbGUuY29tLz4gdGhlIGF1dGh6
IGRpc2NvdmVyeSBzaG91bGQgZmFpbCBpbiBzb21lIHdheSAoZWcgcmV0dXJuIG5vdGhpbmcpLg0K
DQoNCg0KVGhlcmUgbWF5IGJlIGJldHRlciB3YXlzIHRvIGRvIHRoaXMuIEVnIGNvbWJpbmUgZGlz
Y292ZXJ5LiBPciBjaGFuZ2UgdGhlIG9yZGVyIG9mIGRpc2NvdmVyeS4NCg0KDQoNCk9uZSBvZiBP
QXV0aCdzIHN0cmVuZ3RoJ3MgYW5kIHdlYWtuZXNzZXMgaXMgdGhhdCB0aGUgdGFyZ2V0IG9mIGF1
dGhvcml6YXRpb24gKHRoZSByZXNvdXJjZSkgaXMgbmV2ZXIgc3BlY2lmaWVkLiBJdCBpcyBvZnRl
biBib3VuZCB1cCBpbiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgYW4gb2Z0ZW4gaW1wbGll
ZCAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gcmVzb3VyY2UgYW5kIGFzLiBHaXZlbiB0aGF0IGlu
IGRpc2NvdmVyeSBwaGFzZSByZWdpc3RyYXRpb24gaGFzIG5vdCB5ZXQgb2NjdXJyZWQgaXQgc2Vl
bXMgaW1wb3J0YW50IHRoYXQgdGhlIGNsaWVudCBrbm93IGl0IGhhcyBhIHZhbGlkIGNvbWJpbmF0
aW9uIG9mIGVuZHBvaW50cyBldGMuDQoNCg0KDQpUaGlzIGlzIHdoeSBJIHdhcyBkaXNhcHBvaW50
ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0YXJ0aW5nIHBvaW50IGZvciBn
cm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVmaW5lZCB0aGUgZnVsbCByZXF1
aXJlbWVudHMgSU1PLg0KDQoNCg0KSSBhbSBvbiB2YWNhdGlvbiBvciBJIHdvdWxkIHB1dCBzb21l
IHRob3VnaHQgaW50byBzb21lIGRyYWZ0IGNoYW5nZXMgb3IgYSBuZXcgZHJhZnQuIEkgYXBvbG9n
aXplIEkgY2FuJ3QgZG8gaXQgbm93Lg0KDQoNCg0KUGhpbA0KDQoNCg0KT24gRmViIDI0LCAyMDE2
LCBhdCAwODoxMiwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpzYWtp
bXVyYUBnbWFpbC5jb20+IDxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11
cmFAZ21haWwuY29tPiB3cm90ZToNCg0KDQoNCkhpIFBoaWwsDQoNCg0KDQpBcmUgeW91IHN1Z2dl
c3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUgdGhlIFJTIFVSSXM/IEN1
cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwgSSBndWVzcy4NCg0KDQoN
ClRoZSB3YXkgb2F1dGgtbWV0YSB3b3JrcyBpcyB0aGF0DQoNCg0KDQoxLiBSUyB0ZWxscyB0aGUg
Y2xpZW50IHdoZXJlIHRoZSBBUyBpcy4NCg0KMi4gQVMgdGVsbHMgdGhlIGNsaWVudCB3aGljaCBS
UyBlbmRwb2ludHMgdGhlIHRva2VuIGNhbiBiZSB1c2VkLg0KDQoNCg0KRXZlbiBpZiB0aGVyZSBp
cyBhIGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJT
LCB0aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBz
ZXJ2ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQg
dG8gc2VuZCB0aGUgdG9rZW4gdG8uDQoNCg0KDQpOYXQNCg0KDQoNCjIwMTblubQy5pyIMjTml6Uo
5rC0KSAyMzo1OSBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5o
dW50QG9yYWNsZS5jb20+IDxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGls
Lmh1bnRAb3JhY2xlLmNvbT46DQoNCk5hdCwNCg0KDQoNCknigJltIG5vdCBzdXJlIHRoYXQgaGF2
aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGVsbCB0aGUgY2xpZW50IHdoZXJlIGl0cyBhdXRob3Jp
emF0aW9uIHNlcnZlciBpcyBzZWN1cmUgYnkgaXRzZWxmLiBUaGUgcmVsYXRpb25zaGlwIGJldHdl
ZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGFuZCB0aGUgUmVzb3VyY2Ugc2VydmVyIG5lZWQg
dG8gYmUgYm91bmQgdG9nZXRoZXIgaW4gb25lIG9mIHRoZSBkaXNjb3ZlcnkgZW5kcG9pbnRzICh0
aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2aWNlIGRpc2NvdmVyeSkuDQoNCg0KDQpJ
ZiBhIGNsaWVudCBkaXNjb3ZlcnMgYSBmYWtlIHJlc291cmNlIHNlcnZlciB0aGF0IGlzIHByb3h5
aW5nIGZvciBhIHJlYWwgcmVzb3VyY2Ugc2VydmVyIHRoZSBjdXJyZW50IGRpc2NvdmVyeSBzcGVj
IHdpbGwgbm90IGxlYWQgdGhlIGNsaWVudCB0byB1bmRlcnN0YW5kIGl0IGhhcyB0aGUgd3Jvbmcg
cmVzb3VyY2Ugc2VydmVyLiBSYXRoZXIgdGhlIGZha2UgcmVzb3VyY2Ugc2VydmljZSB3aWxsIGp1
c3QgaGF2ZSBhIGZha2UgZGlzY292ZXJ5IHNlcnZpY2UuIFRoZSBoYWNrZXIgY2FuIG5vdyBpbnRl
cmNlcHQgcmVzb3VyY2UgcGF5bG9hZCBhcyB3ZWxsIGFzIHRva2VucyBiZWNhdXNlIHRoZXkgd2Vy
ZSBhYmxlIHRvIGNvbnZpbmNlIHRoZSBjbGllbnQgdG8gdXNlIHRoZSBsZWdpdCBhdXRob3JpemF0
aW9uIHNlcnZpY2UgYnV0IHVzZSB0aGUgdG9rZW4gYWdhaW5zdCB0aGUgaGFja2VycyBwcm94eS4N
Cg0KDQoNClRoZSBPQXV0aCBEaXNjb3Zlcnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRo
ZSBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0
YXRlZCByZXNvdXJjZSBlbmRwb2ludC4NCg0KDQoNClRoaXMgbm90IG9ubHkgd29ya3MgaW4gbm9y
bWFsIE9BdXRoIGJ1dCBzaG91bGQgYWRkIHNlY3VyaXR5IGV2ZW4gdG8gVU1BIHNpdHVhdGlvbnMu
DQoNCg0KDQpQaGlsDQoNCg0KDQpAaW5kZXBlbmRlbnRpZA0KDQp3d3cuaW5kZXBlbmRlbnRpZC5j
b208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4gPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRp
ZC5jb20vPjxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCg0KcGhpbC5odW50QG9yYWNs
ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFj
bGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KT24gRmViIDI0LCAyMDE2LCBhdCAzOjU0IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdt
YWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4gPG1haWx0bzpzYWtpbXVyYUBnbWFp
bC5jb20+PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+IHdyb3RlOg0KDQoNCg0KDQoNCkhpIFRo
b21hcywNCg0KDQoNCmlubGluZToNCg0KDQoNCjIwMTblubQy5pyIMjLml6Uo5pyIKSAxODo0NCBU
aG9tYXMgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb20+PG1haWx0bzp0LmJyb3llckBnbWFpbC5j
b20+IDxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPjxtYWlsdG86dC5icm95ZXJAZ21haWwuY29t
PjoNCg0KQ291bGRuJ3QgdGhlIGRvY3VtZW50IG9ubHkgZGVzY3JpYmUgdGhlIG1ldGFkYXRhPw0K
DQpJIHF1aXRlIGxpa2UgdGhlIGlkZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5
b3UgcmVhbGx5IHdhbnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBs
ZW1lbnRlcnMgLyB0byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9y
ICJhdXRvLWNvbmZpZ3VyYXRpb24iLg0KDQpUaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291
bGQgdGhlbiBlaXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMgZHJh
ZnQtc2FraW11cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMg
Zm9yIG90aGVyIG1ldGFkYXRhIHNwZWNzIChsaWtlIE9wZW5JRCBDb25uZWN0KS4NCg0KV2l0aCBk
cmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhJ3MgImR1cmkiIGFuZCB0aGUgInNjb3BlIiBhdHRyaWJ1
dGUgb2YgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIsIHlvdSBoYXZlIGV2ZXJ5dGhp
bmcgeW91IG5lZWQgdG8gcHJvY2VlZA0KDQoNCg0KWXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1
aXJlbWVudHMgdG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90Pw0KDQoNCg0KSW4gT0F1dGgncyBjYXNl
LCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0
aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlvdSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBV
TUEuKQ0KDQpTbywgdGhlIHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIGVp
dGhlciB0aGUgbG9jYXRpb24gb2YgdGhlIGF1dGh6IGVuZHBvaW50LiBJbiBzb21lIHRydXN0ZWQg
ZW52aXJvbm1lbnQsIHRoZSByZXNvdXJjZSBtYXkgYXMgd2VsbCByZXR1cm4gdGhlIGxvY2F0aW9u
IG9mIHRoZSBhdXRoeiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNlcywg
eW91IGRvIG5vdCBoYXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5b3Ug
c2F5LiBUaGlzIGZyZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUgbG9j
YXRpb24gY29sbGlzaW9ucyBldGMuIFdlIHNob3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUgdGhl
IHVyaSBzcGFjZSBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KDQoNCg0KKHdlbGwsIGV4Y2VwdCBpZiB0
aGVyZSBhcmUgc2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBs
aWtlIGFuIGVkZ2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3Rl
YWQgYmUgdXBkYXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3VjaCB0aGF0IGFuIFJTIGNvdWxk
IHJldHVybiBzZXZlcmFsIFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciwgZWFjaCB3aXRoIGl0cyBv
d24gInNjb3BlIiBhbmQgImR1cmkiIHZhbHVlPykNCg0KDQoNClllYWgsIEkgZ3Vlc3MgaXQgaXMg
YW4gZWRnZSBjYXNlLiBJIHdvdWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2
ZXJzIHRvIGRldmVsb3AgYSB0cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdy
ZWUgb24gYSBzaW5nbGUgc2V0IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLg0KDQoN
Cg0KQ2hlZXJzLA0KDQoNCg0KTmF0DQoNCg0KDQoNCg0KDQoNCk9uIEZyaSwgRmViIDE5LCAyMDE2
IGF0IDEwOjU5IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT48bWFpbHRvOmpyaWNo
ZXJAbWl0LmVkdT4gPG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PG1haWx0bzpqcmljaGVyQG1pdC5l
ZHU+IHdyb3RlOg0KDQpUaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQg
aXMgaGVscGZ1bCBhbmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhv
d2V2ZXIsIHN0aWxsIGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0
IG9yaWdpbnMuIE9uZSBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1l
OiB0aGUgdXNlIG9mIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0
aGUgZGlzY292ZXJ5IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50
LCBvciBhbiBPcGVuSUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVs
bGluZyByZWFzb24gdG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlz
bS4NCg0KDQoNCkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24vb2F1dGgtYXV0
aG9yaXphdGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxvY2F0aW9uLCBh
bmQgc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxlIGZyb20g4oCc
Ly53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2ZXIgYWxzbyBw
cm92aWRlcyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVyIGFwcGxpY2F0
aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBPQXV0
aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZpYyBk
aXNjb3ZlcnkgZG9jdW1lbnQuDQoNCg0KDQog4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0K
T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGggPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg+PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h
aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIDxodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPjxodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPjxodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN
Ck9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aD4NCg0KDQoNCg0KDQotLQ0KDQpWbGFkaW1pciBEemh1dmlub3YgOjog
dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPiA8
bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPjxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJp
ZC5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aD4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRo
QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

--_000_BY2PR03MB4428901D4BA97135B5AAF47F5B80BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4gR290
aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw
Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg
ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t
dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGFua3MgZm9yIHRha2lu
ZyB0aGUgdGltZSB0byBwcm9wb3NlIHNwZWNpZmljIHRleHQsIFBoaWwuJm5ic3A7IFRoYXTigJlz
IHJlYWxseSBoZWxwZnVsLiZuYnNwOyBJ4oCZbGwgcGxhbiB0byBpbmNvcnBvcmF0ZSBhIHZlcnNp
b24gb2YgdGhpcyBpbiB0aGUgZHJhZnQgYWRkcmVzc2luZyBXR0xDIGNvbW1lbnRzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBhZ3JlZSB3aXRoIFZsYWRpbWly
4oCZcyBvYnNlcnZhdGlvbiB0aGF0IGl04oCZcyBkaWZmaWN1bHQgdG8gY29tZSB1cCB3aXRoIGEg
Z2VuZXJhbC1wdXJwb3NlIHJlc291cmNlIGRpc2NvdmVyeSBtZWNoYW5pc20uJm5ic3A7IFRoYXQg
aW4gcGFydCwgaXMgYmVjYXVzZSwgYXMgQnJpYW4gcG9pbnRzDQogb3V0LCB0aGVyZeKAmXMgb2Z0
ZW4gbm90IGEgMToxIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycyBh
bmQgcmVzb3VyY2Ugc2VydmVycy4mbmJzcDsgQXMgSeKAmXZlIHdyaXR0ZW4gYmVmb3JlLCBJIGRv
IGVuY291cmFnZSB0aGUgd29ya2luZyBncm91cCB0byB3b3JrIG9uIGNyZWF0aW5nIHNvbHV0aW9u
cyB0byByZXNvdXJjZSBkaXNjb3ZlcnkgdGhhdCB3aWxsIHdvcmsgZm9yIHNvbWUgY29tbW9uIHVz
ZSBjYXNlcy4mbmJzcDsgQnV0IHRoZSBnb29kDQogbmV3cyBpcyB0aGF0IHdoaWxlIHJlc291cmNl
IGRpc2NvdmVyeSByZXF1aXJlcyBuZXcgaW52ZW50aW9uLCBhdXRob3JpemF0aW9uIHNlcnZlciBk
aXNjb3ZlcnkgZG9lcyBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy
MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p
a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf
TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVu
ZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gT0F1dGggW21h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5WbGFkaW1p
ciBEemh1dmlub3Y8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEZlYnJ1YXJ5IDI3LCAyMDE2
IDEwOjMzIEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAyNy8wMi8xNiAyMDoxMCwgUGhpbCBIdW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+VGhlIG5hbWUgY2hhbmdlIHNlZW1zIGFwcHJvcHJpYXRlIGdpdmVuIHRo
YXQgdGhlIFdHIG1lbWJlcnMgaGF2ZSBkZWNpZGVkIG5vdCB0byBhZGRyZXNzIHRoZSBpc3N1ZSBv
ZiByZXNvdXJjZSBkaXNjb3ZlcnkgYXMgcGFydCBvZiB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SWYgdGhlIGNv
bnNlbnN1cyBpcyB0byBsaW1pdCB0aGUgc2NvcGUgb2YgdGhlIHNwZWNpZmljYXRpb24sIHRoZW4g
SSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dC48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5SZXNvdXJj
ZSBEaXNjb3Zlcnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT5TZWN1cmUgZGlzY292ZXJ5IG9mIHJlc291cmNlIGVuZHBvaW50cyBpcyBvdXQtb2Yt
c2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGlzIHNwZWNpZmljYXRpb24gYXNzdW1lcyB0
aGF0IHRoZSBjbGllbnQgaGFzIGFscmVhZHkgc2VjdXJlbHkgZGlzY292ZXJlZCB0aGUgY29ycmVj
dCByZXNvdXJjZSBlbmRwb2ludCBhbmQgdGhhdCB0aGUgY2xpZW50IGhhcyBjb3JyZWN0bHkgc2Vs
ZWN0ZWQgdGhlIGNvcnJlY3QgY29ycmVzcG9uZGluZyBkaXNjb3ZlcnkgZm9yIE9BdXRoIEF1dGhv
cml6YXRpb24gc2VydmVyLiBJbXBsZW1lbnRlcnMgTVVTVCBjb25zaWRlciB0aGF0IGlmIGFuIGlu
Y29ycmVjdCByZXNvdXJjZSBlbmRwb2ludCB3YXMgZGlzY292ZXJlZCBieSB0aGUgY2xpZW50IHRo
YXQgYW4gYXR0YWNrZXIgd2lsbCBiZSBhYmxlIHRvIHNldCB1cCBhIG1hbi1pbi10aGUtbWlkZGxl
IHByb3h5IHRvIGEgcmVhbCByZXNvdXJjZSBzZXJ2ZXIgd2l0aG91dCBkZXRlY3Rpb24gYnkgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyIG9yIHRoZSBjbGllbnQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHN1cHBvcnQgdGhhdC4g
VGhpcyB3YXMgdGhlIHByaW1hcnkgY29uY2VybiBvZiBldmVyeW9uZSB3aG8gZmVsdCB1bmNvbWZv
cnRhYmxlIHdpdGggdGhlIG9yaWdpbmFsIGRyYWZ0IHdpdGggV2ViRmluZ2VyLWJhc2VkIGRpc2Nv
dmVyeSBpbiBpdCwgc28gaXQgc2hvdWxkIGJlIGluY2x1ZGVkLjxicj4NCjxicj4NCjxicj4NCjxi
cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPkl0IG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGV2ZW4gaW5jbHVkZSB0aGlzIHRl
eHQgaW4gdGhlIGludHJvZHVjdGlvbiBhcyBhIGNhdXRpb25hcnkgJnF1b3Q7cmVkIGZsYWcmcXVv
dDsgdG8gaW1wbGVtZW50ZXJzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5PbmNlIGFnYWluLCBJIHN0cm9uZ2x5IHVyZ2UgdGhlIFdHIHRvIGFjdHVhbGx5
IGluY2x1ZGUgYSBtZXRob2QgZm9yIHRoZSBjbGllbnQgdG8gZGlzY292ZXJ5IHRoYXQgdGhlIG9h
dXRoIGNsaWV0IGhhcyBjb3JyZWN0bHkgZGlzY292ZXJlZCBhbiBhdXRob3JpemF0aW9uIHNlcnZl
ciB0aGF0IGlzIHdpbGxpbmcgYW5kIGFibGUgdG8gaXNzdWUgYWNjZXNzIHRva2VucyBmb3IgYSBn
aXZlbiByZXNvdXJjZSBlbmRwb2ludC4gSSBiZWxpZXZlIHRoaXMgcmVsYXRpb25zaGlwIGlzIGNy
aXRpY2FsIHRvIHNlY3VyaXR5IG9mIE9BdXRoIGluIGNhc2VzIHdoZXJlIHJlc291cmNlIGVuZHBv
aW50cyBhcmUgZGlzY292ZXJlZCBkeW5hbWljYWxseS4mbmJzcDsgT2YgY291cnNlIHdpbGxpbmcg
YW5kIGFibGUgbWVhbnMgdGhhdCB0aGUgQVMgYmVsaWV2ZXMgdGhhdCB0aGUgZW5kcG9pbnQgaXMg
bGVnaXRpbWF0ZS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KVGhlIG1vcmUgSSB0aGluayBhYm91dCB0aGlzIHRvcGljLCB0aGUgbW9y
ZSBwZXNzaW1pc3RpYyBJIGdldCB0aGF0IHRoZXJlIGlzIGEgZ29vZCBzb2x1dGlvbiB0byB0aGlz
IDopPGJyPg0KPGJyPg0KVmxhZGltaXI8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5QaGlsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5j
b208L2E+IDxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIj4mbHQ7aHR0cDov
L3d3dy5pbmRlcGVuZGVudGlkLmNvbS8mZ3Q7PC9hPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA
b3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+IDxhIGhyZWY9Im1haWx0bzpwaGls
Lmh1bnRAb3JhY2xlLmNvbSI+Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT5PbiBGZWIgMjcsIDIwMTYsIGF0IDY6NDYgQU0sIFNhbXVlbCBFcmR0bWFuIDxhIGhyZWY9
Im1haWx0bzpzYW11ZWxAZXJkdG1hbi5zZSI+Jmx0O3NhbXVlbEBlcmR0bWFuLnNlJmd0OzwvYT4g
d3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+JiM0MzsxIGZvciDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5
4oCdPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
Ly9TYW11ZWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5PbiBUaHUsIEZlYiAyNSwgMjAxNiBhdCA4OjEwIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBo
cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb208L2E+IDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20iPiZsdDttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyBmb3IgeW91ciB0aG91Z2h0cywgVmxh
ZGltaXIuJm5ic3A7IEnigJltIGluY3JlYXNpbmdseSBpbmNsaW5lZCB0byBhY2NlcHQgeW91ciBz
dWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgdGl0bGUgZnJvbSDigJxPQXV0aCAyLjAgRGlzY292ZXJ5
4oCdIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ0uJm5i
c3A7IFdoaWxlIHRoZSBhYnN0cmFjdCBhbHJlYWR5IG1ha2VzIGl0IGNsZWFyIHRoYXQgdGhlIHNj
b3BlIG9mIHRoZSBkb2N1bWVudCBpcyBBUyBkaXNjb3ZlcnksIGRvaW5nIHNvIGluIHRoZSB0aXRs
ZSBzZWVtcyBsaWtlIGl0IGNvdWxkIGhlbHAgY2xhcmlmeSB0aGluZ3MsIGdpdmVuIHRoYXQgYSBs
b3Qgb2YgdGhlIGRpc2N1c3Npb24gc2VlbXMgdG8gYmUgYWJvdXQgcmVzb3VyY2UgZGlzY292ZXJ5
LCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5J4oCZbSBub3Qgc2F5aW5nIHRoYXQg
cmVzb3VyY2UgZGlzY292ZXJ5IGlzbuKAmXQgaW1wb3J0YW50IOKAkyBpdCBpcyDigJMgYnV0IHVu
bGlrZSBhdXRob3JpemF0aW9uIHNlcnZlciBkaXNjb3ZlcnksIHdoZXJlIHRoZXJl4oCZcyBsb3Rz
IG9mIGV4aXN0aW5nIHByYWN0aWNlLCBpbmNsdWRpbmcgdXNpbmcgdGhlIGV4aXN0aW5nIGRhdGEg
Zm9ybWF0IGZvciBkZXNjcmliaW5nIE9BdXRoIGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZW7igJl0
IGJlaW5nIHVzZWQgd2l0aCBPcGVuSUQgQ29ubmVjdCwgdGhlcmXigJlzIG5vIGV4aXN0aW5nIHBy
YWN0aWNlIHRvIHN0YW5kYXJkaXplIGZvciByZXNvdXJjZSBkaXNjb3ZlcnkuJm5ic3A7IFRoZSB0
aW1lIHRvIGNyZWF0ZSBhIHN0YW5kYXJkIGZvciB0aGF0IHNlZW1zIHRvIGJlIGFmdGVyIGV4aXN0
aW5nIHByYWN0aWNlIGhhcyBlbWVyZ2VkLiZuYnNwOyBJdCAqbWlnaHQqIG9yIG1pZ2h0IG5vdCB1
c2UgbmV3IG1ldGFkYXRhIHZhbHVlcyBpbiB0aGUgQVMgZGlzY292ZXJ5IGRvY3VtZW50LCBidXQg
dGhhdOKAmXMgc3RpbGwgdG8gYmUgZGV0ZXJtaW5lZC4mbmJzcDsgVGhlIG9uZSByZWFzb24gdG8g
bGVhdmUgdGhlIHRpdGxlIGFzLWlzIGlzIHRoYXQgcmVzb3VyY2UgZGlzY292ZXJ5IG1pZ2h0IGVu
ZCB1cCBpbnZvbHZpbmcgZXh0ZW5zaW9ucyB0byB0aGlzIG1ldGFkYXRhIGZvcm1hdCBpbiBzb21l
IGNhc2VzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5JIHRoaW5rIGFuIGFuYWxvZ3kgdG8gdGhlIGNvcmUgT0F1dGggZG9jdW1lbnRzIFJGQyA2NzQ5
IGFuZCBSRkMgNjc1MCBhcHBsaWVzLiZuYnNwOyA2NzQ5IGlzIGFib3V0IHRoZSBBUy4mbmJzcDsg
Njc1MCBpcyBhYm91dCB0aGUgUlMuJm5ic3A7IFRoZSBkaXNjb3ZlcnkgZG9jdW1lbnQgaXMgYWJv
dXQgdGhlIEFTLiZuYnNwOyBXZSBkb27igJl0IHlldCBoYXZlIGEgc3BlY2lmaWNhdGlvbiBvciBl
eGlzdGluZyBwcmFjdGljZSBmb3IgUlMgZGlzY292ZXJ5LCB3aGljaCB3b3VsZCBiZSB0aGUgNjc1
MCBhbmFsb2d5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5JbiBzdW1tYXJ5LCB3aGljaCB0aXRsZSBkbyBwZW9wbGUgcHJlZmVyPzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPsK3Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnE9BdXRoIDIuMCBEaXNjb3ZlcnnigJ08bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT7CtyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBT
ZXJ2ZXIgRGlzY292ZXJ54oCdPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZsdDsmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+
RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmciPiZsdDttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+XSBP
biBCZWhhbGYgT2YgVmxhZGltaXIgRHpodXZpbm92PG86cD48L286cD48L3ByZT4NCjxwcmU+U2Vu
dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI1LCAyMDE2IDEyOjU5IEFNPG86cD48L286cD48L3ByZT4N
CjxwcmU+VG86IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8
L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpvYXV0aEBpZXRm
Lm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+U3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2Nh
dGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5J
biBPSURDIHRoZSBkaXNjb3ZlcnkgZG9jIGlzIG9mIGdyZWF0IHV0aWxpdHkgdG8gZGV2ZWxvcGVy
cyBhbmQgaW50ZWdyYXRvcnMuIERldmVsb3BlcnMgYWxzbyB0ZW5kIHRvIGZpbmQgaXQgYSBtb3Jl
IGFjY3VyYXRlIGFuZCBjb21wbGV0ZSBkZXNjcmlwdGlvbiBvZiBob3cgdG8gc2V0IHVwIGEgY2xp
ZW50IGZvciBhIHBhcnRpY3VsYXIgZGVwbG95bWVudCwgY29tcGFyZWQgdG8gdHJhZGl0aW9uYWwg
b25saW5lIGRvY3MsIHdoaWNoIG1heSBiZSBub3QgYmUgdXAgdG8gZGF0ZSwgb3IgZXZlbiBtaXNz
aW5nLiBWZXJ5IG11Y2ggbGlrZSBhdXRvLWdlbmVyYXRlZCBTd2FnZ2VyIGFuZCBKYXZhRG9jcy48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5IZXJl
IGFyZSBzb21lIGV4YW1wbGUgT0lEQyBkaXNjb3ZlcnkgZG9jczo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL2FjY291
bnRzLmdvb2dsZS5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24iPmh0dHBzOi8v
YWNjb3VudHMuZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbjwvYT4g
PGEgaHJlZj0iaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1j
b25maWd1cmF0aW9uIj4mbHQ7aHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxsLWtub3du
L29wZW5pZC1jb25maWd1cmF0aW9uJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5wYXlwYWxvYmpl
Y3RzLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiI+aHR0cHM6Ly93d3cucGF5
cGFsb2JqZWN0cy5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb248L2E+IDxhIGhy
ZWY9Imh0dHBzOi8vd3d3LnBheXBhbG9iamVjdHMuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25m
aWd1cmF0aW9uIj4mbHQ7aHR0cHM6Ly93d3cucGF5cGFsb2JqZWN0cy5jb20vLndlbGwta25vd24v
b3BlbmlkLWNvbmZpZ3VyYXRpb24mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbG9naW4ubWljcm9zb2Z0
b25saW5lLmNvbS9mYWJyaWthbWIyYy5vbm1pY3Jvc29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9v
cGVuaWQtY29uZmlndXJhdGlvbiI+aHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2Zh
YnJpa2FtYjJjLm9ubWljcm9zb2Z0LmNvbS92Mi4wLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1
cmF0aW9uPC9hPiA8YSBocmVmPSJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZmFi
cmlrYW1iMmMub25taWNyb3NvZnQuY29tL3YyLjAvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3Vy
YXRpb24iPiZsdDtodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZmFicmlrYW1iMmMu
b25taWNyb3NvZnQuY29tL3YyLjAvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24mZ3Q7
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPldpdGggdGhpcyBkaXNjb3ZlcnkgZG9jdW1l
bnQgaW4gcGxhY2Ugc2V0dXAgb2YgaWRlbnRpdHkgZmVkZXJhdGlvbiBjYW4gdGhlbiBiZSBlYXNp
bHkgc2NyaXB0ZWQuIEZvciBleGFtcGxlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHA6Ly9kb2NzLmF3cy5hbWF6b24uY29t
L0lBTS9sYXRlc3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVyc19jcmVhdGVfb2lkY192ZXJp
ZnktdGh1bWJwcmludC5odG1sIj5odHRwOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9JQU0vbGF0ZXN0
L1VzZXJHdWlkZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5LXRodW1icHJp
bnQuaHRtbDwvYT4gPGEgaHJlZj0iaHR0cDovL2RvY3MuYXdzLmFtYXpvbi5jb20vSUFNL2xhdGVz
dC9Vc2VyR3VpZGUvaWRfcm9sZXNfcHJvdmlkZXJzX2NyZWF0ZV9vaWRjX3ZlcmlmeS10aHVtYnBy
aW50Lmh0bWwiPiZsdDtodHRwOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9JQU0vbGF0ZXN0L1VzZXJH
dWlkZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5LXRodW1icHJpbnQuaHRt
bCZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Tm93LCBkb2VzIHRoYXQgZGljdGF0
ZSBhbnkgcGFydGljdWxhciBhcHAgYXJjaGl0ZWN0dXJlPyBNeSByZWFkaW5nIG9mIHRoZSBzcGVj
IGlzIHRoYXQgaXQgZG9lc24ndCwgYW5kIGl0IHNob3VsZG4ndCBlaXRoZXIuIEJ5IHN0YXlpbmcg
bmV1dHJhbCBvbiB0aGUgdG9waWNzIG9mIFJTIGRpc2NvdmVyeSBhbmQgcmVnaXN0ZXJpbmcgUlBz
IHdpdGggUlNzLiBBbmQgaG93IG9uZSBhcnJpdmVzIGF0IHRoZSAmcXVvdDsud2VsbC1rbm93bi8u
Li4mcXVvdDsuIEknbSBub3QgZXZlbiBzdXJlIHRoYXQgcmVzb3VyY2UgZGlzY292ZXJ5IHNob3Vs
ZCBiZSBhIHRvcGljIG9mIHRoaXMgV0cuIFBlcmhhcHMgdG8gdGhpcyBlbmQsIGFuZCB0byBwcmV2
ZW50IGNvbmZ1c2lvbiB0aGF0IHRoZSBzcGVjIGlzIHRyeWluZyB0byBkbyBzb21ldGhpbmcgbW9y
ZSwgYSBtb3JlIHNwZWNpZmljIHRpdGxlIHdvdWxkIHN1aXQgaXQgYmV0dGVyLiBFLmcuICZxdW90
O0FTIERpc2NvdmVyeSZxdW90Oy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5DaGVlcnMsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+VmxhZGltaXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5PbiAyNS8wMi8xNiAwMjoyNSwgUGhpbCBIdW50IChJRE0pIHdyb3RlOjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFuZCBzbyBkb2VzIG9yYWNs
ZSBhbmQgc28gZG9lcyBnb29nbGUuIEVhY2ggZGlmZmVyZW50LiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TbyBob3cgY2FuIGFuIGFwcCBkaWN0
YXRlIGl0IHRoZW4gdW5sZXNzIHdlIGFsbCBnbyB0byBhIGNvbW1vbiBhcmNoaXRlY3R1cmU/PG86
cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2
LCBhdCAxNjowNCwgTWlrZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tIj4mbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT4gPGEgaHJl
Zj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+Jmx0O21haWx0bzpNaWNoYWVs
LkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+QXp1cmUgZGVmaW5lcyB3YXlzIGZvciByZXNvdXJj
ZSBzZXJ2ZXJzIHRvIGJlIHJlZ2lzdGVyZWQgZm9yIHVzZSB3aXRoIGEgY2xpZW50IGFuZCBmb3Ig
Y2xpZW50cyB0byBkeW5hbWljYWxseSByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiBmb3IgdXNlIGF0
IGEgcGFydGljdWxhciByZXNvdXJjZSBzZXJ2ZXIuJm5ic3A7IFlvdSBjYW4gY2FsbCB0aGF0IGN1
c3RvbSBhcmNoaXRlY3R1cmUgaWYgeW91IHdhbnQuJm5ic3A7IEl04oCZcyB3ZWxsLWRlZmluZWQg
YnV0IGl04oCZcyBub3QgY3VycmVudGx5IGluIHRoZSBzdGFuZGFyZHMgcmVhbG0uJm5ic3A7IEkg
a25vdyB0aGF0IEdvb2dsZSBoYXMgc3ludGF4IGZvciBkb2luZyB0aGUgc2FtZSwgYXMgSeKAmW0g
c3VyZSBkbyBhIGxvdCBvZiBvdGhlciBjbG91ZCBPQXV0aCBkZXBsb3ltZW50cywgc3VjaCBhcyBP
cmFjbGXigJlzLiZuYnNwOyBGb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSB3b3JraW5nIGdyb3Vw
IHRhbGtlZCBhYm91dCBwb3NzaWJseSBwcm9kdWNpbmcgYSBzdGFuZGFyZCB2ZXJzaW9uIG9mIHN5
bnRheCBmb3IgbWFraW5nIHRoZXNlIGtpbmRzIG9mIHJlcXVlc3RzIGR1cmluZyBvdXIgZGlzY3Vz
c2lvbnMgaW4gUHJhZ3VlIChkdXJpbmcgdGhlIFRva2VuIEV4Y2hhbmdlIGRpc2N1c3Npb24pIGJ1
dCBub2JvZHkgaGFzIHJ1biB3aXRoIHRoaXMgeWV0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JbiB0aGlzIHNlbnNlLCB5ZXMsIEF6dXJlIGlzIGFuIGFw
cGxpY2F0aW9uIG9mIHRoZSBraW5kIHdl4oCZcmUgdGFsa2luZyBhYm91dC4mbmJzcDsgQXp1cmUg
YWxyZWFkeSBkb2VzIGRlZmluZSBzcGVjaWZpYyBuZXcgT0F1dGggMi4wIGRpc2NvdmVyeSBtZXRh
ZGF0YSB2YWx1ZXMgdGhhdCBhcmUgdXNlZCBpbiBwcm9kdWN0aW9uLiZuYnNwOyBBIHJlZ2lzdHJ5
IGp1c3QgZG9lc27igJl0IHlldCBleGlzdCBpbiB3aGljaCBpdCBjYW4gcmVnaXN0ZXIgdGhvc2Ug
dGhhdCBhcmUgb2YgZ2VuZXJhbCBhcHBsaWNhYmlsaXR5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDstLSBNaWtlPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkZyb206IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu
dEBvcmFjbGUuY29tIj5tYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+IDxhIGhyZWY9Im1h
aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bSZndDs8L2E+XSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBXZWRuZXNkYXksIEZlYnJ1
YXJ5IDI0LCAyMDE2IDM6NTIgUE08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UbzogTWlrZSBKb25l
czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v
cmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyI+Jmx0O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4N
CjxwcmU+U3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlv
bjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NaWtlPG86
cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRha2UgYSBsb29r
IGF0IHRoZSBhc3N1bXB0aW9ucyB5b3UgYXJlIG1ha2luZy4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+WW91IHNlZW0gdG8gYmUgYXNzdW1pbmcg
YXBwbGljYXRpb24gc29mdHdhcmUgZGljdGF0ZXMgb2F1dGggaW5mcmFzdHJ1Y3R1cmUgYXJjaGl0
ZWN0dXJlIGJ5IHN1Z2dlc3RpbmcgdGhhdCBhcHBzIHJlZ2lzdGVyIGluIGlhbmEuJm5ic3A7IDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldvdWxk
IG1zIGF6dXJlIGFsbG93IGN1c3RvbSBhcmNoPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5QaGlsPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9uIEZlYiAyNCwgMjAxNiwgYXQgMTU6MjgsIE1pa2UgSm9uZXMgPGEg
aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+Jmx0O01pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20iPiZsdDttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozwv
YT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlRoZSBVc2VySW5mbyBFbmRwb2ludCBwYXRoIGlzbuKAmXQgZml4ZWQgYW5kIHNvIGhhcyB0byBi
ZSBkaXNjb3ZlcmVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5JIGFncmVlIHRoYXQgZm9yIHNvbWUgT0F1dGggcHJvZmlsZXMsIG9uZSBvciBtb3JlIHJl
c291cmNlIHNlcnZlcnMgd2lsbCBoYXZlIHRvIGJlIGRpc2NvdmVyZWQgc3RhcnRpbmcgZnJvbSB0
aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuJm5ic3A7IFdvcmtpbmcgZ3JvdXAgbWVtYmVycyBoYXZl
IGFsc28gZGVzY3JpYmVkIHdhbnRpbmcgdG8gZGlzY292ZXIgYXV0aG9yaXphdGlvbiBzZXJ2ZXJz
IHN0YXJ0aW5nIGZyb20gcmVzb3VyY2Ugc2VydmVycy4mbmJzcDsgVGhlcmUgaXNu4oCZdCBhIHN0
YW5kYXJkIHByYWN0aWNlIGZvciBhbnkgb2YgdGhpcywgd2hpY2ggaXMgd2h5IGl04oCZcyBpbnRl
bnRpb25hbGx5IGxlZnQgb3V0IG9mIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24uPG86cD48L286
cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uY2UgdGhlIElBTkEgT0F1
dGggRGlzY292ZXJ5IE1ldGFkYXRhIFJlZ2lzdHJ5IGhhcyBiZWVuIGVzdGFibGlzaGVkLCB3aGlj
aCB3aWxsIGhhcHBlbiBhZnRlciB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFw
cHJvdmVkLCBpdCB3aWxsIGJlIGVhc3kgZm9yIHN1YnNlcXVlbnQgc3BlY2lmaWNhdGlvbnMgdG8g
ZG9jdW1lbnQgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIGRpZmZlcmVudCBPQXV0aCBwcm9maWxlcyBh
bmQgcmVnaXN0ZXIgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyBzdXBwb3J0aW5nIHRoZW0uJm5i
c3A7IFNvbWUgb2YgdGhvc2UgdmFsdWVzIHdpbGwgbGlrZWx5IGRlZmluZSB3YXlzIHRvIGRpc2Nv
dmVyIHJlc291cmNlIHNlcnZlcnMsIHdoZW4gYXBwbGljYWJsZS48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+QnV0IGZpcnN0LCB3ZSBuZWVkIHRvIGZpbmlz
aCB0aGUgZXhpc3Rpbmcgc3BlYywgc28gdGhhdCB0aGUgcmVnaXN0cnkgZW5hYmxpbmcgdGhlc2Ug
ZXh0ZW5zaW9ucyBnZXRzIGVzdGFibGlzaGVkIGluIHRoZSBmaXJzdCBwbGFjZS48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBQaGlsIEh1bnQgKElETSkgWzxhIGhyZWY9Im1h
aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9h
PiA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPiZsdDttYWlsdG86cGhpbC5o
dW50QG9yYWNsZS5jb20mZ3Q7PC9hPl0gPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogV2Vk
bmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAyOjEzIFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+
VG86IE1pa2UgSm9uZXMgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bSI+Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L2E+IDxhIGhyZWY9Im1haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPiZsdDttYWlsdG86TWljaGFlbC5Kb25lc0Bt
aWNyb3NvZnQuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogPGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPiA8YSBocmVm
PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9h
PiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8
L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpvYXV0aEBpZXRm
Lm9yZyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtPQVVUSC1X
R10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ZdXAuIEFuZCBiZWNhdXNlIHRoZXJlIG1hbnkgcmVsYXRp
b25zIHRoZSBjbGllbnQgbWlzdCBiZSBhYmxlIHRvIGRpc2NvdmVyIGl0LiBUaGUgY2xpZW50IGRv
ZXMgbm90IGtub3cgaWYgdGhlIHJlcyBzZXJ2ZXIgaXMgbGVnaXQuIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSB1c2VyaW5mbyBpcyBhbHdh
eXMgZml4IGFuZCBzbyB1IGRvbnQgbmVlZCBkaXNjb3ZlcnkuIDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAxNDowNSwg
TWlrZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj4m
bHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOk1p
Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+Jmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286
cD48L3ByZT4NCjxwcmU+SW4gT3BlbklEIENvbm5lY3QsIHRoZXJl4oCZcyBhIHJlc291cmNlIHNl
cnZlciBjYWxsZWQgdGhlIFVzZXJJbmZvIEVuZHBvaW50IHRoYXQgcmV0dXJucyBjbGFpbXMgYWJv
dXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlciBhcyBhIEpTT04gZGF0YSBzdHJ1Y3R1cmUuJm5ic3A7
IEl0cyBsb2NhdGlvbiBpcyBwdWJsaXNoZWQgaW4gT3BlbklEIENvbm5lY3QgZGlzY292ZXJ5IG1l
dGFkYXRhIGFzIHRoZSDigJx1c2VyaW5mb19lbmRwb2ludOKAnSBtZXRhZGF0YSB2YWx1ZSwgd2hp
Y2ggaXMgZGVmaW5lZCBhdCA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt
Y29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YSI+aHR0cDovL29wZW5p
ZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0
YWRhdGE8L2E+IDxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0
LWRpc2NvdmVyeS0xXzAuaHRtbCNQcm92aWRlck1ldGFkYXRhIj4mbHQ7aHR0cDovL29wZW5pZC5u
ZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0YWRh
dGEmZ3Q7PC9hPi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+V2UgZGlkbuKAmXQgaW5jbHVkZSB0aGUgVXNlckluZm8gRW5kcG9pbnQgaW4gdGhlIGdlbmVy
aWMgT0F1dGggZGlzY292ZXJ5IHNwZWMgc2luY2UgaW4gT0F1dGgsIHRoZXJlIGFyZSBsb3RzIG9m
IHBvc3NpYmxlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBhdXRob3JpemF0aW9uIHNlcnZlcnMgYW5k
IHJlc291cmNlIHNlcnZlcnMgYW5kIHRoZXkgbmVlZG7igJl0IGJlIG9uZS10by1vbmUsIGFzIGlz
IGJlaW5nIGFjdGl2ZWx5IGRpc2N1c3NlZCBieSB0aGUgd29ya2luZyBncm91cC4mbmJzcDsgRm9y
IGluc3RhbmNlLCBzZWUgR2VvcmdlIEZsZXRjaGVy4oCZcyByZWNlbnQgY29udHJpYnV0aW9uLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFua3MgZm9y
IHRoZSBnb29kIGRpc2N1c3Npb24sIFBoaWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOy0tIE1pa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+RnJvbTogUGhpbCBIdW50IChJRE0pIFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs
ZS5jb20iPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4gPGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIj4mbHQ7bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozwv
YT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQs
IDIwMTYgMToyNSBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBNaWtlIEpvbmVzPG86cD48
L286cD48L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0
O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4m
bHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5T
dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48
L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldoZXJlIGlzIHRoZSBw
cm9maWxlIGVuZHBvaW50IChvaWRjJ3MgcmVzb3VyY2Ugc2VydmVyKSBwdWJsaXNoZWQ/IChGb3Ig
dGhlIG5vbiBPSURDIHBlb3BsZSBvbiB0aGUgbGlzdCkuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAxMzowOSwgTWlr
ZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj4mbHQ7
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+Jmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m
dC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48
L3ByZT4NCjxwcmU+VG8gdGhlIGV4dGVudCB0aGF0IGdlbmVyaWMgT0F1dGggMi4wIG5lZWRzIHRv
IHB1Ymxpc2ggc29tZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBPcGVuSUQgQ29ubmVjdCDi
gJMgd2hpY2ggaXMgYnVpbHQgb24gZ2VuZXJpYyBPQXV0aCAyLjAg4oCTIGl0IG1ha2VzIHNlbnNl
IHRvIHB1Ymxpc2ggdGhhdCBpbmZvcm1hdGlvbiB1c2luZyBleGFjdGx5IHRoZSBzYW1lIHN5bnRh
eCwgc2luY2UgdGhhdCBzeW50YXggaXMgYWxyZWFkeSBpbiB3aWRlc3ByZWFkIHVzZS4mbmJzcDsg
VGhhdCB3aGF0IHRoaXMgZHJhZnQgYWNjb21wbGlzaGVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGVyZeKAmXMgbm90aGluZyBDb25uZWN0LXNwZWNp
ZmljIGFib3V0IHVzaW5nIG1ldGFkYXRhIHJlc3BvbnNlIHZhbHVlcyBsaWtlOjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm
cXVvdDthdXRob3JpemF0aW9uX2VuZHBvaW50JnF1b3Q7OiA8YSBocmVmPSJodHRwczovL3NlcnZl
ci5leGFtcGxlLmNvbS9hdXRob3JpemUiPiZxdW90O2h0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29t
L2F1dGhvcml6ZSZxdW90OzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20v
YXV0aG9yaXplIj4mbHQ7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplJmd0Ozwv
YT4sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZxdW90O3Rva2VuX2VuZHBv
aW50JnF1b3Q7OiA8YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiI+JnF1
b3Q7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4mcXVvdDs8L2E+IDxhIGhyZWY9Imh0
dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIj4mbHQ7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
ZS5jb20vdG9rZW4mZ3Q7PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
JnF1b3Q7dG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCZxdW90OzogWyZxdW90
O2NsaWVudF9zZWNyZXRfYmFzaWMmcXVvdDssICZxdW90O3ByaXZhdGVfa2V5X2p3dCZxdW90O10s
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZxdW90O3JlZ2lzdHJhdGlvbl9l
bmRwb2ludCZxdW90OzogPGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0
ZXIiPiZxdW90O2h0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyJnF1b3Q7PC9hPiA8
YSBocmVmPSJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdpc3RlciI+Jmx0O2h0dHBzOi8v
c2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyJmd0OzwvYT4sPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7ICZxdW90O3Jlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCZxdW90OzombmJz
cDsgWyZxdW90O2NvZGUmcXVvdDssICZxdW90O3Rva2VuJnF1b3Q7XSw8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1b3Q7c2VydmljZV9kb2N1bWVudGF0aW9uJnF1b3Q7OiA8
YSBocmVmPSJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5o
dG1sIj4mcXVvdDtodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlv
bi5odG1sJnF1b3Q7PC9hPiA8YSBocmVmPSJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZp
Y2VfZG9jdW1lbnRhdGlvbi5odG1sIj4mbHQ7aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2
aWNlX2RvY3VtZW50YXRpb24uaHRtbCZndDs8L2E+LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JcyB0aGVyZSBhIHJlYXNvbiB0aGF0IHlvdSB3b3VsZCBs
aWtlIHRoZSBzeW50YXggZm9yIGFueSBvZiB0aGVzZSBvciB0aGUgb3RoZXIgZ2VuZXJhbGx5IGFw
cGxpY2FibGUgT0F1dGggMi4wIG1ldGFkYXRhIHZhbHVlcyB0byBiZSBkaWZmZXJlbnQ/Jm5ic3A7
IEkgZG9u4oCZdCBzZWUgYW55IGdvb2QgcmVhc29uIGZvciB1bm5lY2Vzc2FyeSBkaWZmZXJlbmNl
cyB0byBiZSBpbnRyb2R1Y2VkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBN
aWtlPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206
IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5t
YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208L2E+IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA
b3JhY2xlLmNvbSI+Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8L2E+XSA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEy
OjQ1IFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IEFudGhvbnkgTmFkYWxpbiA8YSBocmVm
PSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj4mbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29t
Jmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+Jmx0O21haWx0
bzp0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNj
OiBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i
PiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj4mbHQ7bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPiZsdDtv
YXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0
O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIj4mbHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0
aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1pa2U8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+UHVibGlzaGlu
ZyBvbiBkZXYgcGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29mdHdhcmUgKGVzcCBvcGVuIHNvdXJj
ZSkgdGhhdCBpcyBkZXBsb3llZCBib3RoIGluIGVudGVycHJpc2VzIGFuZCBvbiBQYWFTIGNsb3Vk
IHByb3ZpZGVycy4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+VGhlIGN1cnJlbnQgZHJhZnQgaXMgbWF5IGNvZGlmeSBjdXJyZW50IE9JREMgcHJh
Y3RpY2UgYW5kIGJlIGFwcHJvcHJpYXRlIGZvciBvaWRjIGJ1dCBpdCBpcyBub3QgcmVhZHkgZm9y
IGdlbmVyaWMgb2F1dGguIFRoZXJlIGlzIG5vIGdlbmVyaWMgb2F1dGggZXhwZXJpZW5jZSBhdCB0
aGlzIHRpbWUuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+T24gRmViIDI0LCAyMDE2LCBhdCAxMDoyNSwgQW50aG9ueSBOYWRhbGluIDxhIGhyZWY9Im1h
aWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPiZsdDt0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7
PC9hPiA8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj4mbHQ7bWFpbHRvOnRv
bnluYWRAbWljcm9zb2Z0LmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdXJlIHRoZXJlIGlzLCBpdCBpcyBhcyB5b3UgaGF2
ZSBub3cgbWFkZSBpdCBmYXIgZWFzaWVyIGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg
ZG9lcyBub3QgZXZlbiBhZGRyZXNzIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48
L286cD48L3ByZT4NCjxwcmU+RnJvbTogTWlrZSBKb25lcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDEwOjIyIEFNPG86cD48L286cD48
L3ByZT4NCjxwcmU+VG86IEFudGhvbnkgTmFkYWxpbiA8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBt
aWNyb3NvZnQuY29tIj4mbHQ7dG9ueW5hZEBtaWNyb3NvZnQuY29tJmd0OzwvYT4gPGEgaHJlZj0i
bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+Jmx0O21haWx0bzp0b255bmFkQG1pY3Jvc29m
dC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86
b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1haWx0
bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhy
ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEg
aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4mbHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0
OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSRTogW09BVVRILVdHXSBPQXV0
aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkFzIHdl4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMg
bm8gZWZmZWN0aXZlIHNlY3VyaXR5IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3Jt
YXRpb24gYmVpbmcgcHVibGlzaGVkIGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBw
YWdlcyBhbmQgaXQgYmVpbmcgcHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiZuYnNwOyDi
gJxTZWN1cml0eSBieSBvYnNjdXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0g
TWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9t
OiBBbnRob255IE5hZGFsaW4gPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogV2VkbmVzZGF5
LCBGZWJydWFyeSAyNCwgMjAxNiAxMDowMSBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBN
aWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPiZs
dDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj4mbHQ7bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbSZndDs8L2E+OyBQaGlsIEh1bnQgKElETSkgPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu
dEBvcmFjbGUuY29tIj4mbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PC9hPiA8YSBocmVmPSJt
YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPiZsdDttYWlsdG86cGhpbC5odW50QG9yYWNsZS5j
b20mZ3Q7PC9hPjsgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20iPiZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86c2FraW11
cmFAZ21haWwuY29tIj4mbHQ7bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSZndDs8L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0
O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4m
bHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhA
aWV0Zi5vcmciPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9j
YXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhl
IHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRp
c2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGF0IG1heSBi
ZSB3aWRlbHkgZGVwbG95ZWQgZm9yIE9JREMgYnV0IG5vdCB3aWRlbHkgZGVwbG95ZWQgZm9yIE9B
dXRoLiBUaGVyZSBhcmUgc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZGlzY292ZXJ5IGZv
ciBlbmRwb2ludCB0aGF0IHJlYWxseSBzaG91bGQgbm90IGJlIGluIGFuIE9BdXRoIHN0YW5kYXJk
IHNpbmNlIGl04oCZcyByZWFsbHkgbm90IGRlYWx0IHdpdGguIE5vdyB0aGF0IGFsbCB0aGlzIGlu
Zm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpdCBtYWtlcyBwb2tpbmcgYXJvdW5kIHRoZSBlbmRwb2lu
dCBtb3JlIGZvY3VzZWQgZm9yIHBlb3BsZSB0aGF0IHdhbnQgdG8gZGlzcnVwdCB5b3VyIGVuZHBv
aW50cywgdGhhdCBpcyByZWFsbHkgbm90IGFkZHJlc3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lk
ZXJhdGlvbnMmbmJzcDsgc2VjdGlvbiBhdCBhbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86
cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJl
Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPiZsdDttYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZyZndDs8L2E+XSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lczxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMTYgOTo1NCBBTTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBQaGlsIEh1bnQgKElETSkgPGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIj4mbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PC9hPiA8YSBo
cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPiZsdDttYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20mZ3Q7PC9hPjsgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb20iPiZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86
c2FraW11cmFAZ21haWwuY29tIj4mbHQ7bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSZndDs8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu
b3JnIj4mbHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0OzwvYT4gPGEgaHJlZj0ibWFpbHRvOm9h
dXRoQGlldGYub3JnIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86
b2F1dGhAaWV0Zi5vcmciPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3Zl
cnkgTG9jYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+VGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBj
b3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxv
eWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ob25l
IG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhZGRpdGlvbmFsIHJlbGF0
ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0ZWQuJm5ic3A7IEnigJltIHN1cmUgaXQg
d2lsbCBiZS4mbmJzcDsgU29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2UgV2ViRmluZ2VyIHRvIGxv
Y2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiZuYnNwOyBTb21lIHdpbGwgcG9zc2libHkgdXNl
IGxpbmsgaGVhZGVycy4mbmJzcDsgU29tZSB3aWxsIHBvc3NpYmx5IHVzZSBhcHBsaWNhdGlvbi1z
cGVjaWZpYyAud2VsbC1rbm93biB2YWx1ZXMuJm5ic3A7IEnigJltIHN1cmUgdGhlcmXigJlzIG90
aGVyIHRoaW5ncyBJIGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuJm5ic3A7IEFsbCBvZiB0
aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgZm9y
bWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0aGFuIHBvc3NpYmx5IHRv
IHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcy48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+U28gYnkgYWxsIG1lYW5zLCB0
aGUgd29ya2luZyBncm91cCBzaG91bGQgY29udGludWUgZGlzY3Vzc2luZyBpbnZlbnRpbmcgcG9z
c2libGUgbmV3IHJlbGF0ZWQgbWVjaGFuaXNtcyB0aGF0IG1ha2Ugc2Vuc2UgaW4gc29tZSBjb250
ZXh0cy4mbmJzcDsgQXQgdGhlIHNhbWUgdGltZSwgd2UgY2FuIGZpbmlzaCBzdGFuZGFyZGl6aW5n
IHRoZSBhbHJlYWR5IHdpZGVseSBkZXBsb3llZCBjb3JlIGZ1bmN0aW9uYWxpdHkgdGhhdCBhbGwg
b2YgdGhlc2UgbWVjaGFuaXNtcyB3aWxsIG5lZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tIE1pa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4g
PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPiZsdDttYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZyZndDs8L2E+XSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50IChJRE0pPG86
cD48L286cD48L3ByZT4NCjxwcmU+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4
OjM5IEFNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IE5hdCBTYWtpbXVyYSA8YSBocmVmPSJt
YWlsdG86c2FraW11cmFAZ21haWwuY29tIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzwvYT4g
PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+Jmx0O21haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWls
dG86b2F1dGhAaWV0Zi5vcmciPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxhIGhyZWY9Im1h
aWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8L2E+IDxh
IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+Jmx0O29hdXRoQGlldGYub3JnJmd0OzwvYT4g
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4mbHQ7bWFpbHRvOm9hdXRoQGlldGYub3Jn
Jmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBP
QXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkkgYW0gc3VnZ2VzdGluZyB0aGF0IHBhcnQgb2YgdGhlIGRpc2Nv
dmVyeSBzb2x1dGlvbiBoYXMgdG8gYmUgdGhlIGNsaWVudCBpbmRpY2F0aW5nIHdoYXQgcmVzb3Vy
Y2UgZW5kcG9pbnQgaXQgd2FudHMgdGhlIG9hdXRoIGNvbmZpZ3VyYXRpb24gZGF0YSBmb3IuIDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvIGlm
IHJlcy5leGFtcGxlLmV2aWwuY29tIDxhIGhyZWY9Imh0dHA6Ly9yZXMuZXhhbXBsZS5ldmlsLmNv
bS8iPiZsdDtodHRwOi8vcmVzLmV4YW1wbGUuZXZpbC5jb20vJmd0OzwvYT4gaXMgbm90IGEgdmFs
aWQgcmVzb3VyY2UgZW5kcG9pbnQgZm9yIGFzLmV4YW1wbGUuY29tIDxhIGhyZWY9Imh0dHA6Ly9h
cy5leGFtcGxlLmNvbS8iPiZsdDtodHRwOi8vYXMuZXhhbXBsZS5jb20vJmd0OzwvYT4gdGhlIGF1
dGh6IGRpc2NvdmVyeSBzaG91bGQgZmFpbCBpbiBzb21lIHdheSAoZWcgcmV0dXJuIG5vdGhpbmcp
LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5U
aGVyZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8gZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3Zlcnku
IE9yIGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlzY292ZXJ5LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbmUgb2YgT0F1dGgncyBzdHJlbmd0aCdz
IGFuZCB3ZWFrbmVzc2VzIGlzIHRoYXQgdGhlIHRhcmdldCBvZiBhdXRob3JpemF0aW9uICh0aGUg
cmVzb3VyY2UpIGlzIG5ldmVyIHNwZWNpZmllZC4gSXQgaXMgb2Z0ZW4gYm91bmQgdXAgaW4gdGhl
IGNsaWVudCByZWdpc3RyYXRpb24gYW5kIGFuIG9mdGVuIGltcGxpZWQgMToxIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHJlc291cmNlIGFuZCBhcy4gR2l2ZW4gdGhhdCBpbiBkaXNjb3ZlcnkgcGhhc2Ug
cmVnaXN0cmF0aW9uIGhhcyBub3QgeWV0IG9jY3VycmVkIGl0IHNlZW1zIGltcG9ydGFudCB0aGF0
IHRoZSBjbGllbnQga25vdyBpdCBoYXMgYSB2YWxpZCBjb21iaW5hdGlvbiBvZiBlbmRwb2ludHMg
ZXRjLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5UaGlzIGlzIHdoeSBJIHdhcyBkaXNhcHBvaW50ZWQgYWJvdXQgd2dsYyBvbiBkaXNjb3Zlcnku
IFdlIGhhZCBhIHN0YXJ0aW5nIHBvaW50IGZvciBncm91cCBhZG9wdGlvbiBidXQgd2UgaGF2ZW4n
dCByZWFsbHkgZGVmaW5lZCB0aGUgZnVsbCByZXF1aXJlbWVudHMgSU1PLiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGFtIG9uIHZhY2F0aW9u
IG9yIEkgd291bGQgcHV0IHNvbWUgdGhvdWdodCBpbnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBh
IG5ldyBkcmFmdC4gSSBhcG9sb2dpemUgSSBjYW4ndCBkbyBpdCBub3cuIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBoaWw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAw
ODoxMiwgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPiZs
dDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PC9hPiA8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21h
aWwuY29tIj4mbHQ7bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IaSBQaGlsLCA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcmUgeW91
IHN1Z2dlc3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUgdGhlIFJTIFVS
SXM/IEN1cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwgSSBndWVzcy4g
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhl
IHdheSBvYXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+MS4gUlMgdGVsbHMgdGhlIGNsaWVudCB3aGVyZSB0
aGUgQVMgaXMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjIuIEFTIHRlbGxzIHRoZSBjbGllbnQg
d2hpY2ggUlMgZW5kcG9pbnRzIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+RXZlbiBpZiB0aGVyZSBpcyBh
IGJhZCBBUyB3aXRoIGEgdmFsaWQgY2VydHMgdGhhdCBwcm94aWVzIHRvIHRoZSBnb29kIFJTLCB0
aGUgY2xpZW50IHdpbGwgbm90IHNlbmQgdGhlIHRva2VuIHRoZXJlIGFzIHRoZSBhdXRoeiBzZXJ2
ZXIgd2lsbCBzYXkgdGhhdCBpcyBub3QgdGhlIHBsYWNlIHRoZSBjbGllbnQgbWF5IHdhbnQgdG8g
c2VuZCB0aGUgdG9rZW4gdG8uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk5hdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3Ro
aWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjQ8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
l6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1
b3Q7LHNhbnMtc2VyaWYiPuawtDwvc3Bhbj4pIDIzOjU5IFBoaWwgSHVudCA8YSBocmVmPSJtYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb20iPiZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8L2E+
IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+Jmx0O21haWx0bzpwaGlsLmh1
bnRAb3JhY2xlLmNvbSZndDs8L2E+OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5hdCw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+SeKAmW0gbm90IHN1cmUg
dGhhdCBoYXZpbmcgdGhlIHJlc291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRz
IGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNo
aXAgYmV0d2VlbiB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2
ZXIgbmVlZCB0byBiZSBib3VuZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRw
b2ludHMgKHRoZSByZXNvdXJjZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgYSBjbGll
bnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94eWluZyBmb3Ig
YSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3BlYyB3aWxsIG5v
dCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25nIHJlc291cmNl
IHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBqdXN0IGhhdmUg
YSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50ZXJjZXB0IHJl
c291cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdlcmUgYWJsZSB0
byBjb252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXphdGlvbiBzZXJ2
aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHkuPG86cD48L286
cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBPQXV0aCBEaXNjb3Zl
cnkgc2VydmljZSBuZWVkcyB0byBjb25maXJtIHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgc2VydmVy
IGlzIGFibGUgdG8gaXNzdWUgdG9rZW5zIGZvciBhIHN0YXRlZCByZXNvdXJjZSBlbmRwb2ludC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBub3Qg
b25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGggYnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0
byBVTUEgc2l0dWF0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+UGhpbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHA6
Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT4gPGEgaHJl
Zj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8iPiZsdDtodHRwOi8vd3d3LmluZGVwZW5k
ZW50aWQuY29tLyZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv
OnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4gPGEgaHJlZj0i
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj4mbHQ7bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu
Y29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+T24gRmViIDI0LCAyMDE2LCBhdCAzOjU0IEFNLCBOYXQgU2FraW11cmEgPGEgaHJl
Zj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+Jmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDs8
L2E+IDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPiZsdDttYWlsdG86c2FraW11
cmFAZ21haWwuY29tJmd0OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhpIFRob21h
cywgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
aW5saW5lOiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVv
dDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjI8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3Nw
YW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNh
bnMtc2VyaWYiPuaciDwvc3Bhbj4pIDE4OjQ0IFRob21hcyBCcm95ZXIgPGEgaHJlZj0ibWFpbHRv
OnQuYnJveWVyQGdtYWlsLmNvbSI+Jmx0O3QuYnJveWVyQGdtYWlsLmNvbSZndDs8L2E+IDxhIGhy
ZWY9Im1haWx0bzp0LmJyb3llckBnbWFpbC5jb20iPiZsdDttYWlsdG86dC5icm95ZXJAZ21haWwu
Y29tJmd0OzwvYT46PG86cD48L286cD48L3ByZT4NCjxwcmU+Q291bGRuJ3QgdGhlIGRvY3VtZW50
IG9ubHkgZGVzY3JpYmUgdGhlIG1ldGFkYXRhPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgcXVp
dGUgbGlrZSB0aGUgaWRlYSBvZiBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIGlmIHlvdSByZWFs
bHkgd2FudCB0byBkbyBkaXNjb3ZlcnksIGFuZCBsZWF2ZSBpdCBvcGVuIHRvIGltcGxlbWVudGVy
cyAvIHRvIG90aGVyIHNwZWNzIHRvIGRlZmluZSBhIC53ZWxsLWtub3duIFVSTCBmb3IgJnF1b3Q7
YXV0by1jb25maWd1cmF0aW9uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBtZXRh
ZGF0YSBkZXNjcmliZWQgaGVyZSB3b3VsZCB0aGVuIGVpdGhlciBiZSB1c2VkIGFzLWlzLCBhdCBh
bnkgVVJMLCByZXR1cm5lZCBhcyBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhIG1ldGFkYXRhIGF0
IHRoZSBSUzsgb3IgYXMgYSBiYXNpcyBmb3Igb3RoZXIgbWV0YWRhdGEgc3BlY3MgKGxpa2UgT3Bl
bklEIENvbm5lY3QpLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XaXRoIGRyYWZ0LXNha2ltdXJh
LW9hdXRoLW1ldGEncyAmcXVvdDtkdXJpJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsg
YXR0cmlidXRlIG9mIFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBl
dmVyeXRoaW5nIHlvdSBuZWVkIHRvIHByb2NlZWQgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+WXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1aXJl
bWVudHMgdG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90PyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JbiBPQXV0aCdzIGNhc2UsIHRoZSBy
ZXNvdXJjZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSB1c3VhbGx5IHRpZ2h0bHkg
Y291cGxlZC4gKE90aGVyd2lzZSwgeW91IG5lZWQgYW5vdGhlciBzcGVjcyBsaWtlIFVNQS4pIDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHNob3VsZCBiZSBh
YmxlIHRvIHRlbGwgZWl0aGVyIHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogZW5kcG9pbnQuIElu
IHNvbWUgdHJ1c3RlZCBlbnZpcm9ubWVudCwgdGhlIHJlc291cmNlIG1heSBhcyB3ZWxsIHJldHVy
biB0aGUgbG9jYXRpb24gb2YgdGhlIGF1dGh6IHNlcnZlciBjb25maWd1cmF0aW9uIGRhdGEuIElu
IHRoZXNlIGNhc2VzLCB5b3UgZG8gbm90IGhhdmUgdG8gZGVjaWRlIG9uIHdoYXQgLndlbGwta25v
d24gdXJpIGFzIHlvdSBzYXkuIFRoaXMgZnJlZXMgdXAgZGV2ZWxvcGVycyBmcm9tIGNvbmZpZ3Vy
YXRpb24gZmlsZSBsb2NhdGlvbiBjb2xsaXNpb25zIGV0Yy4gV2Ugc2hvdWxkIHN0cml2ZSBub3Qg
dG8gcG9sbHV0ZSB0aGUgdXJpIHNwYWNlIGFzIG11Y2ggYXMgcG9zc2libGUuIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPih3ZWxsLCBleGNlcHQg
aWYgdGhlcmUgYXJlIHNldmVyYWwgQVNzIGVhY2ggd2l0aCBkaWZmZXJlbnQgc2NvcGVzOyBzb3Vu
ZHMgbGlrZSBhbiBlZGdlLWNhc2UgdG8gbWUgdGhvdWdoOyBtYXliZSBSRkM2NzUwIHNob3VsZCBp
bnN0ZWFkIGJlIHVwZGF0ZWQgd2l0aCBzdWNoIGEgcGFyYW1ldGVyIHN1Y2ggdGhhdCBhbiBSUyBj
b3VsZCByZXR1cm4gc2V2ZXJhbCBXV1ctQXV0aGVudGljYXRlOiBCZWFyZXIsIGVhY2ggd2l0aCBp
dHMgb3duICZxdW90O3Njb3BlJnF1b3Q7IGFuZCAmcXVvdDtkdXJpJnF1b3Q7IHZhbHVlPyk8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+WWVhaCwgSSBndWVz
cyBpdCBpcyBhbiBlZGdlIGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1
dGh6IHNlcnZlcnMgdG8gZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5
IGNhbiBhZ3JlZSBvbiBhIHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlciB2YWx1
ZXMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkNoZWVycywgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+TmF0PG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDEwOjU5IFBNIEp1c3RpbiBSaWNoZXIgPGEgaHJl
Zj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+Jmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8L2E+IDxh
IGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiPiZsdDttYWlsdG86anJpY2hlckBtaXQuZWR1
Jmd0OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIG5ld2x5LXRyaW1tZWQg
T0F1dGggRGlzY292ZXJ5IGRvY3VtZW50IGlzIGhlbHBmdWwgYW5kIG1vdmluZyBpbiB0aGUgcmln
aHQgZGlyZWN0aW9uLiBJdCBkb2VzLCBob3dldmVyLCBzdGlsbCBoYXZlIHRvbyBtYW55IHZlc3Rp
Z2VzIG9mIGl0cyBPcGVuSUQgQ29ubmVjdCBvcmlnaW5zLiBPbmUgaXNzdWUgaW4gcGFydGljdWxh
ciBzdGlsbCByZWFsbHkgYm90aGVycyBtZTogdGhlIHVzZSBvZiDigJwvLndlbGwta25vd24vb3Bl
bmlkLWNvbmZpZ3VyYXRpb27igJ0gaW4gdGhlIGRpc2NvdmVyeSBwb3J0aW9uLiBJcyB0aGlzIGFu
IE9BdXRoIGRpc2NvdmVyeSBkb2N1bWVudCwgb3IgYW4gT3BlbklEIENvbm5lY3Qgb25lPyBUaGVy
ZSBpcyBhYnNvbHV0ZWx5IG5vIGNvbXBlbGxpbmcgcmVhc29uIHRvIHRpZSB0aGUgVVJMIHRvIHRo
ZSBPSURDIGRpc2NvdmVyeSBtZWNoYW5pc20uPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24v
b2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxv
Y2F0aW9uLCBhbmQgc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxl
IGZyb20g4oCcLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2
ZXIgYWxzbyBwcm92aWRlcyBPcGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVy
IGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNj
cmliZSBPQXV0aCBlbmRwb2ludHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1z
cGVjaWZpYyBkaXNjb3ZlcnkgZG9jdW1lbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+IDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+IDxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8
L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCI+Jmx0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFp
bGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll
dGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
Ij4mbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPiA8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj4mbHQ7aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCZndDs8L2E+PG86cD48L286cD48L3By
ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h
PiA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPiZsdDttYWlsdG86T0F1dGhAaWV0Zi5v
cmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgiPiZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h
PiA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPiZsdDttYWlsdG86T0F1dGhAaWV0Zi5v
cmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgiPiZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu
b3JnPC9hPiA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPiZsdDttYWlsdG86T0F1dGhA
aWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiPiZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLSA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1pciBEemh1dmlub3YgOjogPGEgaHJlZj0ibWFpbHRv
OnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4gPGEg
aHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIj4mbHQ7bWFpbHRvOnZsYWRpbWly
QGNvbm5lY3QyaWQuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyI+Jmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8L2E+PG86cD48L286
cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv
YT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+
Jmx0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgmZ3Q7PC9hPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0
PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P
QXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv
dGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BY2PR03MB4428901D4BA97135B5AAF47F5B80BY2PR03MB442namprd_--


From nobody Sat Feb 27 10:57:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA221B2AF8 for ; Sat, 27 Feb 2016 10:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtapDb4bDb6n for ; Sat, 27 Feb 2016 10:57:31 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18421B2AEF for ; Sat, 27 Feb 2016 10:57:30 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1RIvNdt018766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Feb 2016 18:57:24 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1RIvNqF013111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 27 Feb 2016 18:57:23 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1RIvMHo021716; Sat, 27 Feb 2016 18:57:22 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Feb 2016 10:57:21 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_53923C8C-4224-4A2F-AC6D-AA5D623F8C74"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Sat, 27 Feb 2016 10:57:19 -0800
Message-Id: 
References:    <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>    <56D1EBC4.404090! 7@connect2id.com> 
To: Mike Jones 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 18:57:40 -0000

--Apple-Mail=_53923C8C-4224-4A2F-AC6D-AA5D623F8C74
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

To clarify=E2=80=A6. I am not suggesting that we need a resource =
discovery mechanism.

What I am suggesting is much simpler.

I propose that the authorization confirm that the endpoint that the =
client has discovered is a resource that the AS can issue tokens for (in =
other words is a valid audience for the tokens).

This will work well in UMA cases and it confirms the relationship =
between the AS and the RS is in fact valid.
It also detects mis-configuration cases that might naturally occur in =
scenarios with multi-tenancies etc.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Feb 27, 2016, at 10:38 AM, Mike Jones  =
wrote:
>=20
> Thanks for taking the time to propose specific text, Phil.  That=E2=80=99=
s really helpful.  I=E2=80=99ll plan to incorporate a version of this in =
the draft addressing WGLC comments.
> =20
> I agree with Vladimir=E2=80=99s observation that it=E2=80=99s =
difficult to come up with a general-purpose resource discovery =
mechanism.  That in part, is because, as Brian points out, there=E2=80=99s=
 often not a 1:1 relationship between authorization servers and resource =
servers.  As I=E2=80=99ve written before, I do encourage the working =
group to work on creating solutions to resource discovery that will work =
for some common use cases.  But the good news is that while resource =
discovery requires new invention, authorization server discovery does =
not.
> =20
>                                                          -- Mike
> =C2=A0 <>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir =
Dzhuvinov
> Sent: Saturday, February 27, 2016 10:33 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> =20
>=20
> On 27/02/16 20:10, Phil Hunt wrote:
> The name change seems appropriate given that the WG members have =
decided not to address the issue of resource discovery as part of this =
specification.
> =20
> If the consensus is to limit the scope of the specification, then I =
suggest the following security considerations text.
> =20
> Resource Discovery
> =20
> Secure discovery of resource endpoints is out-of-scope of this =
specification. This specification assumes that the client has already =
securely discovered the correct resource endpoint and that the client =
has correctly selected the correct corresponding discovery for OAuth =
Authorization server. Implementers MUST consider that if an incorrect =
resource endpoint was discovered by the client that an attacker will be =
able to set up a man-in-the-middle proxy to a real resource server =
without detection by the authorization server or the client.=20
>=20
> I support that. This was the primary concern of everyone who felt =
uncomfortable with the original draft with WebFinger-based discovery in =
it, so it should be included.
>=20
>=20
>=20
>=20
> =20
> It may be more appropriate to even include this text in the =
introduction as a cautionary "red flag" to implementers.
> +1
>=20
>=20
> =20
> =20
> Once again, I strongly urge the WG to actually include a method for =
the client to discovery that the oauth cliet has correctly discovered an =
authorization server that is willing and able to issue access tokens for =
a given resource endpoint. I believe this relationship is critical to =
security of OAuth in cases where resource endpoints are discovered =
dynamically.  Of course willing and able means that the AS believes that =
the endpoint is legitimate.
>=20
> The more I think about this topic, the more pessimistic I get that =
there is a good solution to this :)
>=20
> Vladimir
>=20
>=20
>=20
> =20
> =20
> Phil
> =20
> @independentid
> www.independentid.com  =
 =
phil.hunt@oracle.com =
  =

> =20
> =20
> =20
> =20
> =20
> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman  =
 wrote:
> =20
> +1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
> =20
> //Samuel
> =20
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones =
 =
 =
> wrote:
> Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined =
to accept your suggestion to change the title from =E2=80=9COAuth 2.0 =
Discovery=E2=80=9D to =E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D.  While the abstract already makes it clear that the =
scope of the document is AS discovery, doing so in the title seems like =
it could help clarify things, given that a lot of the discussion seems =
to be about resource discovery, which is out of scope of the document.
> =20
> =20
> =20
> I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93 but unlike authorization server discovery, =
where there=E2=80=99s lots of existing practice, including using the =
existing data format for describing OAuth implementations that aren=E2=80=99=
t being used with OpenID Connect, there=E2=80=99s no existing practice =
to standardize for resource discovery.  The time to create a standard =
for that seems to be after existing practice has emerged.  It *might* or =
might not use new metadata values in the AS discovery document, but =
that=E2=80=99s still to be determined.  The one reason to leave the =
title as-is is that resource discovery might end up involving extensions =
to this metadata format in some cases.
> =20
> =20
> =20
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 =
applies.  6749 is about the AS.  6750 is about the RS.  The discovery =
document is about the AS.  We don=E2=80=99t yet have a specification or =
existing practice for RS discovery, which would be the 6750 analogy.
> =20
> =20
> =20
> In summary, which title do people prefer?
> =20
> =C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
> =20
> =C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
> =20
> =20
> =20
>                                                           -- Mike
> =20
>   <>
> From: OAuth [mailto:oauth-bounces@ietf.org =
  =
] On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: oauth@ietf.org   =

> =20
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> =20
> =20
> In OIDC the discovery doc is of great utility to developers and =
integrators. Developers also tend to find it a more accurate and =
complete description of how to set up a client for a particular =
deployment, compared to traditional online docs, which may be not be up =
to date, or even missing. Very much like auto-generated Swagger and =
JavaDocs.
> =20
> Here are some example OIDC discovery docs:
> =20
> https://accounts.google.com/.well-known/openid-configuration =
 =
 =

> =20
> https://www.paypalobjects.com/.well-known/openid-configuration =
 =
 =

> =20
> =
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-k=
nown/openid-configuration =
 =
 =

> =20
> =20
> With this discovery document in place setup of identity federation can =
then be easily scripted. For example:
> =20
> =
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_=
oidc_verify-thumbprint.html =
 =
 =

> =20
> =20
> Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one =
arrives at the ".well-known/...". I'm not even sure that resource =
discovery should be a topic of this WG. Perhaps to this end, and to =
prevent confusion that the spec is trying to do something more, a more =
specific title would suit it better. E.g. "AS Discovery".
> =20
> Cheers,
> =20
> Vladimir
> =20
> =20
> =20
> =20
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> =20
> And so does oracle and so does google. Each different.=20
> =20
> So how can an app dictate it then unless we all go to a common =
architecture?
> =20
> Phil
> =20
> On Feb 24, 2016, at 16:04, Mike Jones  =
 =
 =
 wrote:
> =20
> Azure defines ways for resource servers to be registered for use with =
a client and for clients to dynamically request an access token for use =
at a particular resource server.  You can call that custom architecture =
if you want.  It=E2=80=99s well-defined but it=E2=80=99s not currently =
in the standards realm.  I know that Google has syntax for doing the =
same, as I=E2=80=99m sure do a lot of other cloud OAuth deployments, =
such as Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working =
group talked about possibly producing a standard version of syntax for =
making these kinds of requests during our discussions in Prague (during =
the Token Exchange discussion) but nobody has run with this yet.
> =20
> In this sense, yes, Azure is an application of the kind we=E2=80=99re =
talking about.  Azure already does define specific new OAuth 2.0 =
discovery metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
  =
]=20
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Take a look at the assumptions you are making.=20
> =20
> You seem to be assuming application software dictates oauth =
infrastructure architecture by suggesting that apps register in iana. =20=

> =20
> Would ms azure allow custom arch?
> =20
> Phil
> =20
> On Feb 24, 2016, at 15:28, Mike Jones  =
 =
 =
 wrote:
> =20
> The UserInfo Endpoint path isn=E2=80=99t fixed and so has to be =
discovered.
> =20
> I agree that for some OAuth profiles, one or more resource servers =
will have to be discovered starting from the authorization server.  =
Working group members have also described wanting to discover =
authorization servers starting from resource servers.  There isn=E2=80=99t=
 a standard practice for any of this, which is why it=E2=80=99s =
intentionally left out of the current specification.
> =20
> Once the IANA OAuth Discovery Metadata Registry has been established, =
which will happen after the current specification has been approved, it =
will be easy for subsequent specifications to document existing practice =
for different OAuth profiles and register discovery metadata values =
supporting them.  Some of those values will likely define ways to =
discover resource servers, when applicable.
> =20
> But first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
  =
]=20
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones  =
 =
 =

> Cc:    =
   =
 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Yup. And because there many relations the client mist be able to =
discover it. The client does not know if the res server is legit.=20
> =20
> The userinfo is always fix and so u dont need discovery.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 14:05, Mike Jones  =
 =
 =
 wrote:
> =20
> In OpenID Connect, there=E2=80=99s a resource server called the =
UserInfo Endpoint that returns claims about the authenticated user as a =
JSON data structure.  Its location is published in OpenID Connect =
discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata =
value, which is defined at =
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata=
 =
 =
 =
.
> =20
> We didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they needn=E2=80=99=
t be one-to-one, as is being actively discussed by the working group.  =
For instance, see George Fletcher=E2=80=99s recent contribution.
> =20
> Thanks for the good discussion, Phil.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
  =
]=20
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc:    =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Where is the profile endpoint (oidc's resource server) published? (For =
the non OIDC people on the list).=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 13:09, Mike Jones  =
 =
 =
 wrote:
> =20
> To the extent that generic OAuth 2.0 needs to publish some of the same =
information as OpenID Connect =E2=80=93 which is built on generic OAuth =
2.0 =E2=80=93 it makes sense to publish that information using exactly =
the same syntax, since that syntax is already in widespread use.  That =
what this draft accomplishes.
> =20
> There=E2=80=99s nothing Connect-specific about using metadata response =
values like:
> =20
>    "authorization_endpoint": "https://server.example.com/authorize" =
 =
 =
,
>    "token_endpoint": "https://server.example.com/token" =
  =
,
>    "token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
>    "registration_endpoint": "https://server.example.com/register" =
 =
 =
,
>    "response_types_supported":  ["code", "token"],
>    "service_documentation": =
"http://server.example.com/service_documentation.html" =
 =
 =
,
> =20
> Is there a reason that you would like the syntax for any of these or =
the other generally applicable OAuth 2.0 metadata values to be =
different?  I don=E2=80=99t see any good reason for unnecessary =
differences to be introduced.
> =20
>                                                                 -- =
Mike
> =20
> From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
  =
]=20
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin  =
  =

> Cc: Mike Jones  =
 =
 =
;  =
   =
   =

> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> Mike
> =20
> Publishing on dev pages does not work for software (esp open source) =
that is deployed both in enterprises and on PaaS cloud providers.=20
> =20
> The current draft is may codify current OIDC practice and be =
appropriate for oidc but it is not ready for generic oauth. There is no =
generic oauth experience at this time.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 10:25, Anthony Nadalin  =
  =
 wrote:
> =20
> Sure there is, it is as you have now made it far easier and the =
security considerations does not even address this
> =20
> From: Mike Jones=20
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin  =
  =

> Cc:    =
   =
 
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> As we=E2=80=99d discussed in person, there=E2=80=99s no effective =
security difference between discovery information being published in an =
ad-hoc fashion on developer pages and it being published in a standard =
format.  =E2=80=9CSecurity by obscurity=E2=80=9D adds no real security =
at all.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones  =
 =
 =
; Phil Hunt (IDM) =
  =
 ; Nat =
Sakimura   =
 
> Cc:    =
   =
 
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
> =20
> That may be widely deployed for OIDC but not widely deployed for =
OAuth. There are some authentication mechanism discovery for endpoint =
that really should not be in an OAuth standard since it=E2=80=99s really =
not dealt with. Now that all this information is available it makes =
poking around the endpoint more focused for people that want to disrupt =
your endpoints, that is really not addressed in the security =
considerations  section at all
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
  =
] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM)  =
  =
; Nat Sakimura  =
  =

> Cc:    =
   =
 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> The point of the WGLC is to finish standardizing the core discovery =
functionality that=E2=80=99s already widely deployed.
> =20
> None of Nat or John or I are suggesting that additional related =
functionality won=E2=80=99t be created.  I=E2=80=99m sure it will be.  =
Some applications will use WebFinger to locate the discovery metadata.  =
Some will possibly use link headers.  Some will possibly use =
application-specific .well-known values.  I=E2=80=99m sure there=E2=80=99s=
 other things I haven=E2=80=99t even thought about.  All of these depend =
upon having a discovery metadata document format and none of them change =
it =E2=80=93 other than possibly to register additional discovery =
metadata values.
> =20
> So by all means, the working group should continue discussing =
inventing possible new related mechanisms that make sense in some =
contexts.  At the same time, we can finish standardizing the already =
widely deployed core functionality that all of these mechanisms will =
need.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
  =
] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura   =
 
> Cc:    =
   =
 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> =20
> I am suggesting that part of the discovery solution has to be the =
client indicating what resource endpoint it wants the oauth =
configuration data for.=20
> =20
> So if res.example.evil.com  =
 is not a valid resource endpoint for =
as.example.com   the =
authz discovery should fail in some way (eg return nothing).=20
> =20
> There may be better ways to do this. Eg combine discovery. Or change =
the order of discovery.=20
> =20
> One of OAuth's strength's and weaknesses is that the target of =
authorization (the resource) is never specified. It is often bound up in =
the client registration and an often implied 1:1 relationship between =
resource and as. Given that in discovery phase registration has not yet =
occurred it seems important that the client know it has a valid =
combination of endpoints etc.=20
> =20
> This is why I was disappointed about wglc on discovery. We had a =
starting point for group adoption but we haven't really defined the full =
requirements IMO.=20
> =20
> I am on vacation or I would put some thought into some draft changes =
or a new draft. I apologize I can't do it now.=20
> =20
> Phil
> =20
> On Feb 24, 2016, at 08:12, Nat Sakimura  =
  =
 wrote:
> =20
> Hi Phil,=20
> =20
> Are you suggesting that the AS metadata should include the RS URIs? =
Currently, it does not, but it can be done, I guess.=20
> =20
> The way oauth-meta works is that=20
> =20
> 1. RS tells the client where the AS is.=20
> 2. AS tells the client which RS endpoints the token can be used.=20
> =20
> Even if there is a bad AS with a valid certs that proxies to the good =
RS, the client will not send the token there as the authz server will =
say that is not the place the client may want to send the token to.=20
> =20
> Nat
> =20
> 2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt =
  =
 :
> Nat,
> =20
> I=E2=80=99m not sure that having the resource server tell the client =
where its authorization server is secure by itself. The relationship =
between the Authorization Server and the Resource server need to be =
bound together in one of the discovery endpoints (the resource and/or =
the oauth service discovery).
> =20
> If a client discovers a fake resource server that is proxying for a =
real resource server the current discovery spec will not lead the client =
to understand it has the wrong resource server. Rather the fake resource =
service will just have a fake discovery service. The hacker can now =
intercept resource payload as well as tokens because they were able to =
convince the client to use the legit authorization service but use the =
token against the hackers proxy.
> =20
> The OAuth Discovery service needs to confirm to the client that the =
server is able to issue tokens for a stated resource endpoint.
> =20
> This not only works in normal OAuth but should add security even to =
UMA situations.
> =20
> Phil
> =20
> @independentid
> www.independentid.com  =
 
> phil.hunt@oracle.com  =
 
> =20
> =20
> =20
> =20
> =20
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  =
  =
 wrote:
> =20
> =20
> Hi Thomas,=20
> =20
> inline:=20
> =20
> 2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer =
  =
 :
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want =
to do discovery, and leave it open to implementers / to other specs to =
define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any =
URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a =
basis for other metadata specs (like OpenID Connect).=20
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed=20
> =20
> Yup. That's one of the requirements to be RESTful, is it not? =20
> =20
> In OAuth's case, the resource and the authorization server are usually =
tightly coupled. (Otherwise, you need another specs like UMA.)=20
> So, the resource server should be able to tell either the location of =
the authz endpoint. In some trusted environment, the resource may as =
well return the location of the authz server configuration data. In =
these cases, you do not have to decide on what .well-known uri as you =
say. This frees up developers from configuration file location =
collisions etc. We should strive not to pollute the uri space as much as =
possible.=20
> =20
> (well, except if there are several ASs each with different scopes; =
sounds like an edge-case to me though; maybe RFC6750 should instead be =
updated with such a parameter such that an RS could return several =
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
> =20
> Yeah, I guess it is an edge case. I would rather like to see these =
authz servers to develop a trust framework under which they can agree on =
a single set of common scope parameter values.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
> =20
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  =
  =
 wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
> =20
> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=E2=
=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery =
document.
> =20
>  =E2=80=94 Justin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org   =

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

> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org   =

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

> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org   =

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

> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org   =

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

> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org   =

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

> =20
> =20
> --=20
> Vladimir Dzhuvinov :: vladimir@connect2id.com =
  =

> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org   =

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

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

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

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


--Apple-Mail=_53923C8C-4224-4A2F-AC6D-AA5D623F8C74
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

To clarify=E2=80=A6. I am not suggesting =
that we need a resource discovery mechanism.

What I am suggesting is much =
simpler.

I =
propose that the authorization confirm that the endpoint that the client =
has discovered is a resource that the AS can issue tokens for (in other =
words is a valid audience for the tokens).

This will work well in UMA cases and it =
confirms the relationship between the AS and the RS is in fact =
valid.
It also detects mis-configuration cases that =
might naturally occur in scenarios with multi-tenancies etc.








On Feb 27, 2016, at 10:38 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for taking the =
time to propose specific text, Phil.  That=E2=80=99s really =
helpful.  I=E2=80=99ll plan to incorporate a version of this in the =
draft addressing WGLC comments.
 
I agree with Vladimir=E2=80=
=99s observation that it=E2=80=99s difficult to come up with a =
general-purpose resource discovery mechanism.  That in part, is =
because, as Brian points out, there=E2=80=99s often not a 1:1 =
relationship between authorization servers and resource servers.  =
As I=E2=80=99ve written before, I do encourage the working group to work =
on creating solutions to resource discovery that will work for some =
common use cases.  But the good news is that while resource =
discovery requires new invention, authorization server discovery does =
not.
 
          &nb=
sp;            =
;            &=
nbsp;       =
            &n=
bsp; -- Mike
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of Vladimir =
Dzhuvinov
Sent: Saturday, February 27, 2016 =
10:33 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 =
Discovery Location
 
 
On 27/02/16 20:10, Phil Hunt wrote:
The name change =
seems appropriate given that the WG members have decided not to address =
the issue of resource discovery as part of this specification.
 
If the =
consensus is to limit the scope of the specification, then I suggest the =
following security considerations text.
 
Resource Discovery
 
Secure =
discovery of resource endpoints is out-of-scope of this specification. =
This specification assumes that the client has already securely =
discovered the correct resource endpoint and that the client has =
correctly selected the correct corresponding discovery for OAuth =
Authorization server. Implementers MUST consider that if an incorrect =
resource endpoint was discovered by the client that an attacker will be =
able to set up a man-in-the-middle proxy to a real resource server =
without detection by the authorization server or the client. 

I support that. This was the primary concern =
of everyone who felt uncomfortable with the original draft with =
WebFinger-based discovery in it, so it should be included.




 
It may be more =
appropriate to even include this text in the introduction as a =
cautionary "red flag" to implementers.
+1


 
 
Once again, I =
strongly urge the WG to actually include a method for the client to =
discovery that the oauth cliet has correctly discovered an authorization =
server that is willing and able to issue access tokens for a given =
resource endpoint. I believe this relationship is critical to security =
of OAuth in cases where resource endpoints are discovered =
dynamically.  Of course willing and able means that the AS believes =
that the endpoint is legitimate.

The more I think about this topic, the more =
pessimistic I get that there is a good solution to this :)

Vladimir



 
 
Phil
 
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
 
 
 
 
 
On Feb 27, =
2016, at 6:46 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
 
+1 for =E2=80=9CO=
Auth 2.0 Authorization Server Discovery=E2=80=9D
 
//Samuel
 
On Thu, Feb 25, =
2016 at 8:10 PM, Mike Jones <Michael.Jones@microsoft.com =
<mailto:Michael.Jones@microsoft.com>> wrote:
Thanks for your =
thoughts, Vladimir.  I=E2=80=99m increasingly inclined to accept =
your suggestion to change the title from =E2=80=9COAuth 2.0 Discovery=E2=80=
=9D to =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D.  =
While the abstract already makes it clear that the scope of the document =
is AS discovery, doing so in the title seems like it could help clarify =
things, given that a lot of the discussion seems to be about resource =
discovery, which is out of scope of the document.
 
 
 
I=E2=80=99m not =
saying that resource discovery isn=E2=80=99t important =E2=80=93 it is =
=E2=80=93 but unlike authorization server discovery, where there=E2=80=99s=
 lots of existing practice, including using the existing data format for =
describing OAuth implementations that aren=E2=80=99t being used with =
OpenID Connect, there=E2=80=99s no existing practice to standardize for =
resource discovery.  The time to create a standard for that seems =
to be after existing practice has emerged.  It *might* or might not =
use new metadata values in the AS discovery document, but that=E2=80=99s =
still to be determined.  The one reason to leave the title as-is is =
that resource discovery might end up involving extensions to this =
metadata format in some cases.
 
 
 
I think an analogy to the core OAuth =
documents RFC 6749 and RFC 6750 applies.  6749 is about the =
AS.  6750 is about the RS.  The discovery document is about =
the AS.  We don=E2=80=99t yet have a specification or existing =
practice for RS discovery, which would be the 6750 analogy.
 
 
 
In summary, =
which title do people prefer?
 
=C2=B7       =
=E2=80=9COAuth 2.0 Discovery=E2=80=9D
 
=C2=B7       =
=E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
 
 
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
  =
<>
From: =
OAuth [mailto:oauth-bounces@ietf.org =
<mailto:oauth-bounces@ietf.org>] On Behalf Of =
Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: oauth@ietf.org <mailto:oauth@ietf.org>
 
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
 
 
In OIDC the discovery doc is of great utility =
to developers and integrators. Developers also tend to find it a more =
accurate and complete description of how to set up a client for a =
particular deployment, compared to traditional online docs, which may be =
not be up to date, or even missing. Very much like auto-generated =
Swagger and JavaDocs.
 
Here are some example OIDC discovery docs:
 
https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuratio=
n>
 
https://www.paypalobjects.com/.well-known/openid-configuration<=
/a> <https://www.paypalobjects.com/.well-known/openid-configurat=
ion>
 
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v=
2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.c=
om/v2.0/.well-known/openid-configuration>
 
 
With this =
discovery document in place setup of identity federation can then be =
easily scripted. For example:
 
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_provid=
ers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr=
oviders_create_oidc_verify-thumbprint.html>
 
 
Now, does that =
dictate any particular app architecture? My reading of the spec is that =
it doesn't, and it shouldn't either. By staying neutral on the topics of =
RS discovery and registering RPs with RSs. And how one arrives at the =
".well-known/...". I'm not even sure that resource discovery should be a =
topic of this WG. Perhaps to this end, and to prevent confusion that the =
spec is trying to do something more, a more specific title would suit it =
better. E.g. "AS Discovery".
 
Cheers,
 
Vladimir
 
 
 
 
On 25/02/16 02:25, Phil Hunt (IDM) wrote:
 
And so does =
oracle and so does google. Each different. 
 
So how can an =
app dictate it then unless we all go to a common architecture?
 
Phil
 
On Feb 24, =
2016, at 16:04, Mike Jones <Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> wrote:
 
Azure defines =
ways for resource servers to be registered for use with a client and for =
clients to dynamically request an access token for use at a particular =
resource server.  You can call that custom architecture if you =
want.  It=E2=80=99s well-defined but it=E2=80=99s not currently in =
the standards realm.  I know that Google has syntax for doing the =
same, as I=E2=80=99m sure do a lot of other cloud OAuth deployments, =
such as Oracle=E2=80=99s.  For what it=E2=80=99s worth, the working =
group talked about possibly producing a standard version of syntax for =
making these kinds of requests during our discussions in Prague (during =
the Token Exchange discussion) but nobody has run with this yet.
 
In this sense, =
yes, Azure is an application of the kind we=E2=80=99re talking =
about.  Azure already does define specific new OAuth 2.0 discovery =
metadata values that are used in production.  A registry just =
doesn=E2=80=99t yet exist in which it can register those that are of =
general applicability.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>] 
Sent: =
Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Mike
 
Take a look at the assumptions you are =
making. 
 
You=
 seem to be assuming application software dictates oauth infrastructure =
architecture by suggesting that apps register in iana.  
 
Would ms azure =
allow custom arch?
 =

Phil
 
On Feb 24, =
2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> wrote:
 
The UserInfo =
Endpoint path isn=E2=80=99t fixed and so has to be discovered.
 
I agree that =
for some OAuth profiles, one or more resource servers will have to be =
discovered starting from the authorization server.  Working group =
members have also described wanting to discover authorization servers =
starting from resource servers.  There isn=E2=80=99t a standard =
practice for any of this, which is why it=E2=80=99s intentionally left =
out of the current specification.
 
Once the IANA OAuth Discovery Metadata =
Registry has been established, which will happen after the current =
specification has been approved, it will be easy for subsequent =
specifications to document existing practice for different OAuth =
profiles and register discovery metadata values supporting them.  =
Some of those values will likely define ways to discover resource =
servers, when applicable.
 
But =
first, we need to finish the existing spec, so that the registry =
enabling these extensions gets established in the first place.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>] 
Sent: =
Wednesday, February 24, 2016 2:13 PM
To: Mike Jones <Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com>
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Yup. And because there many relations the =
client mist be able to discover it. The client does not know if the res =
server is legit. 
 
The=
 userinfo is always fix and so u dont need discovery. 
 
Phil
 
On Feb 24, =
2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> wrote:
 
In OpenID =
Connect, there=E2=80=99s a resource server called the UserInfo Endpoint =
that returns claims about the authenticated user as a JSON data =
structure.  Its location is published in OpenID Connect discovery =
metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D metadata value, =
which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#Provi=
derMetadata <http://openid.net/specs/openid-connect-discovery-1_0.html#P=
roviderMetadata>.
 
We =
didn=E2=80=99t include the UserInfo Endpoint in the generic OAuth =
discovery spec since in OAuth, there are lots of possible relationships =
between authorization servers and resource servers and they needn=E2=80=99=
t be one-to-one, as is being actively discussed by the working =
group.  For instance, see George Fletcher=E2=80=99s recent =
contribution.
 
Thanks for the =
good discussion, Phil.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>] 
Sent: =
Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Where is the profile endpoint (oidc's =
resource server) published? (For the non OIDC people on the list). 
 
Phil
 
On Feb 24, =
2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> wrote:
 
To the extent =
that generic OAuth 2.0 needs to publish some of the same information as =
OpenID Connect =E2=80=93 which is built on generic OAuth 2.0 =E2=80=93 =
it makes sense to publish that information using exactly the same =
syntax, since that syntax is already in widespread use.  That what =
this draft accomplishes.
 
There=E2=80=99s nothing Connect-specific about using metadata =
response values like:
 
   "authorization_endpoint": "https://server.example.com/authorize" <https://server.example.com/authorize>,
   =
"token_endpoint": "https://server.example.com/token" <https://server.example.com/token>,
   =
"token_endpoint_auth_methods_supported": ["client_secret_basic", =
"private_key_jwt"],
   "registration_endpoint": "https://server.example.com/register" <https://server.example.com/register>,
   =
"response_types_supported":  ["code", "token"],
   =
"service_documentation": "http://server.example.com/service_documentation.html" <http://server.example.com/service_documentation.html>,
 
Is there a =
reason that you would like the syntax for any of these or the other =
generally applicable OAuth 2.0 metadata values to be different?  I =
don=E2=80=99t see any good reason for unnecessary differences to be =
introduced.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>] 
Sent: =
Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <tonynad@microsoft.com> =
<mailto:tonynad@microsoft.com>
Cc: Mike Jones =
<Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com>; <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
Mike
 
Publishing on dev pages does not work for =
software (esp open source) that is deployed both in enterprises and on =
PaaS cloud providers. 
 
The=
 current draft is may codify current OIDC practice and be appropriate =
for oidc but it is not ready for generic oauth. There is no generic =
oauth experience at this time. 
 
Phil
 
On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> =
<mailto:tonynad@microsoft.com> wrote:
 
Sure there is, =
it is as you have now made it far easier and the security considerations =
does not even address this
 
From: Mike Jones 
Sent: =
Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <tonynad@microsoft.com> =
<mailto:tonynad@microsoft.com>
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: RE: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
As we=E2=80=99d discussed in person, =
there=E2=80=99s no effective security difference between discovery =
information being published in an ad-hoc fashion on developer pages and =
it being published in a standard format.  =E2=80=9CSecurity by =
obscurity=E2=80=9D adds no real security at all.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- =
Mike
 
From: Anthony =
Nadalin 
Sent: =
Wednesday, February 24, 2016 10:01 AM
To: Mike Jones <Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com>; Phil Hunt =
(IDM) <phil.hunt@oracle.com> =
<mailto:phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com> =
<mailto:sakimura@gmail.com>
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: RE: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
The point of the WGLC is to finish =
standardizing the core discovery functionality that=E2=80=99s already =
widely deployed.
 =

That may be =
widely deployed for OIDC but not widely deployed for OAuth. There are =
some authentication mechanism discovery for endpoint that really should =
not be in an OAuth standard since it=E2=80=99s really not dealt with. =
Now that all this information is available it makes poking around the =
endpoint more focused for people that want to disrupt your endpoints, =
that is really not addressed in the security considerations  =
section at all
 
From: OAuth [mailto:oauth-bounces@ietf.org =
<mailto:oauth-bounces@ietf.org>] On Behalf Of Mike =
Jones
Sent: =
Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com> =
<mailto:phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com> =
<mailto:sakimura@gmail.com>
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
The point of the WGLC is to finish =
standardizing the core discovery functionality that=E2=80=99s already =
widely deployed.
 =

None of Nat or =
John or I are suggesting that additional related functionality won=E2=80=99=
t be created.  I=E2=80=99m sure it will be.  Some applications =
will use WebFinger to locate the discovery metadata.  Some will =
possibly use link headers.  Some will possibly use =
application-specific .well-known values.  I=E2=80=99m sure =
there=E2=80=99s other things I haven=E2=80=99t even thought about.  =
All of these depend upon having a discovery metadata document format and =
none of them change it =E2=80=93 other than possibly to register =
additional discovery metadata values.
 
So by all means, the working group should =
continue discussing inventing possible new related mechanisms that make =
sense in some contexts.  At the same time, we can finish =
standardizing the already widely deployed core functionality that all of =
these mechanisms will need.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- =
Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org =
<mailto:oauth-bounces@ietf.org>] On Behalf Of Phil =
Hunt (IDM)
Sent: =
Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <sakimura@gmail.com> =
<mailto:sakimura@gmail.com>
Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: Re: =
[OAUTH-WG] OAuth 2.0 Discovery Location
 
I am suggesting that part of the discovery =
solution has to be the client indicating what resource endpoint it wants =
the oauth configuration data for. 
 
So if res.example.evil.com <http://res.example.evil.com/> is not a valid =
resource endpoint for as.example.com <http://as.example.com/> the authz discovery should =
fail in some way (eg return nothing). 
 
There may be better ways to do this. Eg =
combine discovery. Or change the order of discovery. 
 
One of OAuth's =
strength's and weaknesses is that the target of authorization (the =
resource) is never specified. It is often bound up in the client =
registration and an often implied 1:1 relationship between resource and =
as. Given that in discovery phase registration has not yet occurred it =
seems important that the client know it has a valid combination of =
endpoints etc. 
 
This is why I was disappointed about wglc on discovery. We =
had a starting point for group adoption but we haven't really defined =
the full requirements IMO. 
 
I am on vacation or I would put some thought =
into some draft changes or a new draft. I apologize I can't do it now. =

 
Phil
 
On Feb 24, =
2016, at 08:12, Nat Sakimura <sakimura@gmail.com> <mailto:sakimura@gmail.com> wrote:
 
Hi Phil, 
 
Are you =
suggesting that the AS metadata should include the RS URIs? Currently, =
it does not, but it can be done, I guess. 
 
The way oauth-meta works is that 
 
1. RS tells the =
client where the AS is. 
2. AS tells the client which RS endpoints the token can be =
used. 
 
Even if there is a bad AS with a valid certs that proxies to =
the good RS, the client will not send the token there as the authz =
server will say that is not the place the client may want to send the =
token to. 
 
Nat
 
2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hunt@oracle.com> <mailto:phil.hunt@oracle.com>:
Nat,
 
I=E2=80=99m not =
sure that having the resource server tell the client where its =
authorization server is secure by itself. The relationship between the =
Authorization Server and the Resource server need to be bound together =
in one of the discovery endpoints (the resource and/or the oauth service =
discovery).
 
If a client =
discovers a fake resource server that is proxying for a real resource =
server the current discovery spec will not lead the client to understand =
it has the wrong resource server. Rather the fake resource service will =
just have a fake discovery service. The hacker can now intercept =
resource payload as well as tokens because they were able to convince =
the client to use the legit authorization service but use the token =
against the hackers proxy.
 
The OAuth Discovery service needs to confirm =
to the client that the server is able to issue tokens for a stated =
resource endpoint.
 =

This not only =
works in normal OAuth but should add security even to UMA =
situations.
 
Phil
 
@independentid
www.independentid.com =
<http://www.independentid.com/>
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
 
 
 
 
 
On Feb 24, =
2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> <mailto:sakimura@gmail.com> wrote:
 
 
Hi Thomas, 
 
inline: 
 
2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com> <mailto:t.broyer@gmail.com>:
Couldn't the =
document only describe the metadata?
I quite like the idea of =
draft-sakimura-oauth-meta if you really want to do discovery, and leave =
it open to implementers / to other specs to define a .well-known URL for =
"auto-configuration".
The metadata described here would then either be used as-is, =
at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or =
as a basis for other metadata specs (like OpenID Connect). 
With =
draft-sakimura-oauth-meta's "duri" and the "scope" attribute of =
WWW-Authenticate response header, you have everything you need to =
proceed 
 
Yup. That's one of the requirements to be RESTful, is it =
not?  
 
In =
OAuth's case, the resource and the authorization server are usually =
tightly coupled. (Otherwise, you need another specs like UMA.) 
So, the =
resource server should be able to tell either the location of the authz =
endpoint. In some trusted environment, the resource may as well return =
the location of the authz server configuration data. In these cases, you =
do not have to decide on what .well-known uri as you say. This frees up =
developers from configuration file location collisions etc. We should =
strive not to pollute the uri space as much as possible. 
 
(well, except =
if there are several ASs each with different scopes; sounds like an =
edge-case to me though; maybe RFC6750 should instead be updated with =
such a parameter such that an RS could return several WWW-Authenticate: =
Bearer, each with its own "scope" and "duri" value?)
 
Yeah, I guess =
it is an edge case. I would rather like to see these authz servers to =
develop a trust framework under which they can agree on a single set of =
common scope parameter values. 
 
Cheers, 
 
Nat
 
 
 
On Fri, Feb 19, 2016 at 10:59 PM Justin =
Richer <jricher@mit.edu> <mailto:jricher@mit.edu> wrote:
The =
newly-trimmed OAuth Discovery document is helpful and moving in the =
right direction. It does, however, still have too many vestiges of its =
OpenID Connect origins. One issue in particular still really bothers me: =
the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the =
discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
 
I propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery document.
 
 =E2=80=94 =
Justin
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
 
 
 
 
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
 
 
-- 
Vladimir =
Dzhuvinov :: vladimir@connect2id.com <mailto:vladimir@connect2id.com>
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
 
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 



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

=

--Apple-Mail=_53923C8C-4224-4A2F-AC6D-AA5D623F8C74--


From nobody Sat Feb 27 11:10:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B913D1B2B51 for ; Sat, 27 Feb 2016 11:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OczlP24VsDje for ; Sat, 27 Feb 2016 11:09:54 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5B11B2B5B for ; Sat, 27 Feb 2016 11:09:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uDRIIr8WodFH6XQ8XIPSB1T4yeMGt5HivXD3s9Oaf1M=; b=aFtpqB53NwdziEVfESXWaPd5cLcs6UA0hhZ0I6AdHLwRrK5KVXmjoOGyKYKaLiPKgP7da/qhJD9fEIDDn+Wo35Q1vWftnY4++QgTAehMbNa7vV1wYY1/MM7zKcq3NE+9Gc/sHFrVyHInzSZ4TgJP3OcZlSpDedAEdyEG4elIfdc=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 27 Feb 2016 19:09:50 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0409.024; Sat, 27 Feb 2016 19:09:50 +0000
From: Mike Jones 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AQHRa2DaHttHgTSJCkmahJ0fmFV0nJ831G4AgANJI4CAADOtAIAAFF+AgAAHbICAABKjoIAABEmAgAAFVmCAAAF8AIAAJvuAgAAD5YCAAAcqAIAACZKwgAAD14CAABMcsIAACLCAgAAAzOCAAAh3AIAAj3QAgACntWCAAt4rAIAAONyAgAAGOgCAAABGEIAABqKAgAACZFA=
Date: Sat, 27 Feb 2016 19:09:49 +0000
Message-ID: 
References:    <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>    <56D1EBC4.404090! 7@connect2id.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: 854db909-5ede-4b9e-c78b-08d33fa990fa
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:kAVDUYKllY3FhpY7xtVfpKBRPTbtXICi4JLPXh99vHynukWZiy0zEUQdxWtsmkoUxy5DaDxdO5MHtmYITf/VP76dyhafJ2uEAvzhEqnHm7HoAY4ZQdjc+51QeB7TWvzCBNfh5tjWAezaq9MA931Mvw==; 24:xyhTJ1KicXDc1BAFKrwNdED93VvzvFXwM0gfGCb7i5ncfTp9nGdxtH14qjXQz62ALT6LsTTmdMrV4ujKXWZLVqJHopLhYTYpfDW9FwFn1I4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(169139582196971);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52604005)(377454003)(24454002)(479174004)(51914003)(19580405001)(19580395003)(1220700001)(93886004)(74316001)(3846002)(3660700001)(586003)(33656002)(66066001)(19625215002)(3280700002)(4326007)(5008740100001)(2900100001)(15975445007)(2906002)(2950100001)(16601075003)(122556002)(3900700001)(77096005)(19609705001)(11100500001)(10400500002)(1096002)(6116002)(1680700002)(5002640100001)(5005710100001)(87936001)(19300405004)(92566002)(76176999)(76576001)(99286002)(106116001)(189998001)(54356999)(110136002)(50986999)(102836003)(10290500002)(86612001)(790700001)(5003600100002)(5004730100002)(5001960100002)(86362001)(10090500001)(19617315012)(15395725005)(16236675004)(559001)(579004)(184035003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F67CB6EC7B1746B35CA7F5B80BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2016 19:09:49.5467 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 19:10:04 -0000

--_000_BY2PR03MB442F67CB6EC7B1746B35CA7F5B80BY2PR03MB442namprd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBrbm93IHRoYXQgYXQgbGVhc3QgaW4gQXp1cmUsIGRldmVsb3BlcnMgY2FuIGR5bmFtaWNhbGx5
IGFkZCByZXNvdXJjZXMgZm9yIHVzZSBieSB0aGUgY2xpZW50IHVzaW5nIHRoZSBkZXZlbG9wZXIg
cG9ydGFsIGF0IGFueSB0aW1lLiAgVGhlcmVmb3JlLCBhdCBjbGllbnQgY29uZmlndXJhdGlvbiB0
aW1lLCB3aGljaCBpcyB3aGVuIEFTIGRpc2NvdmVyeSBpcyB1c2VkLCB0aGVyZSBpcyBub3QgYW4g
YXV0aG9yaXRhdGl2ZSBsaXN0IG9mIHJlc291cmNlcyBhdmFpbGFibGUuICBJIGJlbGlldmUgdGhh
dCBCcmlhbiBzYWlkIGEgc2ltaWxhciB0aGluZyBhYm91dCBoaXMgdXNlIGNhc2VzLg0KDQpUaGVy
ZWZvcmUsIHdoaWxlIHdoYXQgeW914oCZcmUgcHJvcG9zaW5nIG1heSAqc2VlbSosIHNpbXBsZSwg
YnV0IGl04oCZcyAqbm90IGFjdHVhbGx5KiBzaW1wbGUgYXQgYWxsLg0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG
cm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NClNlbnQ6IFNhdHVy
ZGF5LCBGZWJydWFyeSAyNywgMjAxNiAxMDo1NyBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tPjsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9B
dXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KVG8gY2xhcmlmeeKApi4gSSBhbSBub3Qgc3Vn
Z2VzdGluZyB0aGF0IHdlIG5lZWQgYSByZXNvdXJjZSBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KDQpX
aGF0IEkgYW0gc3VnZ2VzdGluZyBpcyBtdWNoIHNpbXBsZXIuDQoNCkkgcHJvcG9zZSB0aGF0IHRo
ZSBhdXRob3JpemF0aW9uIGNvbmZpcm0gdGhhdCB0aGUgZW5kcG9pbnQgdGhhdCB0aGUgY2xpZW50
IGhhcyBkaXNjb3ZlcmVkIGlzIGEgcmVzb3VyY2UgdGhhdCB0aGUgQVMgY2FuIGlzc3VlIHRva2Vu
cyBmb3IgKGluIG90aGVyIHdvcmRzIGlzIGEgdmFsaWQgYXVkaWVuY2UgZm9yIHRoZSB0b2tlbnMp
Lg0KDQpUaGlzIHdpbGwgd29yayB3ZWxsIGluIFVNQSBjYXNlcyBhbmQgaXQgY29uZmlybXMgdGhl
IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTIGlzIGluIGZhY3QgdmFsaWQu
DQpJdCBhbHNvIGRldGVjdHMgbWlzLWNvbmZpZ3VyYXRpb24gY2FzZXMgdGhhdCBtaWdodCBuYXR1
cmFsbHkgb2NjdXIgaW4gc2NlbmFyaW9zIHdpdGggbXVsdGktdGVuYW5jaWVzIGV0Yy4NCg0KUGhp
bA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5k
ZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+DQoNCg0KDQoNCk9uIEZlYiAyNywgMjAxNiwgYXQgMTA6MzggQU0sIE1pa2UgSm9u
ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPj4gd3JvdGU6DQoNClRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHByb3Bv
c2Ugc3BlY2lmaWMgdGV4dCwgUGhpbC4gIFRoYXTigJlzIHJlYWxseSBoZWxwZnVsLiAgSeKAmWxs
IHBsYW4gdG8gaW5jb3Jwb3JhdGUgYSB2ZXJzaW9uIG9mIHRoaXMgaW4gdGhlIGRyYWZ0IGFkZHJl
c3NpbmcgV0dMQyBjb21tZW50cy4NCg0KSSBhZ3JlZSB3aXRoIFZsYWRpbWly4oCZcyBvYnNlcnZh
dGlvbiB0aGF0IGl04oCZcyBkaWZmaWN1bHQgdG8gY29tZSB1cCB3aXRoIGEgZ2VuZXJhbC1wdXJw
b3NlIHJlc291cmNlIGRpc2NvdmVyeSBtZWNoYW5pc20uICBUaGF0IGluIHBhcnQsIGlzIGJlY2F1
c2UsIGFzIEJyaWFuIHBvaW50cyBvdXQsIHRoZXJl4oCZcyBvZnRlbiBub3QgYSAxOjEgcmVsYXRp
b25zaGlwIGJldHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZCByZXNvdXJjZSBzZXJ2ZXJz
LiAgQXMgSeKAmXZlIHdyaXR0ZW4gYmVmb3JlLCBJIGRvIGVuY291cmFnZSB0aGUgd29ya2luZyBn
cm91cCB0byB3b3JrIG9uIGNyZWF0aW5nIHNvbHV0aW9ucyB0byByZXNvdXJjZSBkaXNjb3Zlcnkg
dGhhdCB3aWxsIHdvcmsgZm9yIHNvbWUgY29tbW9uIHVzZSBjYXNlcy4gIEJ1dCB0aGUgZ29vZCBu
ZXdzIGlzIHRoYXQgd2hpbGUgcmVzb3VyY2UgZGlzY292ZXJ5IHJlcXVpcmVzIG5ldyBpbnZlbnRp
b24sIGF1dGhvcml6YXRpb24gc2VydmVyIGRpc2NvdmVyeSBkb2VzIG5vdC4NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K
DQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBWbGFkaW1pciBEemh1dmlub3YNClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAyNywgMjAxNiAx
MDozMyBBTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1Ympl
Y3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KDQpPbiAy
Ny8wMi8xNiAyMDoxMCwgUGhpbCBIdW50IHdyb3RlOg0KDQpUaGUgbmFtZSBjaGFuZ2Ugc2VlbXMg
YXBwcm9wcmlhdGUgZ2l2ZW4gdGhhdCB0aGUgV0cgbWVtYmVycyBoYXZlIGRlY2lkZWQgbm90IHRv
IGFkZHJlc3MgdGhlIGlzc3VlIG9mIHJlc291cmNlIGRpc2NvdmVyeSBhcyBwYXJ0IG9mIHRoaXMg
c3BlY2lmaWNhdGlvbi4NCg0KDQoNCklmIHRoZSBjb25zZW5zdXMgaXMgdG8gbGltaXQgdGhlIHNj
b3BlIG9mIHRoZSBzcGVjaWZpY2F0aW9uLCB0aGVuIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHNl
Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQuDQoNCg0KDQpSZXNvdXJjZSBEaXNjb3ZlcnkNCg0K
DQoNClNlY3VyZSBkaXNjb3Zlcnkgb2YgcmVzb3VyY2UgZW5kcG9pbnRzIGlzIG91dC1vZi1zY29w
ZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uIFRoaXMgc3BlY2lmaWNhdGlvbiBhc3N1bWVzIHRoYXQg
dGhlIGNsaWVudCBoYXMgYWxyZWFkeSBzZWN1cmVseSBkaXNjb3ZlcmVkIHRoZSBjb3JyZWN0IHJl
c291cmNlIGVuZHBvaW50IGFuZCB0aGF0IHRoZSBjbGllbnQgaGFzIGNvcnJlY3RseSBzZWxlY3Rl
ZCB0aGUgY29ycmVjdCBjb3JyZXNwb25kaW5nIGRpc2NvdmVyeSBmb3IgT0F1dGggQXV0aG9yaXph
dGlvbiBzZXJ2ZXIuIEltcGxlbWVudGVycyBNVVNUIGNvbnNpZGVyIHRoYXQgaWYgYW4gaW5jb3Jy
ZWN0IHJlc291cmNlIGVuZHBvaW50IHdhcyBkaXNjb3ZlcmVkIGJ5IHRoZSBjbGllbnQgdGhhdCBh
biBhdHRhY2tlciB3aWxsIGJlIGFibGUgdG8gc2V0IHVwIGEgbWFuLWluLXRoZS1taWRkbGUgcHJv
eHkgdG8gYSByZWFsIHJlc291cmNlIHNlcnZlciB3aXRob3V0IGRldGVjdGlvbiBieSB0aGUgYXV0
aG9yaXphdGlvbiBzZXJ2ZXIgb3IgdGhlIGNsaWVudC4NCg0KSSBzdXBwb3J0IHRoYXQuIFRoaXMg
d2FzIHRoZSBwcmltYXJ5IGNvbmNlcm4gb2YgZXZlcnlvbmUgd2hvIGZlbHQgdW5jb21mb3J0YWJs
ZSB3aXRoIHRoZSBvcmlnaW5hbCBkcmFmdCB3aXRoIFdlYkZpbmdlci1iYXNlZCBkaXNjb3Zlcnkg
aW4gaXQsIHNvIGl0IHNob3VsZCBiZSBpbmNsdWRlZC4NCg0KDQoNCg0KDQoNCg0KDQpJdCBtYXkg
YmUgbW9yZSBhcHByb3ByaWF0ZSB0byBldmVuIGluY2x1ZGUgdGhpcyB0ZXh0IGluIHRoZSBpbnRy
b2R1Y3Rpb24gYXMgYSBjYXV0aW9uYXJ5ICJyZWQgZmxhZyIgdG8gaW1wbGVtZW50ZXJzLg0KKzEN
Cg0KDQoNCg0KDQoNCg0KDQpPbmNlIGFnYWluLCBJIHN0cm9uZ2x5IHVyZ2UgdGhlIFdHIHRvIGFj
dHVhbGx5IGluY2x1ZGUgYSBtZXRob2QgZm9yIHRoZSBjbGllbnQgdG8gZGlzY292ZXJ5IHRoYXQg
dGhlIG9hdXRoIGNsaWV0IGhhcyBjb3JyZWN0bHkgZGlzY292ZXJlZCBhbiBhdXRob3JpemF0aW9u
IHNlcnZlciB0aGF0IGlzIHdpbGxpbmcgYW5kIGFibGUgdG8gaXNzdWUgYWNjZXNzIHRva2VucyBm
b3IgYSBnaXZlbiByZXNvdXJjZSBlbmRwb2ludC4gSSBiZWxpZXZlIHRoaXMgcmVsYXRpb25zaGlw
IGlzIGNyaXRpY2FsIHRvIHNlY3VyaXR5IG9mIE9BdXRoIGluIGNhc2VzIHdoZXJlIHJlc291cmNl
IGVuZHBvaW50cyBhcmUgZGlzY292ZXJlZCBkeW5hbWljYWxseS4gIE9mIGNvdXJzZSB3aWxsaW5n
IGFuZCBhYmxlIG1lYW5zIHRoYXQgdGhlIEFTIGJlbGlldmVzIHRoYXQgdGhlIGVuZHBvaW50IGlz
IGxlZ2l0aW1hdGUuDQoNClRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgdGhpcyB0b3BpYywgdGhlIG1v
cmUgcGVzc2ltaXN0aWMgSSBnZXQgdGhhdCB0aGVyZSBpcyBhIGdvb2Qgc29sdXRpb24gdG8gdGhp
cyA6KQ0KDQpWbGFkaW1pcg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbA0KDQoNCg0KQGluZGVwZW5k
ZW50aWQNCg0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5j
b20vPiA8aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+PGh0dHA6Ly93d3cuaW5kZXBlbmRl
bnRpZC5jb20vPnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bT4gPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu
Y29tPg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIEZlYiAyNywgMjAxNiwgYXQgNjo0NiBBTSwg
U2FtdWVsIEVyZHRtYW4gPHNhbXVlbEBlcmR0bWFuLnNlPjxtYWlsdG86c2FtdWVsQGVyZHRtYW4u
c2U+IHdyb3RlOg0KDQoNCg0KKzEgZm9yIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZl
ciBEaXNjb3ZlcnnigJ0NCg0KDQoNCi8vU2FtdWVsDQoNCg0KDQpPbiBUaHUsIEZlYiAyNSwgMjAx
NiBhdCA4OjEwIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFp
bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN
Cg0KVGhhbmtzIGZvciB5b3VyIHRob3VnaHRzLCBWbGFkaW1pci4gIEnigJltIGluY3JlYXNpbmds
eSBpbmNsaW5lZCB0byBhY2NlcHQgeW91ciBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgdGl0bGUg
ZnJvbSDigJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0
aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ0uICBXaGlsZSB0aGUgYWJzdHJhY3QgYWxyZWFkeSBtYWtl
cyBpdCBjbGVhciB0aGF0IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgQVMgZGlzY292ZXJ5
LCBkb2luZyBzbyBpbiB0aGUgdGl0bGUgc2VlbXMgbGlrZSBpdCBjb3VsZCBoZWxwIGNsYXJpZnkg
dGhpbmdzLCBnaXZlbiB0aGF0IGEgbG90IG9mIHRoZSBkaXNjdXNzaW9uIHNlZW1zIHRvIGJlIGFi
b3V0IHJlc291cmNlIGRpc2NvdmVyeSwgd2hpY2ggaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBkb2N1
bWVudC4NCg0KDQoNCg0KDQoNCg0KSeKAmW0gbm90IHNheWluZyB0aGF0IHJlc291cmNlIGRpc2Nv
dmVyeSBpc27igJl0IGltcG9ydGFudCDigJMgaXQgaXMg4oCTIGJ1dCB1bmxpa2UgYXV0aG9yaXph
dGlvbiBzZXJ2ZXIgZGlzY292ZXJ5LCB3aGVyZSB0aGVyZeKAmXMgbG90cyBvZiBleGlzdGluZyBw
cmFjdGljZSwgaW5jbHVkaW5nIHVzaW5nIHRoZSBleGlzdGluZyBkYXRhIGZvcm1hdCBmb3IgZGVz
Y3JpYmluZyBPQXV0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmVu4oCZdCBiZWluZyB1c2VkIHdp
dGggT3BlbklEIENvbm5lY3QsIHRoZXJl4oCZcyBubyBleGlzdGluZyBwcmFjdGljZSB0byBzdGFu
ZGFyZGl6ZSBmb3IgcmVzb3VyY2UgZGlzY292ZXJ5LiAgVGhlIHRpbWUgdG8gY3JlYXRlIGEgc3Rh
bmRhcmQgZm9yIHRoYXQgc2VlbXMgdG8gYmUgYWZ0ZXIgZXhpc3RpbmcgcHJhY3RpY2UgaGFzIGVt
ZXJnZWQuICBJdCAqbWlnaHQqIG9yIG1pZ2h0IG5vdCB1c2UgbmV3IG1ldGFkYXRhIHZhbHVlcyBp
biB0aGUgQVMgZGlzY292ZXJ5IGRvY3VtZW50LCBidXQgdGhhdOKAmXMgc3RpbGwgdG8gYmUgZGV0
ZXJtaW5lZC4gIFRoZSBvbmUgcmVhc29uIHRvIGxlYXZlIHRoZSB0aXRsZSBhcy1pcyBpcyB0aGF0
IHJlc291cmNlIGRpc2NvdmVyeSBtaWdodCBlbmQgdXAgaW52b2x2aW5nIGV4dGVuc2lvbnMgdG8g
dGhpcyBtZXRhZGF0YSBmb3JtYXQgaW4gc29tZSBjYXNlcy4NCg0KDQoNCg0KDQoNCg0KSSB0aGlu
ayBhbiBhbmFsb2d5IHRvIHRoZSBjb3JlIE9BdXRoIGRvY3VtZW50cyBSRkMgNjc0OSBhbmQgUkZD
IDY3NTAgYXBwbGllcy4gIDY3NDkgaXMgYWJvdXQgdGhlIEFTLiAgNjc1MCBpcyBhYm91dCB0aGUg
UlMuICBUaGUgZGlzY292ZXJ5IGRvY3VtZW50IGlzIGFib3V0IHRoZSBBUy4gIFdlIGRvbuKAmXQg
eWV0IGhhdmUgYSBzcGVjaWZpY2F0aW9uIG9yIGV4aXN0aW5nIHByYWN0aWNlIGZvciBSUyBkaXNj
b3ZlcnksIHdoaWNoIHdvdWxkIGJlIHRoZSA2NzUwIGFuYWxvZ3kuDQoNCg0KDQoNCg0KDQoNCklu
IHN1bW1hcnksIHdoaWNoIHRpdGxlIGRvIHBlb3BsZSBwcmVmZXI/DQoNCg0KDQrCtyAgICAgICDi
gJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdDQoNCg0KDQrCtyAgICAgICDigJxPQXV0aCAyLjAgQXV0
aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ54oCdDQoNCg0KDQoNCg0KDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN
Cg0KDQogIDw+DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyA8
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnPl0gT24gQmVoYWxmIE9mIFZsYWRpbWlyIER6aHV2aW5vdg0KDQpTZW50OiBUaHVyc2RheSwg
RmVicnVhcnkgMjUsIDIwMTYgMTI6NTkgQU0NCg0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz4gPG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYu
b3JnPg0KDQoNCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBM
b2NhdGlvbg0KDQoNCg0KDQoNCg0KDQpJbiBPSURDIHRoZSBkaXNjb3ZlcnkgZG9jIGlzIG9mIGdy
ZWF0IHV0aWxpdHkgdG8gZGV2ZWxvcGVycyBhbmQgaW50ZWdyYXRvcnMuIERldmVsb3BlcnMgYWxz
byB0ZW5kIHRvIGZpbmQgaXQgYSBtb3JlIGFjY3VyYXRlIGFuZCBjb21wbGV0ZSBkZXNjcmlwdGlv
biBvZiBob3cgdG8gc2V0IHVwIGEgY2xpZW50IGZvciBhIHBhcnRpY3VsYXIgZGVwbG95bWVudCwg
Y29tcGFyZWQgdG8gdHJhZGl0aW9uYWwgb25saW5lIGRvY3MsIHdoaWNoIG1heSBiZSBub3QgYmUg
dXAgdG8gZGF0ZSwgb3IgZXZlbiBtaXNzaW5nLiBWZXJ5IG11Y2ggbGlrZSBhdXRvLWdlbmVyYXRl
ZCBTd2FnZ2VyIGFuZCBKYXZhRG9jcy4NCg0KDQoNCkhlcmUgYXJlIHNvbWUgZXhhbXBsZSBPSURD
IGRpc2NvdmVyeSBkb2NzOg0KDQoNCg0KaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxs
LWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIDxodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20v
LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24+PGh0dHBzOi8vYWNjb3VudHMuZ29vZ2xl
LmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbj4NCg0KDQoNCmh0dHBzOi8vd3d3
LnBheXBhbG9iamVjdHMuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIDxodHRw
czovL3d3dy5wYXlwYWxvYmplY3RzLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlv
bj48aHR0cHM6Ly93d3cucGF5cGFsb2JqZWN0cy5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZp
Z3VyYXRpb24+DQoNCg0KDQpodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZmFicmlr
YW1iMmMub25taWNyb3NvZnQuY29tL3YyLjAvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRp
b24gPGh0dHBzOi8vbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbS9mYWJyaWthbWIyYy5vbm1pY3Jv
c29mdC5jb20vdjIuMC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbj48aHR0cHM6Ly9s
b2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2ZhYnJpa2FtYjJjLm9ubWljcm9zb2Z0LmNvbS92Mi4w
Ly53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPg0KDQoNCg0KDQoNCldpdGggdGhpcyBk
aXNjb3ZlcnkgZG9jdW1lbnQgaW4gcGxhY2Ugc2V0dXAgb2YgaWRlbnRpdHkgZmVkZXJhdGlvbiBj
YW4gdGhlbiBiZSBlYXNpbHkgc2NyaXB0ZWQuIEZvciBleGFtcGxlOg0KDQoNCg0KaHR0cDovL2Rv
Y3MuYXdzLmFtYXpvbi5jb20vSUFNL2xhdGVzdC9Vc2VyR3VpZGUvaWRfcm9sZXNfcHJvdmlkZXJz
X2NyZWF0ZV9vaWRjX3ZlcmlmeS10aHVtYnByaW50Lmh0bWwgPGh0dHA6Ly9kb2NzLmF3cy5hbWF6
b24uY29tL0lBTS9sYXRlc3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVyc19jcmVhdGVfb2lk
Y192ZXJpZnktdGh1bWJwcmludC5odG1sPjxodHRwOi8vZG9jcy5hd3MuYW1hem9uLmNvbS9JQU0v
bGF0ZXN0L1VzZXJHdWlkZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRlX29pZGNfdmVyaWZ5LXRo
dW1icHJpbnQuaHRtbD4NCg0KDQoNCg0KDQpOb3csIGRvZXMgdGhhdCBkaWN0YXRlIGFueSBwYXJ0
aWN1bGFyIGFwcCBhcmNoaXRlY3R1cmU/IE15IHJlYWRpbmcgb2YgdGhlIHNwZWMgaXMgdGhhdCBp
dCBkb2Vzbid0LCBhbmQgaXQgc2hvdWxkbid0IGVpdGhlci4gQnkgc3RheWluZyBuZXV0cmFsIG9u
IHRoZSB0b3BpY3Mgb2YgUlMgZGlzY292ZXJ5IGFuZCByZWdpc3RlcmluZyBSUHMgd2l0aCBSU3Mu
IEFuZCBob3cgb25lIGFycml2ZXMgYXQgdGhlICIud2VsbC1rbm93bi8uLi4iLiBJJ20gbm90IGV2
ZW4gc3VyZSB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBzaG91bGQgYmUgYSB0b3BpYyBvZiB0aGlz
IFdHLiBQZXJoYXBzIHRvIHRoaXMgZW5kLCBhbmQgdG8gcHJldmVudCBjb25mdXNpb24gdGhhdCB0
aGUgc3BlYyBpcyB0cnlpbmcgdG8gZG8gc29tZXRoaW5nIG1vcmUsIGEgbW9yZSBzcGVjaWZpYyB0
aXRsZSB3b3VsZCBzdWl0IGl0IGJldHRlci4gRS5nLiAiQVMgRGlzY292ZXJ5Ii4NCg0KDQoNCkNo
ZWVycywNCg0KDQoNClZsYWRpbWlyDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiAyNS8wMi8xNiAwMjoy
NSwgUGhpbCBIdW50IChJRE0pIHdyb3RlOg0KDQoNCg0KQW5kIHNvIGRvZXMgb3JhY2xlIGFuZCBz
byBkb2VzIGdvb2dsZS4gRWFjaCBkaWZmZXJlbnQuDQoNCg0KDQpTbyBob3cgY2FuIGFuIGFwcCBk
aWN0YXRlIGl0IHRoZW4gdW5sZXNzIHdlIGFsbCBnbyB0byBhIGNvbW1vbiBhcmNoaXRlY3R1cmU/
DQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDE2OjA0LCBNaWtlIEpvbmVz
IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv
c29mdC5jb20+IDxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KDQoNCkF6dXJlIGRlZmluZXMgd2F5
cyBmb3IgcmVzb3VyY2Ugc2VydmVycyB0byBiZSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIGNs
aWVudCBhbmQgZm9yIGNsaWVudHMgdG8gZHluYW1pY2FsbHkgcmVxdWVzdCBhbiBhY2Nlc3MgdG9r
ZW4gZm9yIHVzZSBhdCBhIHBhcnRpY3VsYXIgcmVzb3VyY2Ugc2VydmVyLiAgWW91IGNhbiBjYWxs
IHRoYXQgY3VzdG9tIGFyY2hpdGVjdHVyZSBpZiB5b3Ugd2FudC4gIEl04oCZcyB3ZWxsLWRlZmlu
ZWQgYnV0IGl04oCZcyBub3QgY3VycmVudGx5IGluIHRoZSBzdGFuZGFyZHMgcmVhbG0uICBJIGtu
b3cgdGhhdCBHb29nbGUgaGFzIHN5bnRheCBmb3IgZG9pbmcgdGhlIHNhbWUsIGFzIEnigJltIHN1
cmUgZG8gYSBsb3Qgb2Ygb3RoZXIgY2xvdWQgT0F1dGggZGVwbG95bWVudHMsIHN1Y2ggYXMgT3Jh
Y2xl4oCZcy4gIEZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIHdvcmtpbmcgZ3JvdXAgdGFsa2Vk
IGFib3V0IHBvc3NpYmx5IHByb2R1Y2luZyBhIHN0YW5kYXJkIHZlcnNpb24gb2Ygc3ludGF4IGZv
ciBtYWtpbmcgdGhlc2Uga2luZHMgb2YgcmVxdWVzdHMgZHVyaW5nIG91ciBkaXNjdXNzaW9ucyBp
biBQcmFndWUgKGR1cmluZyB0aGUgVG9rZW4gRXhjaGFuZ2UgZGlzY3Vzc2lvbikgYnV0IG5vYm9k
eSBoYXMgcnVuIHdpdGggdGhpcyB5ZXQuDQoNCg0KDQpJbiB0aGlzIHNlbnNlLCB5ZXMsIEF6dXJl
IGlzIGFuIGFwcGxpY2F0aW9uIG9mIHRoZSBraW5kIHdl4oCZcmUgdGFsa2luZyBhYm91dC4gIEF6
dXJlIGFscmVhZHkgZG9lcyBkZWZpbmUgc3BlY2lmaWMgbmV3IE9BdXRoIDIuMCBkaXNjb3Zlcnkg
bWV0YWRhdGEgdmFsdWVzIHRoYXQgYXJlIHVzZWQgaW4gcHJvZHVjdGlvbi4gIEEgcmVnaXN0cnkg
anVzdCBkb2VzbuKAmXQgeWV0IGV4aXN0IGluIHdoaWNoIGl0IGNhbiByZWdpc3RlciB0aG9zZSB0
aGF0IGFyZSBvZiBnZW5lcmFsIGFwcGxpY2FiaWxpdHkuDQoNCg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K
DQoNCg0KRnJvbTogUGhpbCBIdW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20g
PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t
Pl0NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAzOjUyIFBNDQoNClRvOiBN
aWtlIEpvbmVzDQoNCkNjOiA8b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4g
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KDQpTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uDQoNCg0KDQpNaWtl
DQoNCg0KDQpUYWtlIGEgbG9vayBhdCB0aGUgYXNzdW1wdGlvbnMgeW91IGFyZSBtYWtpbmcuDQoN
Cg0KDQpZb3Ugc2VlbSB0byBiZSBhc3N1bWluZyBhcHBsaWNhdGlvbiBzb2Z0d2FyZSBkaWN0YXRl
cyBvYXV0aCBpbmZyYXN0cnVjdHVyZSBhcmNoaXRlY3R1cmUgYnkgc3VnZ2VzdGluZyB0aGF0IGFw
cHMgcmVnaXN0ZXIgaW4gaWFuYS4NCg0KDQoNCldvdWxkIG1zIGF6dXJlIGFsbG93IGN1c3RvbSBh
cmNoPw0KDQoNCg0KUGhpbA0KDQoNCg0KT24gRmViIDI0LCAyMDE2LCBhdCAxNToyOCwgTWlrZSBK
b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0Bt
aWNyb3NvZnQuY29tPiA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRv
Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCg0KDQpUaGUgVXNlckluZm8g
RW5kcG9pbnQgcGF0aCBpc27igJl0IGZpeGVkIGFuZCBzbyBoYXMgdG8gYmUgZGlzY292ZXJlZC4N
Cg0KDQoNCkkgYWdyZWUgdGhhdCBmb3Igc29tZSBPQXV0aCBwcm9maWxlcywgb25lIG9yIG1vcmUg
cmVzb3VyY2Ugc2VydmVycyB3aWxsIGhhdmUgdG8gYmUgZGlzY292ZXJlZCBzdGFydGluZyBmcm9t
IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFdvcmtpbmcgZ3JvdXAgbWVtYmVycyBoYXZlIGFs
c28gZGVzY3JpYmVkIHdhbnRpbmcgdG8gZGlzY292ZXIgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHN0
YXJ0aW5nIGZyb20gcmVzb3VyY2Ugc2VydmVycy4gIFRoZXJlIGlzbuKAmXQgYSBzdGFuZGFyZCBw
cmFjdGljZSBmb3IgYW55IG9mIHRoaXMsIHdoaWNoIGlzIHdoeSBpdOKAmXMgaW50ZW50aW9uYWxs
eSBsZWZ0IG91dCBvZiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KT25jZSB0aGUg
SUFOQSBPQXV0aCBEaXNjb3ZlcnkgTWV0YWRhdGEgUmVnaXN0cnkgaGFzIGJlZW4gZXN0YWJsaXNo
ZWQsIHdoaWNoIHdpbGwgaGFwcGVuIGFmdGVyIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gaGFz
IGJlZW4gYXBwcm92ZWQsIGl0IHdpbGwgYmUgZWFzeSBmb3Igc3Vic2VxdWVudCBzcGVjaWZpY2F0
aW9ucyB0byBkb2N1bWVudCBleGlzdGluZyBwcmFjdGljZSBmb3IgZGlmZmVyZW50IE9BdXRoIHBy
b2ZpbGVzIGFuZCByZWdpc3RlciBkaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzIHN1cHBvcnRpbmcg
dGhlbS4gIFNvbWUgb2YgdGhvc2UgdmFsdWVzIHdpbGwgbGlrZWx5IGRlZmluZSB3YXlzIHRvIGRp
c2NvdmVyIHJlc291cmNlIHNlcnZlcnMsIHdoZW4gYXBwbGljYWJsZS4NCg0KDQoNCkJ1dCBmaXJz
dCwgd2UgbmVlZCB0byBmaW5pc2ggdGhlIGV4aXN0aW5nIHNwZWMsIHNvIHRoYXQgdGhlIHJlZ2lz
dHJ5IGVuYWJsaW5nIHRoZXNlIGV4dGVuc2lvbnMgZ2V0cyBlc3RhYmxpc2hlZCBpbiB0aGUgZmly
c3QgcGxhY2UuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KRnJvbTogUGhpbCBIdW50IChJ
RE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20gPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPl0NCg0KU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAyNCwgMjAxNiAyOjEzIFBNDQoNClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IDxtYWls
dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGll
dGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1h
aWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4w
IERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KWXVwLiBBbmQgYmVjYXVzZSB0aGVyZSBtYW55IHJl
bGF0aW9ucyB0aGUgY2xpZW50IG1pc3QgYmUgYWJsZSB0byBkaXNjb3ZlciBpdC4gVGhlIGNsaWVu
dCBkb2VzIG5vdCBrbm93IGlmIHRoZSByZXMgc2VydmVyIGlzIGxlZ2l0Lg0KDQoNCg0KVGhlIHVz
ZXJpbmZvIGlzIGFsd2F5cyBmaXggYW5kIHNvIHUgZG9udCBuZWVkIGRpc2NvdmVyeS4NCg0KDQoN
ClBoaWwNCg0KDQoNCk9uIEZlYiAyNCwgMjAxNiwgYXQgMTQ6MDUsIE1pa2UgSm9uZXMgPE1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bT4gPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQoNCg0KSW4gT3BlbklEIENvbm5lY3QsIHRoZXJl
4oCZcyBhIHJlc291cmNlIHNlcnZlciBjYWxsZWQgdGhlIFVzZXJJbmZvIEVuZHBvaW50IHRoYXQg
cmV0dXJucyBjbGFpbXMgYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlciBhcyBhIEpTT04gZGF0
YSBzdHJ1Y3R1cmUuICBJdHMgbG9jYXRpb24gaXMgcHVibGlzaGVkIGluIE9wZW5JRCBDb25uZWN0
IGRpc2NvdmVyeSBtZXRhZGF0YSBhcyB0aGUg4oCcdXNlcmluZm9fZW5kcG9pbnTigJ0gbWV0YWRh
dGEgdmFsdWUsIHdoaWNoIGlzIGRlZmluZWQgYXQgaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Bl
bmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0YWRhdGEgPGh0dHA6Ly9v
cGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCNQcm92aWRl
ck1ldGFkYXRhPjxodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3Zl
cnktMV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YT4uDQoNCg0KDQpXZSBkaWRu4oCZdCBpbmNsdWRl
IHRoZSBVc2VySW5mbyBFbmRwb2ludCBpbiB0aGUgZ2VuZXJpYyBPQXV0aCBkaXNjb3Zlcnkgc3Bl
YyBzaW5jZSBpbiBPQXV0aCwgdGhlcmUgYXJlIGxvdHMgb2YgcG9zc2libGUgcmVsYXRpb25zaGlw
cyBiZXR3ZWVuIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgcmVzb3VyY2Ugc2VydmVycyBhbmQg
dGhleSBuZWVkbuKAmXQgYmUgb25lLXRvLW9uZSwgYXMgaXMgYmVpbmcgYWN0aXZlbHkgZGlzY3Vz
c2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAgRm9yIGluc3RhbmNlLCBzZWUgR2VvcmdlIEZsZXRj
aGVy4oCZcyByZWNlbnQgY29udHJpYnV0aW9uLg0KDQoNCg0KVGhhbmtzIGZvciB0aGUgZ29vZCBk
aXNjdXNzaW9uLCBQaGlsLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCkZyb206IFBoaWwg
SHVudCAoSURNKSBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIDxtYWlsdG86cGhpbC5odW50
QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT5dDQoNClNlbnQ6IFdlZG5l
c2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMToyNSBQTQ0KDQpUbzogTWlrZSBKb25lcw0KDQpDYzog
PG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KV2hlcmUgaXMgdGhlIHByb2ZpbGUg
ZW5kcG9pbnQgKG9pZGMncyByZXNvdXJjZSBzZXJ2ZXIpIHB1Ymxpc2hlZD8gKEZvciB0aGUgbm9u
IE9JREMgcGVvcGxlIG9uIHRoZSBsaXN0KS4NCg0KDQoNClBoaWwNCg0KDQoNCk9uIEZlYiAyNCwg
MjAxNiwgYXQgMTM6MDksIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT48
bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gPG1haWx0bzpNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3Rl
Og0KDQoNCg0KVG8gdGhlIGV4dGVudCB0aGF0IGdlbmVyaWMgT0F1dGggMi4wIG5lZWRzIHRvIHB1
Ymxpc2ggc29tZSBvZiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBPcGVuSUQgQ29ubmVjdCDigJMg
d2hpY2ggaXMgYnVpbHQgb24gZ2VuZXJpYyBPQXV0aCAyLjAg4oCTIGl0IG1ha2VzIHNlbnNlIHRv
IHB1Ymxpc2ggdGhhdCBpbmZvcm1hdGlvbiB1c2luZyBleGFjdGx5IHRoZSBzYW1lIHN5bnRheCwg
c2luY2UgdGhhdCBzeW50YXggaXMgYWxyZWFkeSBpbiB3aWRlc3ByZWFkIHVzZS4gIFRoYXQgd2hh
dCB0aGlzIGRyYWZ0IGFjY29tcGxpc2hlcy4NCg0KDQoNClRoZXJl4oCZcyBub3RoaW5nIENvbm5l
Y3Qtc3BlY2lmaWMgYWJvdXQgdXNpbmcgbWV0YWRhdGEgcmVzcG9uc2UgdmFsdWVzIGxpa2U6DQoN
Cg0KDQogICAiYXV0aG9yaXphdGlvbl9lbmRwb2ludCI6ICJodHRwczovL3NlcnZlci5leGFtcGxl
LmNvbS9hdXRob3JpemUiPGh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGhvcml6ZT4gPGh0
dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL2F1dGhvcml6ZT48aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
ZS5jb20vYXV0aG9yaXplPiwNCg0KICAgInRva2VuX2VuZHBvaW50IjogImh0dHBzOi8vc2VydmVy
LmV4YW1wbGUuY29tL3Rva2VuIjxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbj4gPGh0
dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuPjxodHRwczovL3NlcnZlci5leGFtcGxlLmNv
bS90b2tlbj4sDQoNCiAgICJ0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkIjog
WyJjbGllbnRfc2VjcmV0X2Jhc2ljIiwgInByaXZhdGVfa2V5X2p3dCJdLA0KDQogICAicmVnaXN0
cmF0aW9uX2VuZHBvaW50IjogImh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyIjxo
dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdpc3Rlcj4gPGh0dHBzOi8vc2VydmVyLmV4YW1w
bGUuY29tL3JlZ2lzdGVyPjxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdpc3Rlcj4sDQoN
CiAgICJyZXNwb25zZV90eXBlc19zdXBwb3J0ZWQiOiAgWyJjb2RlIiwgInRva2VuIl0sDQoNCiAg
ICJzZXJ2aWNlX2RvY3VtZW50YXRpb24iOiAiaHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2
aWNlX2RvY3VtZW50YXRpb24uaHRtbCI8aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2aWNl
X2RvY3VtZW50YXRpb24uaHRtbD4gPGh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vc2VydmljZV9k
b2N1bWVudGF0aW9uLmh0bWw+PGh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vc2VydmljZV9kb2N1
bWVudGF0aW9uLmh0bWw+LA0KDQoNCg0KSXMgdGhlcmUgYSByZWFzb24gdGhhdCB5b3Ugd291bGQg
bGlrZSB0aGUgc3ludGF4IGZvciBhbnkgb2YgdGhlc2Ugb3IgdGhlIG90aGVyIGdlbmVyYWxseSBh
cHBsaWNhYmxlIE9BdXRoIDIuMCBtZXRhZGF0YSB2YWx1ZXMgdG8gYmUgZGlmZmVyZW50PyAgSSBk
b27igJl0IHNlZSBhbnkgZ29vZCByZWFzb24gZm9yIHVubmVjZXNzYXJ5IGRpZmZlcmVuY2VzIHRv
IGJlIGludHJvZHVjZWQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KRnJvbTogUGhpbCBI
dW50IChJRE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20gPG1haWx0bzpwaGlsLmh1bnRA
b3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPl0NCg0KU2VudDogV2VkbmVz
ZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMjo0NSBQTQ0KDQpUbzogQW50aG9ueSBOYWRhbGluIDx0
b255bmFkQG1pY3Jvc29mdC5jb20+PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+IDxtYWls
dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPjxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0K
DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjxtYWlsdG86TWlj
aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IDxvYXV0aEBpZXRmLm9y
Zz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWlsdG86
b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRmLm9yZz48bWFpbHRvOm9hdXRoQGlldGYub3JnPiA8
bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQoNClN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb24NCg0KDQoNCk1pa2UN
Cg0KDQoNClB1Ymxpc2hpbmcgb24gZGV2IHBhZ2VzIGRvZXMgbm90IHdvcmsgZm9yIHNvZnR3YXJl
IChlc3Agb3BlbiBzb3VyY2UpIHRoYXQgaXMgZGVwbG95ZWQgYm90aCBpbiBlbnRlcnByaXNlcyBh
bmQgb24gUGFhUyBjbG91ZCBwcm92aWRlcnMuDQoNCg0KDQpUaGUgY3VycmVudCBkcmFmdCBpcyBt
YXkgY29kaWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBhbmQgYmUgYXBwcm9wcmlhdGUgZm9yIG9p
ZGMgYnV0IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJpYyBvYXV0aC4gVGhlcmUgaXMgbm8gZ2Vu
ZXJpYyBvYXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGltZS4NCg0KDQoNClBoaWwNCg0KDQoNCk9u
IEZlYiAyNCwgMjAxNiwgYXQgMTA6MjUsIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3Nv
ZnQuY29tPjxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPiA8bWFpbHRvOnRvbnluYWRAbWlj
cm9zb2Z0LmNvbT48bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCg0KDQpT
dXJlIHRoZXJlIGlzLCBpdCBpcyBhcyB5b3UgaGF2ZSBub3cgbWFkZSBpdCBmYXIgZWFzaWVyIGFu
ZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9lcyBub3QgZXZlbiBhZGRyZXNzIHRoaXMN
Cg0KDQoNCkZyb206IE1pa2UgSm9uZXMNCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwg
MjAxNiAxMDoyMiBBTQ0KDQpUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5j
b20+PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+IDxtYWlsdG86dG9ueW5hZEBtaWNyb3Nv
ZnQuY29tPjxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KDQpDYzogPG9hdXRoQGlldGYu
b3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0
bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVj
dDogUkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KQXMg
d2XigJlkIGRpc2N1c3NlZCBpbiBwZXJzb24sIHRoZXJl4oCZcyBubyBlZmZlY3RpdmUgc2VjdXJp
dHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGRpc2NvdmVyeSBpbmZvcm1hdGlvbiBiZWluZyBwdWJsaXNo
ZWQgaW4gYW4gYWQtaG9jIGZhc2hpb24gb24gZGV2ZWxvcGVyIHBhZ2VzIGFuZCBpdCBiZWluZyBw
dWJsaXNoZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQuICDigJxTZWN1cml0eSBieSBvYnNjdXJpdHni
gJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC4NCg0KDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQpG
cm9tOiBBbnRob255IE5hZGFsaW4NCg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAx
NiAxMDowMSBBTQ0KDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
PjxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiA8bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT48bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IFBo
aWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3Jh
Y2xlLmNvbT4gPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBv
cmFjbGUuY29tPjsgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpzYWtp
bXVyYUBnbWFpbC5jb20+IDxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11
cmFAZ21haWwuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5v
cmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRo
QGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGgg
Mi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KVGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRv
IGZpbmlzaCBzdGFuZGFyZGl6aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRo
YXTigJlzIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkLg0KDQoNCg0KVGhhdCBtYXkgYmUgd2lkZWx5
IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVkIGZvciBPQXV0aC4gVGhl
cmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2NvdmVyeSBmb3IgZW5kcG9p
bnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBPQXV0aCBzdGFuZGFyZCBzaW5jZSBp
dOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlv
biBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0aGUgZW5kcG9pbnQgbW9yZSBm
b2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1cHQgeW91ciBlbmRwb2ludHMsIHRo
YXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z
ICBzZWN0aW9uIGF0IGFsbA0KDQoNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnIDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KDQpTZW50OiBXZWRuZXNk
YXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDk6NTQgQU0NCg0KVG86IFBoaWwgSHVudCAoSURNKSA8cGhp
bC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4gPG1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjsgTmF0IFNh
a2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+IDxt
YWlsdG86c2FraW11cmFAZ21haWwuY29tPjxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPg0KDQpD
YzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPjxtYWlsdG86
b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRm
Lm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2Nh
dGlvbg0KDQoNCg0KVGhlIHBvaW50IG9mIHRoZSBXR0xDIGlzIHRvIGZpbmlzaCBzdGFuZGFyZGl6
aW5nIHRoZSBjb3JlIGRpc2NvdmVyeSBmdW5jdGlvbmFsaXR5IHRoYXTigJlzIGFscmVhZHkgd2lk
ZWx5IGRlcGxveWVkLg0KDQoNCg0KTm9uZSBvZiBOYXQgb3IgSm9obiBvciBJIGFyZSBzdWdnZXN0
aW5nIHRoYXQgYWRkaXRpb25hbCByZWxhdGVkIGZ1bmN0aW9uYWxpdHkgd29u4oCZdCBiZSBjcmVh
dGVkLiAgSeKAmW0gc3VyZSBpdCB3aWxsIGJlLiAgU29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2Ug
V2ViRmluZ2VyIHRvIGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiAgU29tZSB3aWxsIHBv
c3NpYmx5IHVzZSBsaW5rIGhlYWRlcnMuICBTb21lIHdpbGwgcG9zc2libHkgdXNlIGFwcGxpY2F0
aW9uLXNwZWNpZmljIC53ZWxsLWtub3duIHZhbHVlcy4gIEnigJltIHN1cmUgdGhlcmXigJlzIG90
aGVyIHRoaW5ncyBJIGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuICBBbGwgb2YgdGhlc2Ug
ZGVwZW5kIHVwb24gaGF2aW5nIGEgZGlzY292ZXJ5IG1ldGFkYXRhIGRvY3VtZW50IGZvcm1hdCBh
bmQgbm9uZSBvZiB0aGVtIGNoYW5nZSBpdCDigJMgb3RoZXIgdGhhbiBwb3NzaWJseSB0byByZWdp
c3RlciBhZGRpdGlvbmFsIGRpc2NvdmVyeSBtZXRhZGF0YSB2YWx1ZXMuDQoNCg0KDQpTbyBieSBh
bGwgbWVhbnMsIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBjb250aW51ZSBkaXNjdXNzaW5nIGlu
dmVudGluZyBwb3NzaWJsZSBuZXcgcmVsYXRlZCBtZWNoYW5pc21zIHRoYXQgbWFrZSBzZW5zZSBp
biBzb21lIGNvbnRleHRzLiAgQXQgdGhlIHNhbWUgdGltZSwgd2UgY2FuIGZpbmlzaCBzdGFuZGFy
ZGl6aW5nIHRoZSBhbHJlYWR5IHdpZGVseSBkZXBsb3llZCBjb3JlIGZ1bmN0aW9uYWxpdHkgdGhh
dCBhbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyB3aWxsIG5lZWQuDQoNCg0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoN
Cg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC
ZWhhbGYgT2YgUGhpbCBIdW50IChJRE0pDQoNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQs
IDIwMTYgODozOSBBTQ0KDQpUbzogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+PG1h
aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+IDxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPjxtYWls
dG86c2FraW11cmFAZ21haWwuY29tPg0KDQpDYzogPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1
dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz4gPG9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtPQVVUSC1X
R10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbg0KDQoNCg0KSSBhbSBzdWdnZXN0aW5nIHRo
YXQgcGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGlu
ZGljYXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmln
dXJhdGlvbiBkYXRhIGZvci4NCg0KDQoNClNvIGlmIHJlcy5leGFtcGxlLmV2aWwuY29tPGh0dHA6
Ly9yZXMuZXhhbXBsZS5ldmlsLmNvbT4gPGh0dHA6Ly9yZXMuZXhhbXBsZS5ldmlsLmNvbS8+PGh0
dHA6Ly9yZXMuZXhhbXBsZS5ldmlsLmNvbS8+IGlzIG5vdCBhIHZhbGlkIHJlc291cmNlIGVuZHBv
aW50IGZvciBhcy5leGFtcGxlLmNvbTxodHRwOi8vYXMuZXhhbXBsZS5jb20+IDxodHRwOi8vYXMu
ZXhhbXBsZS5jb20vPjxodHRwOi8vYXMuZXhhbXBsZS5jb20vPiB0aGUgYXV0aHogZGlzY292ZXJ5
IHNob3VsZCBmYWlsIGluIHNvbWUgd2F5IChlZyByZXR1cm4gbm90aGluZykuDQoNCg0KDQpUaGVy
ZSBtYXkgYmUgYmV0dGVyIHdheXMgdG8gZG8gdGhpcy4gRWcgY29tYmluZSBkaXNjb3ZlcnkuIE9y
IGNoYW5nZSB0aGUgb3JkZXIgb2YgZGlzY292ZXJ5Lg0KDQoNCg0KT25lIG9mIE9BdXRoJ3Mgc3Ry
ZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0YXJnZXQgb2YgYXV0aG9yaXphdGlv
biAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQuIEl0IGlzIG9mdGVuIGJvdW5kIHVw
IGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBvZnRlbiBpbXBsaWVkIDE6MSByZWxh
dGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdpdmVuIHRoYXQgaW4gZGlzY292ZXJ5
IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1cnJlZCBpdCBzZWVtcyBpbXBvcnRh
bnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFsaWQgY29tYmluYXRpb24gb2YgZW5k
cG9pbnRzIGV0Yy4NCg0KDQoNClRoaXMgaXMgd2h5IEkgd2FzIGRpc2FwcG9pbnRlZCBhYm91dCB3
Z2xjIG9uIGRpc2NvdmVyeS4gV2UgaGFkIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGdyb3VwIGFkb3B0
aW9uIGJ1dCB3ZSBoYXZlbid0IHJlYWxseSBkZWZpbmVkIHRoZSBmdWxsIHJlcXVpcmVtZW50cyBJ
TU8uDQoNCg0KDQpJIGFtIG9uIHZhY2F0aW9uIG9yIEkgd291bGQgcHV0IHNvbWUgdGhvdWdodCBp
bnRvIHNvbWUgZHJhZnQgY2hhbmdlcyBvciBhIG5ldyBkcmFmdC4gSSBhcG9sb2dpemUgSSBjYW4n
dCBkbyBpdCBub3cuDQoNCg0KDQpQaGlsDQoNCg0KDQpPbiBGZWIgMjQsIDIwMTYsIGF0IDA4OjEy
LCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48bWFpbHRvOnNha2ltdXJhQGdtYWls
LmNvbT4gPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PG1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20+IHdyb3RlOg0KDQoNCg0KSGkgUGhpbCwNCg0KDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0
IHRoZSBBUyBtZXRhZGF0YSBzaG91bGQgaW5jbHVkZSB0aGUgUlMgVVJJcz8gQ3VycmVudGx5LCBp
dCBkb2VzIG5vdCwgYnV0IGl0IGNhbiBiZSBkb25lLCBJIGd1ZXNzLg0KDQoNCg0KVGhlIHdheSBv
YXV0aC1tZXRhIHdvcmtzIGlzIHRoYXQNCg0KDQoNCjEuIFJTIHRlbGxzIHRoZSBjbGllbnQgd2hl
cmUgdGhlIEFTIGlzLg0KDQoyLiBBUyB0ZWxscyB0aGUgY2xpZW50IHdoaWNoIFJTIGVuZHBvaW50
cyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuDQoNCg0KDQpFdmVuIGlmIHRoZXJlIGlzIGEgYmFkIEFT
IHdpdGggYSB2YWxpZCBjZXJ0cyB0aGF0IHByb3hpZXMgdG8gdGhlIGdvb2QgUlMsIHRoZSBjbGll
bnQgd2lsbCBub3Qgc2VuZCB0aGUgdG9rZW4gdGhlcmUgYXMgdGhlIGF1dGh6IHNlcnZlciB3aWxs
IHNheSB0aGF0IGlzIG5vdCB0aGUgcGxhY2UgdGhlIGNsaWVudCBtYXkgd2FudCB0byBzZW5kIHRo
ZSB0b2tlbiB0by4NCg0KDQoNCk5hdA0KDQoNCg0KMjAxNuW5tDLmnIgyNOaXpSjmsLQpIDIzOjU5
IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbT4gPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFj
bGUuY29tPjoNCg0KTmF0LA0KDQoNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBoYXZpbmcgdGhlIHJl
c291cmNlIHNlcnZlciB0ZWxsIHRoZSBjbGllbnQgd2hlcmUgaXRzIGF1dGhvcml6YXRpb24gc2Vy
dmVyIGlzIHNlY3VyZSBieSBpdHNlbGYuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQXV0
aG9yaXphdGlvbiBTZXJ2ZXIgYW5kIHRoZSBSZXNvdXJjZSBzZXJ2ZXIgbmVlZCB0byBiZSBib3Vu
ZCB0b2dldGhlciBpbiBvbmUgb2YgdGhlIGRpc2NvdmVyeSBlbmRwb2ludHMgKHRoZSByZXNvdXJj
ZSBhbmQvb3IgdGhlIG9hdXRoIHNlcnZpY2UgZGlzY292ZXJ5KS4NCg0KDQoNCklmIGEgY2xpZW50
IGRpc2NvdmVycyBhIGZha2UgcmVzb3VyY2Ugc2VydmVyIHRoYXQgaXMgcHJveHlpbmcgZm9yIGEg
cmVhbCByZXNvdXJjZSBzZXJ2ZXIgdGhlIGN1cnJlbnQgZGlzY292ZXJ5IHNwZWMgd2lsbCBub3Qg
bGVhZCB0aGUgY2xpZW50IHRvIHVuZGVyc3RhbmQgaXQgaGFzIHRoZSB3cm9uZyByZXNvdXJjZSBz
ZXJ2ZXIuIFJhdGhlciB0aGUgZmFrZSByZXNvdXJjZSBzZXJ2aWNlIHdpbGwganVzdCBoYXZlIGEg
ZmFrZSBkaXNjb3Zlcnkgc2VydmljZS4gVGhlIGhhY2tlciBjYW4gbm93IGludGVyY2VwdCByZXNv
dXJjZSBwYXlsb2FkIGFzIHdlbGwgYXMgdG9rZW5zIGJlY2F1c2UgdGhleSB3ZXJlIGFibGUgdG8g
Y29udmluY2UgdGhlIGNsaWVudCB0byB1c2UgdGhlIGxlZ2l0IGF1dGhvcml6YXRpb24gc2Vydmlj
ZSBidXQgdXNlIHRoZSB0b2tlbiBhZ2FpbnN0IHRoZSBoYWNrZXJzIHByb3h5Lg0KDQoNCg0KVGhl
IE9BdXRoIERpc2NvdmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0
aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291
cmNlIGVuZHBvaW50Lg0KDQoNCg0KVGhpcyBub3Qgb25seSB3b3JrcyBpbiBub3JtYWwgT0F1dGgg
YnV0IHNob3VsZCBhZGQgc2VjdXJpdHkgZXZlbiB0byBVTUEgc2l0dWF0aW9ucy4NCg0KDQoNClBo
aWwNCg0KDQoNCkBpbmRlcGVuZGVudGlkDQoNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8v
d3d3LmluZGVwZW5kZW50aWQuY29tLz4gPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPjxo
dHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFp
bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjxt
YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gRmVi
IDI0LCAyMDE2LCBhdCAzOjU0IEFNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT48
bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4gPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PG1h
aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+IHdyb3RlOg0KDQoNCg0KDQoNCkhpIFRob21hcywNCg0K
DQoNCmlubGluZToNCg0KDQoNCjIwMTblubQy5pyIMjLml6Uo5pyIKSAxODo0NCBUaG9tYXMgQnJv
eWVyIDx0LmJyb3llckBnbWFpbC5jb20+PG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+IDxtYWls
dG86dC5icm95ZXJAZ21haWwuY29tPjxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPjoNCg0KQ291
bGRuJ3QgdGhlIGRvY3VtZW50IG9ubHkgZGVzY3JpYmUgdGhlIG1ldGFkYXRhPw0KDQpJIHF1aXRl
IGxpa2UgdGhlIGlkZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5
IHdhbnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMg
LyB0byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICJhdXRvLWNv
bmZpZ3VyYXRpb24iLg0KDQpUaGUgbWV0YWRhdGEgZGVzY3JpYmVkIGhlcmUgd291bGQgdGhlbiBl
aXRoZXIgYmUgdXNlZCBhcy1pcywgYXQgYW55IFVSTCwgcmV0dXJuZWQgYXMgZHJhZnQtc2FraW11
cmEtb2F1dGgtbWV0YSBtZXRhZGF0YSBhdCB0aGUgUlM7IG9yIGFzIGEgYmFzaXMgZm9yIG90aGVy
IG1ldGFkYXRhIHNwZWNzIChsaWtlIE9wZW5JRCBDb25uZWN0KS4NCg0KV2l0aCBkcmFmdC1zYWtp
bXVyYS1vYXV0aC1tZXRhJ3MgImR1cmkiIGFuZCB0aGUgInNjb3BlIiBhdHRyaWJ1dGUgb2YgV1dX
LUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXIsIHlvdSBoYXZlIGV2ZXJ5dGhpbmcgeW91IG5l
ZWQgdG8gcHJvY2VlZA0KDQoNCg0KWXVwLiBUaGF0J3Mgb25lIG9mIHRoZSByZXF1aXJlbWVudHMg
dG8gYmUgUkVTVGZ1bCwgaXMgaXQgbm90Pw0KDQoNCg0KSW4gT0F1dGgncyBjYXNlLCB0aGUgcmVz
b3VyY2UgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNv
dXBsZWQuIChPdGhlcndpc2UsIHlvdSBuZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKQ0KDQpT
bywgdGhlIHJlc291cmNlIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byB0ZWxsIGVpdGhlciB0aGUg
bG9jYXRpb24gb2YgdGhlIGF1dGh6IGVuZHBvaW50LiBJbiBzb21lIHRydXN0ZWQgZW52aXJvbm1l
bnQsIHRoZSByZXNvdXJjZSBtYXkgYXMgd2VsbCByZXR1cm4gdGhlIGxvY2F0aW9uIG9mIHRoZSBh
dXRoeiBzZXJ2ZXIgY29uZmlndXJhdGlvbiBkYXRhLiBJbiB0aGVzZSBjYXNlcywgeW91IGRvIG5v
dCBoYXZlIHRvIGRlY2lkZSBvbiB3aGF0IC53ZWxsLWtub3duIHVyaSBhcyB5b3Ugc2F5LiBUaGlz
IGZyZWVzIHVwIGRldmVsb3BlcnMgZnJvbSBjb25maWd1cmF0aW9uIGZpbGUgbG9jYXRpb24gY29s
bGlzaW9ucyBldGMuIFdlIHNob3VsZCBzdHJpdmUgbm90IHRvIHBvbGx1dGUgdGhlIHVyaSBzcGFj
ZSBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KDQoNCg0KKHdlbGwsIGV4Y2VwdCBpZiB0aGVyZSBhcmUg
c2V2ZXJhbCBBU3MgZWFjaCB3aXRoIGRpZmZlcmVudCBzY29wZXM7IHNvdW5kcyBsaWtlIGFuIGVk
Z2UtY2FzZSB0byBtZSB0aG91Z2g7IG1heWJlIFJGQzY3NTAgc2hvdWxkIGluc3RlYWQgYmUgdXBk
YXRlZCB3aXRoIHN1Y2ggYSBwYXJhbWV0ZXIgc3VjaCB0aGF0IGFuIFJTIGNvdWxkIHJldHVybiBz
ZXZlcmFsIFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciwgZWFjaCB3aXRoIGl0cyBvd24gInNjb3Bl
IiBhbmQgImR1cmkiIHZhbHVlPykNCg0KDQoNClllYWgsIEkgZ3Vlc3MgaXQgaXMgYW4gZWRnZSBj
YXNlLiBJIHdvdWxkIHJhdGhlciBsaWtlIHRvIHNlZSB0aGVzZSBhdXRoeiBzZXJ2ZXJzIHRvIGRl
dmVsb3AgYSB0cnVzdCBmcmFtZXdvcmsgdW5kZXIgd2hpY2ggdGhleSBjYW4gYWdyZWUgb24gYSBz
aW5nbGUgc2V0IG9mIGNvbW1vbiBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLg0KDQoNCg0KQ2hlZXJz
LA0KDQoNCg0KTmF0DQoNCg0KDQoNCg0KDQoNCk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDEwOjU5
IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT48bWFpbHRvOmpyaWNoZXJAbWl0LmVk
dT4gPG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+IHdyb3Rl
Og0KDQpUaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBEaXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1
bCBhbmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0
aWxsIGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2YgaXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMu
IE9uZSBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxsIHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNl
IG9mIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292
ZXJ5IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGggZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBP
cGVuSUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFic29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFz
b24gdG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMgZGlzY292ZXJ5IG1lY2hhbmlzbS4NCg0KDQoN
CkkgcHJvcG9zZSB0aGF0IHdlIHVzZSDigJwvLndlbGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlv
bi1zZXJ2ZXLigJ0gYXMgdGhlIGRlZmF1bHQgZGlzY292ZXJ5IGxvY2F0aW9uLCBhbmQgc3RhdGUg
dGhhdCB0aGUgZG9jdW1lbnQgTUFZIGFsc28gYmUgcmVhY2hhYmxlIGZyb20g4oCcLy53ZWxsLWtu
b3duL29wZW5pZC1jb25maWd1cmF0aW9u4oCdIGlmIHRoZSBzZXJ2ZXIgYWxzbyBwcm92aWRlcyBP
cGVuSUQgQ29ubmVjdCBvbiB0aGUgc2FtZSBkb21haW4uIE90aGVyIGFwcGxpY2F0aW9ucyBTSE9V
TEQgdXNlIHRoZSBzYW1lIHBhcmFtZXRlciBuYW1lcyB0byBkZXNjcmliZSBPQXV0aCBlbmRwb2lu
dHMgYW5kIGZ1bmN0aW9ucyBpbnNpZGUgdGhlaXIgc2VydmljZS1zcGVjaWZpYyBkaXNjb3Zlcnkg
ZG9jdW1lbnQuDQoNCg0KDQog4oCUIEp1c3Rpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPjxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGggPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+PGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg+DQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlz
dA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4N
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1
dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4g
PG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIDxodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz48bWFpbHRvOk9BdXRoQGll
dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIDxo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPjxodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h
aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aD4NCg0KDQoNCg0KDQotLQ0KDQpWbGFkaW1pciBEemh1dmlub3YgOjogdmxhZGltaXJA
Y29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPiA8bWFpbHRvOnZs
YWRpbWlyQGNvbm5lY3QyaWQuY29tPjxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20+DQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRo
IG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aD48aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aD4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQoNCg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cg0K

--_000_BY2PR03MB442F67CB6EC7B1746B35CA7F5B80BY2PR03MB442namprd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN
Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu
LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFw
cGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxl
LW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5JIGtu
b3cgdGhhdCBhdCBsZWFzdCBpbiBBenVyZSwgZGV2ZWxvcGVycyBjYW4gZHluYW1pY2FsbHkgYWRk
IHJlc291cmNlcyBmb3IgdXNlIGJ5IHRoZSBjbGllbnQgdXNpbmcgdGhlIGRldmVsb3BlciBwb3J0
YWwgYXQgYW55IHRpbWUuJm5ic3A7IFRoZXJlZm9yZSwgYXQgY2xpZW50IGNvbmZpZ3VyYXRpb24N
CiB0aW1lLCB3aGljaCBpcyB3aGVuIEFTIGRpc2NvdmVyeSBpcyB1c2VkLCB0aGVyZSBpcyBub3Qg
YW4gYXV0aG9yaXRhdGl2ZSBsaXN0IG9mIHJlc291cmNlcyBhdmFpbGFibGUuJm5ic3A7IEkgYmVs
aWV2ZSB0aGF0IEJyaWFuIHNhaWQgYSBzaW1pbGFyIHRoaW5nIGFib3V0IGhpcyB1c2UgY2FzZXMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGVyZWZvcmUsIHdo
aWxlIHdoYXQgeW914oCZcmUgcHJvcG9zaW5nIG1heSAqPGI+c2VlbTwvYj4qLCBzaW1wbGUsIGJ1
dCBpdOKAmXMgKjxiPm5vdCBhY3R1YWxseTwvYj4qIHNpbXBsZSBhdCBhbGwuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48
L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBoaWwg
SHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNh
dHVyZGF5LCBGZWJydWFyeSAyNywgMjAxNiAxMDo1NyBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBK
b25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g
VmxhZGltaXIgRHpodXZpbm92ICZsdDt2bGFkaW1pckBjb25uZWN0MmlkLmNvbSZndDs7IG9hdXRo
QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBE
aXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UbyBjbGFyaWZ54oCmLiBJIGFtIDx1Pm5vdDwvdT4gc3VnZ2VzdGluZyB0aGF0IHdl
IG5lZWQgYSByZXNvdXJjZSBkaXNjb3ZlcnkgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBJIGFtIHN1Z2dlc3RpbmcgaXMgbXVjaCBz
aW1wbGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIHByb3Bvc2UgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjb25maXJtIHRoYXQgdGhlIGVu
ZHBvaW50IHRoYXQgdGhlIGNsaWVudCBoYXMgZGlzY292ZXJlZCBpcyBhIHJlc291cmNlIHRoYXQg
dGhlIEFTIGNhbiBpc3N1ZSB0b2tlbnMgZm9yIChpbiBvdGhlciB3b3JkcyBpcyBhIHZhbGlkIGF1
ZGllbmNlIGZvciB0aGUgdG9rZW5zKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3aWxsIHdvcmsgd2VsbCBpbiBVTUEgY2FzZXMgYW5k
IGl0IGNvbmZpcm1zIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQVMgYW5kIHRoZSBSUyBp
cyBpbiBmYWN0IHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SXQgYWxzbyBkZXRlY3RzIG1pcy1jb25maWd1cmF0aW9uIGNhc2VzIHRoYXQg
bWlnaHQgbmF0dXJhbGx5IG9jY3VyIGluIHNjZW5hcmlvcyB3aXRoIG11bHRpLXRlbmFuY2llcyBl
dGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQu
Y29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+
cGhpbC5odW50QG9yYWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIEZlYiAyNywgMjAxNiwgYXQgMTA6MzggQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9
Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMDAyMDYwIj5UaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byBwcm9wb3NlIHNwZWNpZmlj
IHRleHQsIFBoaWwuJm5ic3A7IFRoYXTigJlzIHJlYWxseSBoZWxwZnVsLiZuYnNwOyBJ4oCZbGwg
cGxhbiB0byBpbmNvcnBvcmF0ZSBhIHZlcnNpb24gb2YgdGhpcyBpbiB0aGUNCiBkcmFmdCBhZGRy
ZXNzaW5nIFdHTEMgY29tbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkgYWdyZWUgd2l0aCBWbGFkaW1pcuKAmXMg
b2JzZXJ2YXRpb24gdGhhdCBpdOKAmXMgZGlmZmljdWx0IHRvIGNvbWUgdXAgd2l0aCBhIGdlbmVy
YWwtcHVycG9zZSByZXNvdXJjZSBkaXNjb3ZlcnkgbWVjaGFuaXNtLiZuYnNwOyBUaGF0IGluIHBh
cnQsDQogaXMgYmVjYXVzZSwgYXMgQnJpYW4gcG9pbnRzIG91dCwgdGhlcmXigJlzIG9mdGVuIG5v
dCBhIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhdXRob3JpemF0aW9uIHNlcnZlcnMgYW5kIHJl
c291cmNlIHNlcnZlcnMuJm5ic3A7IEFzIEnigJl2ZSB3cml0dGVuIGJlZm9yZSwgSSBkbyBlbmNv
dXJhZ2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gd29yayBvbiBjcmVhdGluZyBzb2x1dGlvbnMgdG8g
cmVzb3VyY2UgZGlzY292ZXJ5IHRoYXQgd2lsbCB3b3JrIGZvciBzb21lDQogY29tbW9uIHVzZSBj
YXNlcy4mbmJzcDsgQnV0IHRoZSBnb29kIG5ld3MgaXMgdGhhdCB3aGlsZSByZXNvdXJjZSBkaXNj
b3ZlcnkgcmVxdWlyZXMgbmV3IGludmVudGlvbiwgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlzY292
ZXJ5IGRvZXMgbm90Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T0F1dGgNCiBbPGEg
aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjwvYj5WbGFkaW1pciBEemh1dmlub3Y8YnI+DQo8Yj5TZW50OjwvYj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U2F0dXJkYXksIEZl
YnJ1YXJ5IDI3LCAyMDE2IDEwOjMzIEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0
Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW09BVVRILVdHXSBPQXV0
aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gMjcvMDIvMTYgMjA6MTAsIFBoaWwgSHVudCB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPlRoZSBuYW1lIGNoYW5nZSBzZWVtcyBhcHByb3ByaWF0ZSBnaXZlbiB0aGF0IHRoZSBX
RyBtZW1iZXJzIGhhdmUgZGVjaWRlZCBub3QgdG8gYWRkcmVzcyB0aGUgaXNzdWUgb2YgcmVzb3Vy
Y2UgZGlzY292ZXJ5IGFzIHBhcnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWYgdGhlIGNvbnNlbnN1cyBpcyB0byBs
aW1pdCB0aGUgc2NvcGUgb2YgdGhlIHNwZWNpZmljYXRpb24sIHRoZW4gSSBzdWdnZXN0IHRoZSBm
b2xsb3dpbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlJlc291cmNlIERpc2NvdmVyeTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U2VjdXJlIGRpc2NvdmVyeSBvZiBy
ZXNvdXJjZSBlbmRwb2ludHMgaXMgb3V0LW9mLXNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4g
VGhpcyBzcGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhhdCB0aGUgY2xpZW50IGhhcyBhbHJlYWR5IHNl
Y3VyZWx5IGRpc2NvdmVyZWQgdGhlIGNvcnJlY3QgcmVzb3VyY2UgZW5kcG9pbnQgYW5kIHRoYXQg
dGhlIGNsaWVudCBoYXMgY29ycmVjdGx5IHNlbGVjdGVkIHRoZSBjb3JyZWN0IGNvcnJlc3BvbmRp
bmcgZGlzY292ZXJ5IGZvciBPQXV0aCBBdXRob3JpemF0aW9uIHNlcnZlci4gSW1wbGVtZW50ZXJz
IE1VU1QgY29uc2lkZXIgdGhhdCBpZiBhbiBpbmNvcnJlY3QgcmVzb3VyY2UgZW5kcG9pbnQgd2Fz
IGRpc2NvdmVyZWQgYnkgdGhlIGNsaWVudCB0aGF0IGFuIGF0dGFja2VyIHdpbGwgYmUgYWJsZSB0
byBzZXQgdXAgYSBtYW4taW4tdGhlLW1pZGRsZSBwcm94eSB0byBhIHJlYWwgcmVzb3VyY2Ugc2Vy
dmVyIHdpdGhvdXQgZGV0ZWN0aW9uIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBvciB0aGUg
Y2xpZW50LiA8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQpJIHN1cHBvcnQgdGhh
dC4gVGhpcyB3YXMgdGhlIHByaW1hcnkgY29uY2VybiBvZiBldmVyeW9uZSB3aG8gZmVsdCB1bmNv
bWZvcnRhYmxlIHdpdGggdGhlIG9yaWdpbmFsIGRyYWZ0IHdpdGggV2ViRmluZ2VyLWJhc2VkIGRp
c2NvdmVyeSBpbiBpdCwgc28gaXQgc2hvdWxkIGJlIGluY2x1ZGVkLjxicj4NCjxicj4NCjxicj4N
Cjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi
YWNrZ3JvdW5kOndoaXRlIj5JdCBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBldmVuIGluY2x1
ZGUgdGhpcyB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb24gYXMgYSBjYXV0aW9uYXJ5ICZxdW90O3Jl
ZCBmbGFnJnF1b3Q7IHRvIGltcGxlbWVudGVycy48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij4mIzQzOzE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uY2UgYWdhaW4sIEkgc3Ryb25nbHkgdXJnZSB0
aGUgV0cgdG8gYWN0dWFsbHkgaW5jbHVkZSBhIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBkaXNj
b3ZlcnkgdGhhdCB0aGUgb2F1dGggY2xpZXQgaGFzIGNvcnJlY3RseSBkaXNjb3ZlcmVkIGFuIGF1
dGhvcml6YXRpb24gc2VydmVyIHRoYXQgaXMgd2lsbGluZyBhbmQgYWJsZSB0byBpc3N1ZSBhY2Nl
c3MgdG9rZW5zIGZvciBhIGdpdmVuIHJlc291cmNlIGVuZHBvaW50LiBJIGJlbGlldmUgdGhpcyBy
ZWxhdGlvbnNoaXAgaXMgY3JpdGljYWwgdG8gc2VjdXJpdHkgb2YgT0F1dGggaW4gY2FzZXMgd2hl
cmUgcmVzb3VyY2UgZW5kcG9pbnRzIGFyZSBkaXNjb3ZlcmVkIGR5bmFtaWNhbGx5LiZuYnNwOyBP
ZiBjb3Vyc2Ugd2lsbGluZyBhbmQgYWJsZSBtZWFucyB0aGF0IHRoZSBBUyBiZWxpZXZlcyB0aGF0
IHRoZSBlbmRwb2ludCBpcyBsZWdpdGltYXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
Pjxicj4NClRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgdGhpcyB0b3BpYywgdGhlIG1vcmUgcGVzc2lt
aXN0aWMgSSBnZXQgdGhhdCB0aGVyZSBpcyBhIGdvb2Qgc29sdXRpb24gdG8gdGhpcyA6KTxicj4N
Cjxicj4NClZsYWRpbWlyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5QaGlsPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwOi8v
d3d3LmluZGVwZW5kZW50aWQuY29tLyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+d3d3Lmlu
ZGVwZW5kZW50aWQuY29tPC9zcGFuPjwvYT4gPGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVu
dGlkLmNvbS8iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtodHRwOi8vd3d3LmluZGVw
ZW5kZW50aWQuY29tLyZndDs8L3NwYW4+PC9hPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh
Y2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208
L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIEZlYiAy
NywgMjAxNiwgYXQgNjo0NiBBTSwgU2FtdWVsIEVyZHRtYW4gPGEgaHJlZj0ibWFpbHRvOnNhbXVl
bEBlcmR0bWFuLnNlIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7c2FtdWVsQGVyZHRt
YW4uc2UmZ3Q7PC9zcGFuPjwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi
YWNrZ3JvdW5kOndoaXRlIj4mIzQzOzEgZm9yIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNl
cnZlciBEaXNjb3ZlcnnigJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPi8vU2FtdWVsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj5PbiBUaHUsIEZlYiAyNSwgMjAxNiBhdCA4OjEwIFBNLCBNaWtlIEpvbmVzICZsdDs8YSBo
cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiA8YSBocmVm
PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj4mbHQ7bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8L3NwYW4+
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPlRoYW5rcyBmb3IgeW91ciB0aG91Z2h0cywgVmxhZGltaXIuJm5ic3A7IEnigJltIGlu
Y3JlYXNpbmdseSBpbmNsaW5lZCB0byBhY2NlcHQgeW91ciBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0
aGUgdGl0bGUgZnJvbSDigJxPQXV0aCAyLjAgRGlzY292ZXJ54oCdIHRvIOKAnE9BdXRoIDIuMCBB
dXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ0uJm5ic3A7IFdoaWxlIHRoZSBhYnN0cmFj
dCBhbHJlYWR5IG1ha2VzIGl0IGNsZWFyIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCBp
cyBBUyBkaXNjb3ZlcnksIGRvaW5nIHNvIGluIHRoZSB0aXRsZSBzZWVtcyBsaWtlIGl0IGNvdWxk
IGhlbHAgY2xhcmlmeSB0aGluZ3MsIGdpdmVuIHRoYXQgYSBsb3Qgb2YgdGhlIGRpc2N1c3Npb24g
c2VlbXMgdG8gYmUgYWJvdXQgcmVzb3VyY2UgZGlzY292ZXJ5LCB3aGljaCBpcyBvdXQgb2Ygc2Nv
cGUgb2YgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
SeKAmW0gbm90IHNheWluZyB0aGF0IHJlc291cmNlIGRpc2NvdmVyeSBpc27igJl0IGltcG9ydGFu
dCDigJMgaXQgaXMg4oCTIGJ1dCB1bmxpa2UgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlzY292ZXJ5
LCB3aGVyZSB0aGVyZeKAmXMgbG90cyBvZiBleGlzdGluZyBwcmFjdGljZSwgaW5jbHVkaW5nIHVz
aW5nIHRoZSBleGlzdGluZyBkYXRhIGZvcm1hdCBmb3IgZGVzY3JpYmluZyBPQXV0aCBpbXBsZW1l
bnRhdGlvbnMgdGhhdCBhcmVu4oCZdCBiZWluZyB1c2VkIHdpdGggT3BlbklEIENvbm5lY3QsIHRo
ZXJl4oCZcyBubyBleGlzdGluZyBwcmFjdGljZSB0byBzdGFuZGFyZGl6ZSBmb3IgcmVzb3VyY2Ug
ZGlzY292ZXJ5LiZuYnNwOyBUaGUgdGltZSB0byBjcmVhdGUgYSBzdGFuZGFyZCBmb3IgdGhhdCBz
ZWVtcyB0byBiZSBhZnRlciBleGlzdGluZyBwcmFjdGljZSBoYXMgZW1lcmdlZC4mbmJzcDsgSXQg
Km1pZ2h0KiBvciBtaWdodCBub3QgdXNlIG5ldyBtZXRhZGF0YSB2YWx1ZXMgaW4gdGhlIEFTIGRp
c2NvdmVyeSBkb2N1bWVudCwgYnV0IHRoYXTigJlzIHN0aWxsIHRvIGJlIGRldGVybWluZWQuJm5i
c3A7IFRoZSBvbmUgcmVhc29uIHRvIGxlYXZlIHRoZSB0aXRsZSBhcy1pcyBpcyB0aGF0IHJlc291
cmNlIGRpc2NvdmVyeSBtaWdodCBlbmQgdXAgaW52b2x2aW5nIGV4dGVuc2lvbnMgdG8gdGhpcyBt
ZXRhZGF0YSBmb3JtYXQgaW4gc29tZSBjYXNlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPkkgdGhpbmsgYW4gYW5hbG9neSB0byB0aGUgY29yZSBPQXV0aCBkb2N1bWVudHMg
UkZDIDY3NDkgYW5kIFJGQyA2NzUwIGFwcGxpZXMuJm5ic3A7IDY3NDkgaXMgYWJvdXQgdGhlIEFT
LiZuYnNwOyA2NzUwIGlzIGFib3V0IHRoZSBSUy4mbmJzcDsgVGhlIGRpc2NvdmVyeSBkb2N1bWVu
dCBpcyBhYm91dCB0aGUgQVMuJm5ic3A7IFdlIGRvbuKAmXQgeWV0IGhhdmUgYSBzcGVjaWZpY2F0
aW9uIG9yIGV4aXN0aW5nIHByYWN0aWNlIGZvciBSUyBkaXNjb3ZlcnksIHdoaWNoIHdvdWxkIGJl
IHRoZSA2NzUwIGFuYWxvZ3kuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k
OndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5J
biBzdW1tYXJ5LCB3aGljaCB0aXRsZSBkbyBwZW9wbGUgcHJlZmVyPzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+wrcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsg4oCcT0F1dGggMi4wIERpc2NvdmVyeeKAnTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+wrcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsg4oCcT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeeKAnTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAmbHQ7Jmd0OzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5Gcm9tOiBPQXV0aCBbPGEg
aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4gPGEgaHJlZj0i
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
PiZsdDttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDs8L3NwYW4+PC9hPl0gT24gQmVo
YWxmIE9mIFZsYWRpbWlyIER6aHV2aW5vdjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi
YWNrZ3JvdW5kOndoaXRlIj5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjUsIDIwMTYgMTI6NTkg
QU08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VG86IDxh
IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
b2F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkluIE9JREMgdGhlIGRpc2NvdmVyeSBk
b2MgaXMgb2YgZ3JlYXQgdXRpbGl0eSB0byBkZXZlbG9wZXJzIGFuZCBpbnRlZ3JhdG9ycy4gRGV2
ZWxvcGVycyBhbHNvIHRlbmQgdG8gZmluZCBpdCBhIG1vcmUgYWNjdXJhdGUgYW5kIGNvbXBsZXRl
IGRlc2NyaXB0aW9uIG9mIGhvdyB0byBzZXQgdXAgYSBjbGllbnQgZm9yIGEgcGFydGljdWxhciBk
ZXBsb3ltZW50LCBjb21wYXJlZCB0byB0cmFkaXRpb25hbCBvbmxpbmUgZG9jcywgd2hpY2ggbWF5
IGJlIG5vdCBiZSB1cCB0byBkYXRlLCBvciBldmVuIG1pc3NpbmcuIFZlcnkgbXVjaCBsaWtlIGF1
dG8tZ2VuZXJhdGVkIFN3YWdnZXIgYW5kIEphdmFEb2NzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SGVyZSBhcmUgc29tZSBleGFtcGxlIE9JREMgZGlzY292
ZXJ5IGRvY3M6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48
YSBocmVmPSJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20vLndlbGwta25vd24vb3BlbmlkLWNv
bmZpZ3VyYXRpb24iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vYWNjb3VudHMu
Z29vZ2xlLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbjwvc3Bhbj48L2E+IDxh
IGhyZWY9Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29u
ZmlndXJhdGlvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O2h0dHBzOi8vYWNjb3Vu
dHMuZ29vZ2xlLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiZndDs8L3NwYW4+
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cucGF5cGFsb2JqZWN0cy5jb20vLndlbGwta25vd24vb3BlbmlkLWNvbmZp
Z3VyYXRpb24iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LnBheXBhbG9i
amVjdHMuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uPC9zcGFuPjwvYT4gPGEg
aHJlZj0iaHR0cHM6Ly93d3cucGF5cGFsb2JqZWN0cy5jb20vLndlbGwta25vd24vb3BlbmlkLWNv
bmZpZ3VyYXRpb24iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtodHRwczovL3d3dy5w
YXlwYWxvYmplY3RzLmNvbS8ud2VsbC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbiZndDs8L3Nw
YW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEg
aHJlZj0iaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2ZhYnJpa2FtYjJjLm9ubWlj
cm9zb2Z0LmNvbS92Mi4wLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZmFi
cmlrYW1iMmMub25taWNyb3NvZnQuY29tL3YyLjAvLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3Vy
YXRpb248L3NwYW4+PC9hPiA8YSBocmVmPSJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5j
b20vZmFicmlrYW1iMmMub25taWNyb3NvZnQuY29tL3YyLjAvLndlbGwta25vd24vb3BlbmlkLWNv
bmZpZ3VyYXRpb24iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtodHRwczovL2xvZ2lu
Lm1pY3Jvc29mdG9ubGluZS5jb20vZmFicmlrYW1iMmMub25taWNyb3NvZnQuY29tL3YyLjAvLndl
bGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24mZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5XaXRoIHRoaXMgZGlzY292ZXJ5IGRvY3Vt
ZW50IGluIHBsYWNlIHNldHVwIG9mIGlkZW50aXR5IGZlZGVyYXRpb24gY2FuIHRoZW4gYmUgZWFz
aWx5IHNjcmlwdGVkLiBGb3IgZXhhbXBsZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHA6Ly9kb2NzLmF3cy5hbWF6b24uY29tL0lBTS9s
YXRlc3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVyc19jcmVhdGVfb2lkY192ZXJpZnktdGh1
bWJwcmludC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vZG9jcy5hd3Mu
YW1hem9uLmNvbS9JQU0vbGF0ZXN0L1VzZXJHdWlkZS9pZF9yb2xlc19wcm92aWRlcnNfY3JlYXRl
X29pZGNfdmVyaWZ5LXRodW1icHJpbnQuaHRtbDwvc3Bhbj48L2E+IDxhIGhyZWY9Imh0dHA6Ly9k
b2NzLmF3cy5hbWF6b24uY29tL0lBTS9sYXRlc3QvVXNlckd1aWRlL2lkX3JvbGVzX3Byb3ZpZGVy
c19jcmVhdGVfb2lkY192ZXJpZnktdGh1bWJwcmludC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj4mbHQ7aHR0cDovL2RvY3MuYXdzLmFtYXpvbi5jb20vSUFNL2xhdGVzdC9Vc2VyR3Vp
ZGUvaWRfcm9sZXNfcHJvdmlkZXJzX2NyZWF0ZV9vaWRjX3ZlcmlmeS10aHVtYnByaW50Lmh0bWwm
Z3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij5Ob3csIGRvZXMgdGhhdCBkaWN0YXRlIGFueSBwYXJ0aWN1bGFyIGFwcCBhcmNoaXRlY3R1cmU/
IE15IHJlYWRpbmcgb2YgdGhlIHNwZWMgaXMgdGhhdCBpdCBkb2Vzbid0LCBhbmQgaXQgc2hvdWxk
bid0IGVpdGhlci4gQnkgc3RheWluZyBuZXV0cmFsIG9uIHRoZSB0b3BpY3Mgb2YgUlMgZGlzY292
ZXJ5IGFuZCByZWdpc3RlcmluZyBSUHMgd2l0aCBSU3MuIEFuZCBob3cgb25lIGFycml2ZXMgYXQg
dGhlICZxdW90Oy53ZWxsLWtub3duLy4uLiZxdW90Oy4gSSdtIG5vdCBldmVuIHN1cmUgdGhhdCBy
ZXNvdXJjZSBkaXNjb3Zlcnkgc2hvdWxkIGJlIGEgdG9waWMgb2YgdGhpcyBXRy4gUGVyaGFwcyB0
byB0aGlzIGVuZCwgYW5kIHRvIHByZXZlbnQgY29uZnVzaW9uIHRoYXQgdGhlIHNwZWMgaXMgdHJ5
aW5nIHRvIGRvIHNvbWV0aGluZyBtb3JlLCBhIG1vcmUgc3BlY2lmaWMgdGl0bGUgd291bGQgc3Vp
dCBpdCBiZXR0ZXIuIEUuZy4gJnF1b3Q7QVMgRGlzY292ZXJ5JnF1b3Q7LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VmxhZGltaXI8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIDI1LzAyLzE2IDAyOjI1LCBQaGlsIEh1bnQgKElETSkg
d3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BbmQg
c28gZG9lcyBvcmFjbGUgYW5kIHNvIGRvZXMgZ29vZ2xlLiBFYWNoIGRpZmZlcmVudC4gPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TbyBob3cgY2FuIGFuIGFw
cCBkaWN0YXRlIGl0IHRoZW4gdW5sZXNzIHdlIGFsbCBnbyB0byBhIGNvbW1vbiBhcmNoaXRlY3R1
cmU/PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+UGhpbDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uIEZlYiAyNCwgMjAxNiwgYXQgMTY6
MDQsIE1pa2UgSm9uZXMgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv
bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbSZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv
ZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbSZndDs8L3NwYW4+PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BenVyZSBkZWZpbmVzIHdheXMgZm9yIHJlc291cmNlIHNl
cnZlcnMgdG8gYmUgcmVnaXN0ZXJlZCBmb3IgdXNlIHdpdGggYSBjbGllbnQgYW5kIGZvciBjbGll
bnRzIHRvIGR5bmFtaWNhbGx5IHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIGZvciB1c2UgYXQgYSBw
YXJ0aWN1bGFyIHJlc291cmNlIHNlcnZlci4mbmJzcDsgWW91IGNhbiBjYWxsIHRoYXQgY3VzdG9t
IGFyY2hpdGVjdHVyZSBpZiB5b3Ugd2FudC4mbmJzcDsgSXTigJlzIHdlbGwtZGVmaW5lZCBidXQg
aXTigJlzIG5vdCBjdXJyZW50bHkgaW4gdGhlIHN0YW5kYXJkcyByZWFsbS4mbmJzcDsgSSBrbm93
IHRoYXQgR29vZ2xlIGhhcyBzeW50YXggZm9yIGRvaW5nIHRoZSBzYW1lLCBhcyBJ4oCZbSBzdXJl
IGRvIGEgbG90IG9mIG90aGVyIGNsb3VkIE9BdXRoIGRlcGxveW1lbnRzLCBzdWNoIGFzIE9yYWNs
ZeKAmXMuJm5ic3A7IEZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIHdvcmtpbmcgZ3JvdXAgdGFs
a2VkIGFib3V0IHBvc3NpYmx5IHByb2R1Y2luZyBhIHN0YW5kYXJkIHZlcnNpb24gb2Ygc3ludGF4
IGZvciBtYWtpbmcgdGhlc2Uga2luZHMgb2YgcmVxdWVzdHMgZHVyaW5nIG91ciBkaXNjdXNzaW9u
cyBpbiBQcmFndWUgKGR1cmluZyB0aGUgVG9rZW4gRXhjaGFuZ2UgZGlzY3Vzc2lvbikgYnV0IG5v
Ym9keSBoYXMgcnVuIHdpdGggdGhpcyB5ZXQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+SW4gdGhpcyBzZW5zZSwgeWVzLCBBenVyZSBpcyBhbiBhcHBsaWNhdGlvbiBv
ZiB0aGUga2luZCB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQuJm5ic3A7IEF6dXJlIGFscmVhZHkgZG9l
cyBkZWZpbmUgc3BlY2lmaWMgbmV3IE9BdXRoIDIuMCBkaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVz
IHRoYXQgYXJlIHVzZWQgaW4gcHJvZHVjdGlvbi4mbmJzcDsgQSByZWdpc3RyeSBqdXN0IGRvZXNu
4oCZdCB5ZXQgZXhpc3QgaW4gd2hpY2ggaXQgY2FuIHJlZ2lzdGVyIHRob3NlIHRoYXQgYXJlIG9m
IGdlbmVyYWwgYXBwbGljYWJpbGl0eS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k
OndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtl
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+RnJvbTogUGhpbCBIdW50
IChJRE0pIFs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxl
PSJjb2xvcjpwdXJwbGUiPm1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+IDxh
IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1
cnBsZSI+Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8L3NwYW4+PC9hPl0gPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlNlbnQ6IFdlZG5l
c2RheSwgRmVicnVhcnkgMjQsIDIwMTYgMzo1MiBQTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UbzogTWlrZSBKb25lczxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5DYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7
PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlN1YmplY3Q6IFJl
OiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5NaWtlPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+VGFrZSBhIGxvb2sgYXQgdGhlIGFzc3VtcHRpb25zIHlvdSBhcmUgbWFr
aW5nLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPllvdSBz
ZWVtIHRvIGJlIGFzc3VtaW5nIGFwcGxpY2F0aW9uIHNvZnR3YXJlIGRpY3RhdGVzIG9hdXRoIGlu
ZnJhc3RydWN0dXJlIGFyY2hpdGVjdHVyZSBieSBzdWdnZXN0aW5nIHRoYXQgYXBwcyByZWdpc3Rl
ciBpbiBpYW5hLiZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPldvdWxkIG1zIGF6dXJlIGFsbG93IGN1c3RvbSBhcmNoPzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr
Z3JvdW5kOndoaXRlIj5PbiBGZWIgMjQsIDIwMTYsIGF0IDE1OjI4LCBNaWtlIEpvbmVzIDxhIGhy
ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT4g
PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7
PC9zcGFuPjwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+VGhlIFVzZXJJbmZvIEVuZHBvaW50IHBhdGggaXNu4oCZdCBmaXhlZCBhbmQgc28gaGFzIHRv
IGJlIGRpc2NvdmVyZWQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
SSBhZ3JlZSB0aGF0IGZvciBzb21lIE9BdXRoIHByb2ZpbGVzLCBvbmUgb3IgbW9yZSByZXNvdXJj
ZSBzZXJ2ZXJzIHdpbGwgaGF2ZSB0byBiZSBkaXNjb3ZlcmVkIHN0YXJ0aW5nIGZyb20gdGhlIGF1
dGhvcml6YXRpb24gc2VydmVyLiZuYnNwOyBXb3JraW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSBhbHNv
IGRlc2NyaWJlZCB3YW50aW5nIHRvIGRpc2NvdmVyIGF1dGhvcml6YXRpb24gc2VydmVycyBzdGFy
dGluZyBmcm9tIHJlc291cmNlIHNlcnZlcnMuJm5ic3A7IFRoZXJlIGlzbuKAmXQgYSBzdGFuZGFy
ZCBwcmFjdGljZSBmb3IgYW55IG9mIHRoaXMsIHdoaWNoIGlzIHdoeSBpdOKAmXMgaW50ZW50aW9u
YWxseSBsZWZ0IG91dCBvZiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9uY2UgdGhlIElBTkEgT0F1dGggRGlzY292ZXJ5
IE1ldGFkYXRhIFJlZ2lzdHJ5IGhhcyBiZWVuIGVzdGFibGlzaGVkLCB3aGljaCB3aWxsIGhhcHBl
biBhZnRlciB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFwcHJvdmVkLCBpdCB3
aWxsIGJlIGVhc3kgZm9yIHN1YnNlcXVlbnQgc3BlY2lmaWNhdGlvbnMgdG8gZG9jdW1lbnQgZXhp
c3RpbmcgcHJhY3RpY2UgZm9yIGRpZmZlcmVudCBPQXV0aCBwcm9maWxlcyBhbmQgcmVnaXN0ZXIg
ZGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyBzdXBwb3J0aW5nIHRoZW0uJm5ic3A7IFNvbWUgb2Yg
dGhvc2UgdmFsdWVzIHdpbGwgbGlrZWx5IGRlZmluZSB3YXlzIHRvIGRpc2NvdmVyIHJlc291cmNl
IHNlcnZlcnMsIHdoZW4gYXBwbGljYWJsZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj5CdXQgZmlyc3QsIHdlIG5lZWQgdG8gZmluaXNoIHRoZSBleGlzdGluZyBzcGVj
LCBzbyB0aGF0IHRoZSByZWdpc3RyeSBlbmFibGluZyB0aGVzZSBleHRlbnNpb25zIGdldHMgZXN0
YWJsaXNoZWQgaW4gdGhlIGZpcnN0IHBsYWNlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn
cm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0t
IE1pa2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5Gcm9tOiBQaGls
IEh1bnQgKElETSkgWzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwv
YT4gPGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj4mbHQ7bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozwvc3Bhbj48L2E+
XSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U2VudDog
V2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAyOjEzIFBNPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRvOiBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
PiZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0i
bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1
cnBsZSI+Jmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Q2M6IDxh
IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
Jmx0O29hdXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBp
ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpvYXV0aEBpZXRm
Lm9yZyZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L3NwYW4+PC9hPiA8
YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
PiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U3ViamVjdDogUmU6IFtPQVVUSC1XR10g
T0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn
cm91bmQ6d2hpdGUiPll1cC4gQW5kIGJlY2F1c2UgdGhlcmUgbWFueSByZWxhdGlvbnMgdGhlIGNs
aWVudCBtaXN0IGJlIGFibGUgdG8gZGlzY292ZXIgaXQuIFRoZSBjbGllbnQgZG9lcyBub3Qga25v
dyBpZiB0aGUgcmVzIHNlcnZlciBpcyBsZWdpdC4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj5UaGUgdXNlcmluZm8gaXMgYWx3YXlzIGZpeCBhbmQgc28gdSBk
b250IG5lZWQgZGlzY292ZXJ5LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPlBoaWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5P
biBGZWIgMjQsIDIwMTYsIGF0IDE0OjA1LCBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpNaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtN
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRv
Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
Jmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT4gd3Jv
dGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SW4gT3BlbklEIENv
bm5lY3QsIHRoZXJl4oCZcyBhIHJlc291cmNlIHNlcnZlciBjYWxsZWQgdGhlIFVzZXJJbmZvIEVu
ZHBvaW50IHRoYXQgcmV0dXJucyBjbGFpbXMgYWJvdXQgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlciBh
cyBhIEpTT04gZGF0YSBzdHJ1Y3R1cmUuJm5ic3A7IEl0cyBsb2NhdGlvbiBpcyBwdWJsaXNoZWQg
aW4gT3BlbklEIENvbm5lY3QgZGlzY292ZXJ5IG1ldGFkYXRhIGFzIHRoZSDigJx1c2VyaW5mb19l
bmRwb2ludOKAnSBtZXRhZGF0YSB2YWx1ZSwgd2hpY2ggaXMgZGVmaW5lZCBhdCA8YSBocmVmPSJo
dHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwj
UHJvdmlkZXJNZXRhZGF0YSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL29wZW5p
ZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1Byb3ZpZGVyTWV0
YWRhdGE8L3NwYW4+PC9hPiA8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt
Y29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjUHJvdmlkZXJNZXRhZGF0YSI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+Jmx0O2h0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0
LWRpc2NvdmVyeS0xXzAuaHRtbCNQcm92aWRlck1ldGFkYXRhJmd0Ozwvc3Bhbj48L2E+LjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPldlIGRpZG7igJl0IGluY2x1ZGUg
dGhlIFVzZXJJbmZvIEVuZHBvaW50IGluIHRoZSBnZW5lcmljIE9BdXRoIGRpc2NvdmVyeSBzcGVj
IHNpbmNlIGluIE9BdXRoLCB0aGVyZSBhcmUgbG90cyBvZiBwb3NzaWJsZSByZWxhdGlvbnNoaXBz
IGJldHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZCByZXNvdXJjZSBzZXJ2ZXJzIGFuZCB0
aGV5IG5lZWRu4oCZdCBiZSBvbmUtdG8tb25lLCBhcyBpcyBiZWluZyBhY3RpdmVseSBkaXNjdXNz
ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IEZvciBpbnN0YW5jZSwgc2VlIEdlb3JnZSBG
bGV0Y2hlcuKAmXMgcmVjZW50IGNvbnRyaWJ1dGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi
YWNrZ3JvdW5kOndoaXRlIj5UaGFua3MgZm9yIHRoZSBnb29kIGRpc2N1c3Npb24sIFBoaWwuPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6d2hpdGUiPkZyb206IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86cGhp
bC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86cGhpbC5odW50
QG9yYWNsZS5jb20mZ3Q7PC9zcGFuPjwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2IDE6
MjUgUE08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VG86
IE1pa2UgSm9uZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+Jmx0O29hdXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0
bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpv
YXV0aEBpZXRmLm9yZyZndDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlz
Y292ZXJ5IExvY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
V2hlcmUgaXMgdGhlIHByb2ZpbGUgZW5kcG9pbnQgKG9pZGMncyByZXNvdXJjZSBzZXJ2ZXIpIHB1
Ymxpc2hlZD8gKEZvciB0aGUgbm9uIE9JREMgcGVvcGxlIG9uIHRoZSBsaXN0KS4gPG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5QaGlsPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gRmViIDI0LCAyMDE2LCBhdCAxMzowOSwgTWlr
ZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3Bh
biBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0
Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tJmd0Ozwvc3Bhbj48L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6d2hpdGUiPlRvIHRoZSBleHRlbnQgdGhhdCBnZW5lcmljIE9BdXRoIDIuMCBuZWVk
cyB0byBwdWJsaXNoIHNvbWUgb2YgdGhlIHNhbWUgaW5mb3JtYXRpb24gYXMgT3BlbklEIENvbm5l
Y3Qg4oCTIHdoaWNoIGlzIGJ1aWx0IG9uIGdlbmVyaWMgT0F1dGggMi4wIOKAkyBpdCBtYWtlcyBz
ZW5zZSB0byBwdWJsaXNoIHRoYXQgaW5mb3JtYXRpb24gdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBz
eW50YXgsIHNpbmNlIHRoYXQgc3ludGF4IGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UuJm5i
c3A7IFRoYXQgd2hhdCB0aGlzIGRyYWZ0IGFjY29tcGxpc2hlcy48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGVyZeKAmXMgbm90aGluZyBDb25uZWN0LXNwZWNpZmlj
IGFib3V0IHVzaW5nIG1ldGFkYXRhIHJlc3BvbnNlIHZhbHVlcyBsaWtlOjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O2F1dGhv
cml6YXRpb25fZW5kcG9pbnQmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUu
Y29tL2F1dGhvcml6ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+JnF1b3Q7aHR0cHM6Ly9z
ZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplJnF1b3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0iaHR0
cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj4mbHQ7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vYXV0aG9yaXplJmd0Ozwvc3Bhbj48
L2E+LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz
cDsmbmJzcDsgJnF1b3Q7dG9rZW5fZW5kcG9pbnQmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8vc2Vy
dmVyLmV4YW1wbGUuY29tL3Rva2VuIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mcXVvdDto
dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS90b2tlbiZxdW90Ozwvc3Bhbj48L2E+IDxhIGhyZWY9
Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj4mbHQ7aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vdG9rZW4mZ3Q7PC9zcGFuPjwvYT4s
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZu
YnNwOyAmcXVvdDt0b2tlbl9lbmRwb2ludF9hdXRoX21ldGhvZHNfc3VwcG9ydGVkJnF1b3Q7OiBb
JnF1b3Q7Y2xpZW50X3NlY3JldF9iYXNpYyZxdW90OywgJnF1b3Q7cHJpdmF0ZV9rZXlfand0JnF1
b3Q7XSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5i
c3A7Jm5ic3A7ICZxdW90O3JlZ2lzdHJhdGlvbl9lbmRwb2ludCZxdW90OzogPGEgaHJlZj0iaHR0
cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPiZxdW90O2h0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3JlZ2lzdGVyJnF1b3Q7PC9zcGFu
PjwvYT4gPGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vcmVnaXN0ZXIiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS9yZWdp
c3RlciZndDs8L3NwYW4+PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7ICZxdW90O3Jlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCZx
dW90OzombmJzcDsgWyZxdW90O2NvZGUmcXVvdDssICZxdW90O3Rva2VuJnF1b3Q7XSw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7ICZx
dW90O3NlcnZpY2VfZG9jdW1lbnRhdGlvbiZxdW90OzogPGEgaHJlZj0iaHR0cDovL3NlcnZlci5l
eGFtcGxlLmNvbS9zZXJ2aWNlX2RvY3VtZW50YXRpb24uaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+JnF1b3Q7aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbS9zZXJ2aWNlX2RvY3VtZW50
YXRpb24uaHRtbCZxdW90Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIuZXhhbXBs
ZS5jb20vc2VydmljZV9kb2N1bWVudGF0aW9uLmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPiZsdDtodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tL3NlcnZpY2VfZG9jdW1lbnRhdGlvbi5o
dG1sJmd0Ozwvc3Bhbj48L2E+LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPklzIHRoZXJlIGEgcmVhc29uIHRoYXQgeW91IHdvdWxkIGxpa2UgdGhlIHN5bnRheCBmb3Ig
YW55IG9mIHRoZXNlIG9yIHRoZSBvdGhlciBnZW5lcmFsbHkgYXBwbGljYWJsZSBPQXV0aCAyLjAg
bWV0YWRhdGEgdmFsdWVzIHRvIGJlIGRpZmZlcmVudD8mbmJzcDsgSSBkb27igJl0IHNlZSBhbnkg
Z29vZCByZWFzb24gZm9yIHVubmVjZXNzYXJ5IGRpZmZlcmVuY2VzIHRvIGJlIGludHJvZHVjZWQu
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPkZyb206IFBoaWwgSHVudCAoSURNKSBbPGEgaHJlZj0ibWFpbHRv
OnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86
cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50
QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86cGhpbC5o
dW50QG9yYWNsZS5jb20mZ3Q7PC9zcGFuPjwvYT5dIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE2
IDEyOjQ1IFBNPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PlRvOiBBbnRob255IE5hZGFsaW4gPGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv
bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZn
dDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj48c3Bh
biBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSZn
dDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj5DYzogTWlrZSBKb25lcyA8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv
ZnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86TWljaGFl
bC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozwvc3Bhbj48L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1
dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtvYXV0aEBpZXRmLm9y
ZyZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwv
YT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOm9h
dXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOm9hdXRo
QGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6d2hpdGUiPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNjb3Zl
cnkgTG9jYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5NaWtl
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+UHVibGlzaGluZyBvbiBk
ZXYgcGFnZXMgZG9lcyBub3Qgd29yayBmb3Igc29mdHdhcmUgKGVzcCBvcGVuIHNvdXJjZSkgdGhh
dCBpcyBkZXBsb3llZCBib3RoIGluIGVudGVycHJpc2VzIGFuZCBvbiBQYWFTIGNsb3VkIHByb3Zp
ZGVycy4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGUg
Y3VycmVudCBkcmFmdCBpcyBtYXkgY29kaWZ5IGN1cnJlbnQgT0lEQyBwcmFjdGljZSBhbmQgYmUg
YXBwcm9wcmlhdGUgZm9yIG9pZGMgYnV0IGl0IGlzIG5vdCByZWFkeSBmb3IgZ2VuZXJpYyBvYXV0
aC4gVGhlcmUgaXMgbm8gZ2VuZXJpYyBvYXV0aCBleHBlcmllbmNlIGF0IHRoaXMgdGltZS4gPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5QaGlsPG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gRmViIDI0LCAyMDE2LCBhdCAxMDoy
NSwgQW50aG9ueSBOYWRhbGluIDxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20i
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDt0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7
PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7
PC9zcGFuPjwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+U3VyZSB0aGVyZSBpcywgaXQgaXMgYXMgeW91IGhhdmUgbm93IG1hZGUgaXQgZmFyIGVhc2ll
ciBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRvZXMgbm90IGV2ZW4gYWRkcmVzcyB0
aGlzPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+RnJvbTogTWlrZSBK
b25lcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U2Vu
dDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiAxMDoyMiBBTTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UbzogQW50aG9ueSBOYWRhbGluIDxhIGhy
ZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPiZsdDt0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFp
bHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0
O21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Q2M6IDxhIGhyZWY9Im1haWx0bzpv
YXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O29hdXRoQGlldGYu
b3JnJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8L3NwYW4+
PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86
b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86b2F1
dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+U3ViamVjdDogUkU6IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2Nv
dmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFz
IHdl4oCZZCBkaXNjdXNzZWQgaW4gcGVyc29uLCB0aGVyZeKAmXMgbm8gZWZmZWN0aXZlIHNlY3Vy
aXR5IGRpZmZlcmVuY2UgYmV0d2VlbiBkaXNjb3ZlcnkgaW5mb3JtYXRpb24gYmVpbmcgcHVibGlz
aGVkIGluIGFuIGFkLWhvYyBmYXNoaW9uIG9uIGRldmVsb3BlciBwYWdlcyBhbmQgaXQgYmVpbmcg
cHVibGlzaGVkIGluIGEgc3RhbmRhcmQgZm9ybWF0LiZuYnNwOyDigJxTZWN1cml0eSBieSBvYnNj
dXJpdHnigJ0gYWRkcyBubyByZWFsIHNlY3VyaXR5IGF0IGFsbC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtlPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+RnJvbTogQW50aG9ueSBOYWRhbGluIDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TZW50OiBXZWRuZXNkYXksIEZlYnJ1
YXJ5IDI0LCAyMDE2IDEwOjAxIEFNPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn
cm91bmQ6d2hpdGUiPlRvOiBNaWtlIEpvbmVzIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtNaWNoYWVsLkpv
bmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0
bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PC9zcGFuPjwvYT47IFBoaWwgSHVudCAo
SURNKSA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPiZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8L3NwYW4+PC9hPiA8YSBo
cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPiZsdDttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PC9zcGFuPjwvYT47IE5hdCBT
YWtpbXVyYSA8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj4mbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozwvc3Bhbj48L2E+IDxhIGhy
ZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
PiZsdDttYWlsdG86c2FraW11cmFAZ21haWwuY29tJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkNjOiA8YSBocmVmPSJtYWlsdG86
b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtvYXV0aEBpZXRm
Lm9yZyZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFu
PjwvYT4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRv
Om9hdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOm9h
dXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPlN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBEaXNj
b3ZlcnkgTG9jYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5U
aGUgcG9pbnQgb2YgdGhlIFdHTEMgaXMgdG8gZmluaXNoIHN0YW5kYXJkaXppbmcgdGhlIGNvcmUg
ZGlzY292ZXJ5IGZ1bmN0aW9uYWxpdHkgdGhhdOKAmXMgYWxyZWFkeSB3aWRlbHkgZGVwbG95ZWQu
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhhdCBtYXkgYmUgd2lk
ZWx5IGRlcGxveWVkIGZvciBPSURDIGJ1dCBub3Qgd2lkZWx5IGRlcGxveWVkIGZvciBPQXV0aC4g
VGhlcmUgYXJlIHNvbWUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGRpc2NvdmVyeSBmb3IgZW5k
cG9pbnQgdGhhdCByZWFsbHkgc2hvdWxkIG5vdCBiZSBpbiBhbiBPQXV0aCBzdGFuZGFyZCBzaW5j
ZSBpdOKAmXMgcmVhbGx5IG5vdCBkZWFsdCB3aXRoLiBOb3cgdGhhdCBhbGwgdGhpcyBpbmZvcm1h
dGlvbiBpcyBhdmFpbGFibGUgaXQgbWFrZXMgcG9raW5nIGFyb3VuZCB0aGUgZW5kcG9pbnQgbW9y
ZSBmb2N1c2VkIGZvciBwZW9wbGUgdGhhdCB3YW50IHRvIGRpc3J1cHQgeW91ciBlbmRwb2ludHMs
IHRoYXQgaXMgcmVhbGx5IG5vdCBhZGRyZXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp
b25zJm5ic3A7IHNlY3Rpb24gYXQgYWxsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh
Y2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmcmZ3Q7PC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlNlbnQ6IFdlZG5lc2RheSwgRmVicnVh
cnkgMjQsIDIwMTYgOTo1NCBBTTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj5UbzogUGhpbCBIdW50IChJRE0pIDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA
b3JhY2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3BoaWwuaHVudEBvcmFj
bGUuY29tJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbSZndDs8L3NwYW4+PC9hPjsgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtzYWtpbXVyYUBnbWFp
bC5jb20mZ3Q7PC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20m
Z3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+Q2M6IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+Jmx0O29hdXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1h
aWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0
bzpvYXV0aEBpZXRmLm9yZyZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0
Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8
L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPiZsdDttYWlsdG86b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U3ViamVjdDogUmU6
IFtPQVVUSC1XR10gT0F1dGggMi4wIERpc2NvdmVyeSBMb2NhdGlvbjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZSBwb2ludCBvZiB0aGUgV0dMQyBpcyB0byBmaW5p
c2ggc3RhbmRhcmRpemluZyB0aGUgY29yZSBkaXNjb3ZlcnkgZnVuY3Rpb25hbGl0eSB0aGF04oCZ
cyBhbHJlYWR5IHdpZGVseSBkZXBsb3llZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj5Ob25lIG9mIE5hdCBvciBKb2huIG9yIEkgYXJlIHN1Z2dlc3RpbmcgdGhhdCBh
ZGRpdGlvbmFsIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSB3b27igJl0IGJlIGNyZWF0ZWQuJm5ic3A7
IEnigJltIHN1cmUgaXQgd2lsbCBiZS4mbmJzcDsgU29tZSBhcHBsaWNhdGlvbnMgd2lsbCB1c2Ug
V2ViRmluZ2VyIHRvIGxvY2F0ZSB0aGUgZGlzY292ZXJ5IG1ldGFkYXRhLiZuYnNwOyBTb21lIHdp
bGwgcG9zc2libHkgdXNlIGxpbmsgaGVhZGVycy4mbmJzcDsgU29tZSB3aWxsIHBvc3NpYmx5IHVz
ZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyAud2VsbC1rbm93biB2YWx1ZXMuJm5ic3A7IEnigJltIHN1
cmUgdGhlcmXigJlzIG90aGVyIHRoaW5ncyBJIGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQu
Jm5ic3A7IEFsbCBvZiB0aGVzZSBkZXBlbmQgdXBvbiBoYXZpbmcgYSBkaXNjb3ZlcnkgbWV0YWRh
dGEgZG9jdW1lbnQgZm9ybWF0IGFuZCBub25lIG9mIHRoZW0gY2hhbmdlIGl0IOKAkyBvdGhlciB0
aGFuIHBvc3NpYmx5IHRvIHJlZ2lzdGVyIGFkZGl0aW9uYWwgZGlzY292ZXJ5IG1ldGFkYXRhIHZh
bHVlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TbyBieSBhbGwg
bWVhbnMsIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBjb250aW51ZSBkaXNjdXNzaW5nIGludmVu
dGluZyBwb3NzaWJsZSBuZXcgcmVsYXRlZCBtZWNoYW5pc21zIHRoYXQgbWFrZSBzZW5zZSBpbiBz
b21lIGNvbnRleHRzLiZuYnNwOyBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBjYW4gZmluaXNoIHN0YW5k
YXJkaXppbmcgdGhlIGFscmVhZHkgd2lkZWx5IGRlcGxveWVkIGNvcmUgZnVuY3Rpb25hbGl0eSB0
aGF0IGFsbCBvZiB0aGVzZSBtZWNoYW5pc21zIHdpbGwgbmVlZC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtlPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+RnJvbTogT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElE
TSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U2VudDog
V2VkbmVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNiA4OjM5IEFNPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRvOiBOYXQgU2FraW11cmEgPGEgaHJlZj0ibWFp
bHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3Nh
a2ltdXJhQGdtYWlsLmNvbSZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86c2FraW11cmFA
Z21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOnNha2ltdXJh
QGdtYWlsLmNvbSZndDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi
YWNrZ3JvdW5kOndoaXRlIj5DYzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48c3Bh
biBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT4g
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij4mbHQ7bWFpbHRvOm9hdXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0
bzpvYXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O29hdXRoQGll
dGYub3JnJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8L3Nw
YW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5T
dWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9uPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSBhbSBzdWdnZXN0aW5nIHRoYXQg
cGFydCBvZiB0aGUgZGlzY292ZXJ5IHNvbHV0aW9uIGhhcyB0byBiZSB0aGUgY2xpZW50IGluZGlj
YXRpbmcgd2hhdCByZXNvdXJjZSBlbmRwb2ludCBpdCB3YW50cyB0aGUgb2F1dGggY29uZmlndXJh
dGlvbiBkYXRhIGZvci4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj5TbyBpZiA8YSBocmVmPSJodHRwOi8vcmVzLmV4YW1wbGUuZXZpbC5jb20iPnJlcy5leGFt
cGxlLmV2aWwuY29tPC9hPiA8YSBocmVmPSJodHRwOi8vcmVzLmV4YW1wbGUuZXZpbC5jb20vIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7aHR0cDovL3Jlcy5leGFtcGxlLmV2aWwuY29t
LyZndDs8L3NwYW4+PC9hPiBpcyBub3QgYSB2YWxpZCByZXNvdXJjZSBlbmRwb2ludCBmb3IgPGEg
aHJlZj0iaHR0cDovL2FzLmV4YW1wbGUuY29tIj5hcy5leGFtcGxlLmNvbTwvYT4gPGEgaHJlZj0i
aHR0cDovL2FzLmV4YW1wbGUuY29tLyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O2h0
dHA6Ly9hcy5leGFtcGxlLmNvbS8mZ3Q7PC9zcGFuPjwvYT4gdGhlIGF1dGh6IGRpc2NvdmVyeSBz
aG91bGQgZmFpbCBpbiBzb21lIHdheSAoZWcgcmV0dXJuIG5vdGhpbmcpLiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZXJlIG1heSBiZSBiZXR0ZXIgd2F5
cyB0byBkbyB0aGlzLiBFZyBjb21iaW5lIGRpc2NvdmVyeS4gT3IgY2hhbmdlIHRoZSBvcmRlciBv
ZiBkaXNjb3ZlcnkuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+T25lIG9mIE9BdXRoJ3Mgc3RyZW5ndGgncyBhbmQgd2Vha25lc3NlcyBpcyB0aGF0IHRoZSB0
YXJnZXQgb2YgYXV0aG9yaXphdGlvbiAodGhlIHJlc291cmNlKSBpcyBuZXZlciBzcGVjaWZpZWQu
IEl0IGlzIG9mdGVuIGJvdW5kIHVwIGluIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBhbiBv
ZnRlbiBpbXBsaWVkIDE6MSByZWxhdGlvbnNoaXAgYmV0d2VlbiByZXNvdXJjZSBhbmQgYXMuIEdp
dmVuIHRoYXQgaW4gZGlzY292ZXJ5IHBoYXNlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IHlldCBvY2N1
cnJlZCBpdCBzZWVtcyBpbXBvcnRhbnQgdGhhdCB0aGUgY2xpZW50IGtub3cgaXQgaGFzIGEgdmFs
aWQgY29tYmluYXRpb24gb2YgZW5kcG9pbnRzIGV0Yy4gPG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGlzIGlzIHdoeSBJIHdhcyBkaXNhcHBvaW50ZWQgYWJv
dXQgd2dsYyBvbiBkaXNjb3ZlcnkuIFdlIGhhZCBhIHN0YXJ0aW5nIHBvaW50IGZvciBncm91cCBh
ZG9wdGlvbiBidXQgd2UgaGF2ZW4ndCByZWFsbHkgZGVmaW5lZCB0aGUgZnVsbCByZXF1aXJlbWVu
dHMgSU1PLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkkg
YW0gb24gdmFjYXRpb24gb3IgSSB3b3VsZCBwdXQgc29tZSB0aG91Z2h0IGludG8gc29tZSBkcmFm
dCBjaGFuZ2VzIG9yIGEgbmV3IGRyYWZ0LiBJIGFwb2xvZ2l6ZSBJIGNhbid0IGRvIGl0IG5vdy4g
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5QaGlsPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gRmViIDI0LCAyMDE2LCBhdCAw
ODoxMiwgTmF0IFNha2ltdXJhIDxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PC9zcGFu
PjwvYT4gPGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+Jmx0O21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7PC9zcGFuPjwvYT4g
d3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SGkgUGhpbCwg
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BcmUgeW91IHN1
Z2dlc3RpbmcgdGhhdCB0aGUgQVMgbWV0YWRhdGEgc2hvdWxkIGluY2x1ZGUgdGhlIFJTIFVSSXM/
IEN1cnJlbnRseSwgaXQgZG9lcyBub3QsIGJ1dCBpdCBjYW4gYmUgZG9uZSwgSSBndWVzcy4gPG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGUgd2F5IG9hdXRo
LW1ldGEgd29ya3MgaXMgdGhhdCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPjEuIFJTIHRlbGxzIHRoZSBjbGllbnQgd2hlcmUgdGhlIEFTIGlzLiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Mi4gQVMgdGVsbHMgdGhl
IGNsaWVudCB3aGljaCBSUyBlbmRwb2ludHMgdGhlIHRva2VuIGNhbiBiZSB1c2VkLiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkV2ZW4gaWYgdGhlcmUgaXMg
YSBiYWQgQVMgd2l0aCBhIHZhbGlkIGNlcnRzIHRoYXQgcHJveGllcyB0byB0aGUgZ29vZCBSUywg
dGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHRoZSB0b2tlbiB0aGVyZSBhcyB0aGUgYXV0aHogc2Vy
dmVyIHdpbGwgc2F5IHRoYXQgaXMgbm90IHRoZSBwbGFjZSB0aGUgY2xpZW50IG1heSB3YW50IHRv
IHNlbmQgdGhlIHRva2VuIHRvLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPk5hdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjIw
MTY8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5z
LXNlcmlmIj7lubQ8L3NwYW4+MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4g
R290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaciDwvc3Bhbj4yNDxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj4oPHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJp
ZiI+5rC0PC9zcGFuPikgMjM6NTkgUGhpbCBIdW50IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA
b3JhY2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3BoaWwuaHVudEBvcmFj
bGUuY29tJmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv
bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xl
LmNvbSZndDs8L3NwYW4+PC9hPjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+TmF0LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k
OndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PknigJltIG5vdCBzdXJlIHRoYXQgaGF2aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGVsbCB0aGUg
Y2xpZW50IHdoZXJlIGl0cyBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBzZWN1cmUgYnkgaXRzZWxm
LiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIGFuZCB0
aGUgUmVzb3VyY2Ugc2VydmVyIG5lZWQgdG8gYmUgYm91bmQgdG9nZXRoZXIgaW4gb25lIG9mIHRo
ZSBkaXNjb3ZlcnkgZW5kcG9pbnRzICh0aGUgcmVzb3VyY2UgYW5kL29yIHRoZSBvYXV0aCBzZXJ2
aWNlIGRpc2NvdmVyeSkuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
SWYgYSBjbGllbnQgZGlzY292ZXJzIGEgZmFrZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCBpcyBwcm94
eWluZyBmb3IgYSByZWFsIHJlc291cmNlIHNlcnZlciB0aGUgY3VycmVudCBkaXNjb3Zlcnkgc3Bl
YyB3aWxsIG5vdCBsZWFkIHRoZSBjbGllbnQgdG8gdW5kZXJzdGFuZCBpdCBoYXMgdGhlIHdyb25n
IHJlc291cmNlIHNlcnZlci4gUmF0aGVyIHRoZSBmYWtlIHJlc291cmNlIHNlcnZpY2Ugd2lsbCBq
dXN0IGhhdmUgYSBmYWtlIGRpc2NvdmVyeSBzZXJ2aWNlLiBUaGUgaGFja2VyIGNhbiBub3cgaW50
ZXJjZXB0IHJlc291cmNlIHBheWxvYWQgYXMgd2VsbCBhcyB0b2tlbnMgYmVjYXVzZSB0aGV5IHdl
cmUgYWJsZSB0byBjb252aW5jZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgbGVnaXQgYXV0aG9yaXph
dGlvbiBzZXJ2aWNlIGJ1dCB1c2UgdGhlIHRva2VuIGFnYWluc3QgdGhlIGhhY2tlcnMgcHJveHku
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhlIE9BdXRoIERpc2Nv
dmVyeSBzZXJ2aWNlIG5lZWRzIHRvIGNvbmZpcm0gdG8gdGhlIGNsaWVudCB0aGF0IHRoZSBzZXJ2
ZXIgaXMgYWJsZSB0byBpc3N1ZSB0b2tlbnMgZm9yIGEgc3RhdGVkIHJlc291cmNlIGVuZHBvaW50
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoaXMgbm90IG9ubHkg
d29ya3MgaW4gbm9ybWFsIE9BdXRoIGJ1dCBzaG91bGQgYWRkIHNlY3VyaXR5IGV2ZW4gdG8gVU1B
IHNpdHVhdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+UGhp
bDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkBpbmRlcGVuZGVudGlk
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9
Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9hPiA8YSBocmVmPSJodHRwOi8vd3d3Lmlu
ZGVwZW5kZW50aWQuY29tLyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O2h0dHA6Ly93
d3cuaW5kZXBlbmRlbnRpZC5jb20vJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh
Y2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208
L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gRmViIDI0LCAyMDE2
LCBhdCAzOjU0IEFNLCBOYXQgU2FraW11cmEgPGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWls
LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZn
dDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSZndDs8L3Nw
YW4+PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SGkg
VGhvbWFzLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPmlu
bGluZTogPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4yMDE2
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1z
ZXJpZiI+5bm0PC9zcGFuPjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdv
dGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjI8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYi
PuaciDwvc3Bhbj4pIDE4OjQ0IFRob21hcyBCcm95ZXIgPGEgaHJlZj0ibWFpbHRvOnQuYnJveWVy
QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3QuYnJveWVyQGdtYWls
LmNvbSZndDs8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86dC5icm95ZXJAZ21haWwuY29tIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSZn
dDs8L3NwYW4+PC9hPjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+Q291bGRuJ3QgdGhlIGRvY3VtZW50IG9ubHkgZGVzY3JpYmUgdGhlIG1ldGFkYXRhPzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIHF1aXRlIGxp
a2UgdGhlIGlkZWEgb2YgZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YSBpZiB5b3UgcmVhbGx5IHdh
bnQgdG8gZG8gZGlzY292ZXJ5LCBhbmQgbGVhdmUgaXQgb3BlbiB0byBpbXBsZW1lbnRlcnMgLyB0
byBvdGhlciBzcGVjcyB0byBkZWZpbmUgYSAud2VsbC1rbm93biBVUkwgZm9yICZxdW90O2F1dG8t
Y29uZmlndXJhdGlvbiZxdW90Oy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+VGhlIG1ldGFkYXRhIGRlc2NyaWJlZCBoZXJlIHdvdWxkIHRoZW4gZWl0aGVy
IGJlIHVzZWQgYXMtaXMsIGF0IGFueSBVUkwsIHJldHVybmVkIGFzIGRyYWZ0LXNha2ltdXJhLW9h
dXRoLW1ldGEgbWV0YWRhdGEgYXQgdGhlIFJTOyBvciBhcyBhIGJhc2lzIGZvciBvdGhlciBtZXRh
ZGF0YSBzcGVjcyAobGlrZSBPcGVuSUQgQ29ubmVjdCkuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5XaXRoIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEn
cyAmcXVvdDtkdXJpJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7c2NvcGUmcXVvdDsgYXR0cmlidXRlIG9m
IFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCB5b3UgaGF2ZSBldmVyeXRoaW5nIHlv
dSBuZWVkIHRvIHByb2NlZWQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k
OndoaXRlIj5ZdXAuIFRoYXQncyBvbmUgb2YgdGhlIHJlcXVpcmVtZW50cyB0byBiZSBSRVNUZnVs
LCBpcyBpdCBub3Q/Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+SW4gT0F1dGgncyBjYXNlLCB0aGUgcmVzb3VyY2UgYW5kIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlciBhcmUgdXN1YWxseSB0aWdodGx5IGNvdXBsZWQuIChPdGhlcndpc2UsIHlvdSBu
ZWVkIGFub3RoZXIgc3BlY3MgbGlrZSBVTUEuKSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+U28sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2hvdWxkIGJlIGFi
bGUgdG8gdGVsbCBlaXRoZXIgdGhlIGxvY2F0aW9uIG9mIHRoZSBhdXRoeiBlbmRwb2ludC4gSW4g
c29tZSB0cnVzdGVkIGVudmlyb25tZW50LCB0aGUgcmVzb3VyY2UgbWF5IGFzIHdlbGwgcmV0dXJu
IHRoZSBsb2NhdGlvbiBvZiB0aGUgYXV0aHogc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YS4gSW4g
dGhlc2UgY2FzZXMsIHlvdSBkbyBub3QgaGF2ZSB0byBkZWNpZGUgb24gd2hhdCAud2VsbC1rbm93
biB1cmkgYXMgeW91IHNheS4gVGhpcyBmcmVlcyB1cCBkZXZlbG9wZXJzIGZyb20gY29uZmlndXJh
dGlvbiBmaWxlIGxvY2F0aW9uIGNvbGxpc2lvbnMgZXRjLiBXZSBzaG91bGQgc3RyaXZlIG5vdCB0
byBwb2xsdXRlIHRoZSB1cmkgc3BhY2UgYXMgbXVjaCBhcyBwb3NzaWJsZS4gPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4od2VsbCwgZXhjZXB0IGlmIHRoZXJl
IGFyZSBzZXZlcmFsIEFTcyBlYWNoIHdpdGggZGlmZmVyZW50IHNjb3Blczsgc291bmRzIGxpa2Ug
YW4gZWRnZS1jYXNlIHRvIG1lIHRob3VnaDsgbWF5YmUgUkZDNjc1MCBzaG91bGQgaW5zdGVhZCBi
ZSB1cGRhdGVkIHdpdGggc3VjaCBhIHBhcmFtZXRlciBzdWNoIHRoYXQgYW4gUlMgY291bGQgcmV0
dXJuIHNldmVyYWwgV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyLCBlYWNoIHdpdGggaXRzIG93biAm
cXVvdDtzY29wZSZxdW90OyBhbmQgJnF1b3Q7ZHVyaSZxdW90OyB2YWx1ZT8pPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiA8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+WWVhaCwgSSBndWVzcyBpdCBpcyBhbiBlZGdl
IGNhc2UuIEkgd291bGQgcmF0aGVyIGxpa2UgdG8gc2VlIHRoZXNlIGF1dGh6IHNlcnZlcnMgdG8g
ZGV2ZWxvcCBhIHRydXN0IGZyYW1ld29yayB1bmRlciB3aGljaCB0aGV5IGNhbiBhZ3JlZSBvbiBh
IHNpbmdsZSBzZXQgb2YgY29tbW9uIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuIDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Q2hlZXJzLCA8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk5hdDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+T24gRnJpLCBGZWIgMTksIDIwMTYgYXQgMTA6NTkgUE0gSnVzdGlu
IFJpY2hlciA8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj4mbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozwvc3Bhbj48L2E+IDxhIGhyZWY9Im1h
aWx0bzpqcmljaGVyQG1pdC5lZHUiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWls
dG86anJpY2hlckBtaXQuZWR1Jmd0Ozwvc3Bhbj48L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5UaGUgbmV3bHktdHJpbW1lZCBPQXV0aCBE
aXNjb3ZlcnkgZG9jdW1lbnQgaXMgaGVscGZ1bCBhbmQgbW92aW5nIGluIHRoZSByaWdodCBkaXJl
Y3Rpb24uIEl0IGRvZXMsIGhvd2V2ZXIsIHN0aWxsIGhhdmUgdG9vIG1hbnkgdmVzdGlnZXMgb2Yg
aXRzIE9wZW5JRCBDb25uZWN0IG9yaWdpbnMuIE9uZSBpc3N1ZSBpbiBwYXJ0aWN1bGFyIHN0aWxs
IHJlYWxseSBib3RoZXJzIG1lOiB0aGUgdXNlIG9mIOKAnC8ud2VsbC1rbm93bi9vcGVuaWQtY29u
ZmlndXJhdGlvbuKAnSBpbiB0aGUgZGlzY292ZXJ5IHBvcnRpb24uIElzIHRoaXMgYW4gT0F1dGgg
ZGlzY292ZXJ5IGRvY3VtZW50LCBvciBhbiBPcGVuSUQgQ29ubmVjdCBvbmU/IFRoZXJlIGlzIGFi
c29sdXRlbHkgbm8gY29tcGVsbGluZyByZWFzb24gdG8gdGllIHRoZSBVUkwgdG8gdGhlIE9JREMg
ZGlzY292ZXJ5IG1lY2hhbmlzbS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj5JIHByb3Bvc2UgdGhhdCB3ZSB1c2Ug4oCcLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6
YXRpb24tc2VydmVy4oCdIGFzIHRoZSBkZWZhdWx0IGRpc2NvdmVyeSBsb2NhdGlvbiwgYW5kIHN0
YXRlIHRoYXQgdGhlIGRvY3VtZW50IE1BWSBhbHNvIGJlIHJlYWNoYWJsZSBmcm9tIOKAnC8ud2Vs
bC1rbm93bi9vcGVuaWQtY29uZmlndXJhdGlvbuKAnSBpZiB0aGUgc2VydmVyIGFsc28gcHJvdmlk
ZXMgT3BlbklEIENvbm5lY3Qgb24gdGhlIHNhbWUgZG9tYWluLiBPdGhlciBhcHBsaWNhdGlvbnMg
U0hPVUxEIHVzZSB0aGUgc2FtZSBwYXJhbWV0ZXIgbmFtZXMgdG8gZGVzY3JpYmUgT0F1dGggZW5k
cG9pbnRzIGFuZCBmdW5jdGlvbnMgaW5zaWRlIHRoZWlyIHNlcnZpY2Utc3BlY2lmaWMgZGlzY292
ZXJ5IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu
YnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3
aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T0F1dGggbWFpbGlu
ZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPiA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0
ZSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoJmd0Ozwvc3Bhbj48L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9z
cGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj4mbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3Nw
YW4+PC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCZndDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3Bh
biBzdHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+IDxhIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21h
aWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT4gPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+Jmx0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgmZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PQXV0aCBtYWlsaW5n
IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5P
QXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8
L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9zcGFuPjwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O2h0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgmZ3Q7PC9zcGFuPjwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+IDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPiA8YSBocmVm
PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtt
YWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+IDxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPjxzcGFuIHN0eWxl
PSJjb2xvcjpwdXJwbGUiPiZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn
cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPlZsYWRpbWlyIER6aHV2aW5vdiA6OiA8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVj
dDJpZC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnZsYWRpbWlyQGNvbm5lY3QyaWQu
Y29tPC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQu
Y29tJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9BdXRoIG1h
aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT4gPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu
b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7bWFpbHRvOk9BdXRoQGlldGYub3Jn
Jmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCZndDs8L3NwYW4+PC9h
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQo8YnI+
DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dy
b3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T0F1dGgg
bWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp
dGUiPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1
cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T0F1dGggbWFp
bGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBo
cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+
DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BY2PR03MB442F67CB6EC7B1746B35CA7F5B80BY2PR03MB442namprd_--


From nobody Sat Feb 27 11:31:47 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEEC1A8969 for ; Sat, 27 Feb 2016 11:31:45 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BCEbZ3YvfLQ for ; Sat, 27 Feb 2016 11:31:43 -0800 (PST)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A4A1A882B for ; Sat, 27 Feb 2016 11:31:43 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa12-04.prod.phx3.secureserver.net with  id PXXh1s00C15ZTut01XXiTV; Sat, 27 Feb 2016 12:31:43 -0700
To: Hannes Tschofenig , oauth@ietf.org
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net>
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1010
Organization: Connect2id Ltd.
Message-ID: <56D1F99C.9070901@connect2id.com>
Date: Sat, 27 Feb 2016 21:31:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CEB0A6.4050500@gmx.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010308000802000205040408"
Archived-At: 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 19:31:46 -0000

This is a cryptographically signed message in MIME format.

--------------ms010308000802000205040408
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Hannes,

I'm glad to hear that you're interest to work on this. The approach in
the Trier report was really enlightening to me. I'm still digesting it.

OAuth 2 was created with the promise to be developer friendly and
extensible, but compared with some other security protocols, doesn't
extend security guarantees to profiles / usages of it. Consider for
example TLS, which allows other protocols to ride on top of it, without
having to worry about breaking TLS security the way we now do now when
thinking of more dynamic use cases of OAuth :)

I wish we would come up with some simple recipe that will be easy to
explain to developers, and at the same time will guarantee the security
in all dynamic use cases. E.g. if you do dynamic discovery then make
sure A,B,C...

Cheers,
Vladimir

On 25/02/16 09:43, Hannes Tschofenig wrote:
> Vladimir,
>
> yes, we could do a formal analysis and it would be a very good idea.
> It would even go faster if a few of us work together on it. Anyone
> interested?
>
> This would be a good contribution for the workshop in July, btw.
>
> Ciao
> Hannes
>
> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>> Hi Mike,
>>
>> You mention that you spent considerable time in research. I wonder if
>> there is existing theory, in communications or information theory, tha=
t
>> can be used to formally establish and prove (or disprove) the security=

>> of the proposed OAuth measures? Perhaps some work that is totally
>> unrelated to identity and the web protocols, but could well apply here=
?
>>
>> My reasoning is that we have a closed system that is fairly simple, so=

>> formal analysis must be entirely possible.
>>
>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>
>> 2. The OAuth protocol follows a simple and well-defined pattern of
>> messages between the parties.
>>
>> 3. The points and the number of ways by which an adversary may break
>> into OAuth must therefore be finite.
>>
>> 4. The security requirement is essentially to guarantee the precedence=

>> and authenticity of the messages from discovery endpoint to RS, and th=
e
>> preferred way to do that is by establishing a binding between the
>> messages, which can be forward or backward binding.
>>
>>
>> Right now the WG concern is whether all possible attacks have been
>> recognised, and then taken care of. If we can have a formal model that=

>> can reliably reveal and prove that, this will be a huge breakthrough.
>>
>> Cheers,
>>
>> Vladimir
>>
>>
>>
>> On 20/02/16 12:41, Mike Jones wrote:
>>> Suggesting that they be read is of course, the right long-term approa=
ch.  But as someone who spent 20+ years as a researcher before switching =
to digital identity, I was sensitive to not wanting to upstage their work=
 by copying too much of their material into our draft before their public=
ations were widely known.  I'll of course commit to working the researche=
rs and the working group to create a self-contained concise description o=
f the threats and mitigations in the working group document.
>>>
>>> 				Cheers,
>>> 				-- Mike
>>>
>>> -----Original Message-----
>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20
>>> Sent: Saturday, February 20, 2016 2:25 AM
>>> To: Mike Jones ; William Denniss ; Phil Hunt (IDM) 
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call =
for Adoption
>>>
>>> Hi Mike,
>>>
>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>> Have you read both of their publications?  If not, do yourself a fav=
or=20
>>>> and do.  They're actually both very readable and quite informative.
>>> I have read both documents. In context of this discussion the questio=
n is whether we
>>>
>>> (a) require them to be read (in which case they should be a normative=
 reference), or
>>> (b) suggest them to be read (since they provide additional background=
 information). In this case they are an informative reference.
>>>
>>> I believe believe we want (b) for the OAuth WG document. While I enco=
urage everyone to read the publications I also believe that there is lots=
 of material in there that goes beyond the information our audience typic=
ally reads (such as the text about the formal analysis).
>>>
>>> There is probably also a middle-ground where we either copy relevant =
text from the papers into the draft or reference specific sections that a=
re "must-read".
>>>
>>> One other issue: I actually thought that the threat that is outlined =
in the research paper is sufficiently well described but the second threa=
t, which is called 'cut-and-paste attack', requires more work.
>>> I noted this in my summary mail to the list, see http://www.ietf.org/=
mail-archive/web/oauth/current/msg15697.html
>>>
>>> Ciao
>>> Hannes
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>



--------------ms010308000802000205040408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAyMjcxOTMxNDBaMC8GCSqGSIb3DQEJBDEiBCBhPACOCs87kwEOWlQCfIe1cFoS1LfD
u7pTsAPCywCNMDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBE8MycYDPa
/HbYQZ499p/YG42cRthWVQWyB0ft/N4Xj48RxdnEetXiI2z/2vVz5RE5Ajr7B+FNBb3lk35P
7TXBQxOpTdTG8tXEHp+NUog5dICg+fSiWGUb6tDjaY1Qrcl56PmakSc3SOD4r97WEuJqMXsG
DoEUI5QnOMVvMJgjPuMnkd4hRT4JxtgKjQzBtYsd2qgCo8WckQXM0nxTv13+IGh8uemwO1BU
ExAhzpo7ZUE+nTGfJPCXc+tAZ/T6or6sGFhORqc3bjQhyL+RvfoErq3J2tVx4PO+SbfuYPcU
l/oxf/9/oskGu05KFf9SIrGAakgWn7XNU1fW1QLwAUQDAAAAAAAA
--------------ms010308000802000205040408--


From nobody Sat Feb 27 15:15:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA801B2D40 for ; Sat, 27 Feb 2016 15:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH9XarXfIEgb for ; Sat, 27 Feb 2016 15:15:41 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6691B2D3F for ; Sat, 27 Feb 2016 15:15:41 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id g127so95772656ywf.2 for ; Sat, 27 Feb 2016 15:15:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=jA6mcqjy6kykvYTRUDiCVxgRBSs36xBGEDWSP/dUB/I=; b=womQqmQTFzin9QMtxJUqv6hvBgfl10n7lydo9wmK06oPnztWSb57CM/EfRcHapLOKV oldR36rwsD4BomLQrstSiTDpu9m1iyJft85CSt+J8zTtDgil6s9r50HDwyut03esYZ1p gpKOT4UyCH38Jz6jJLRQu8wfC16jeoAzYntuA/X+TXcKd6cyQGFRYAUE85Rfeps2DPxb mrlbcaw8XYUy9d1Bkqv+r/nScYltDH+T1R0oVJ8Lg1G1E4hg3Bk/h8n0dONntZFHNuZA EiCNOzJpGBmN+ENdf5Rpb5k2GuYmPP/TnGxv8PrkQ1hLpnz65TWYDEqUwvQrqGIPiA3R /9UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jA6mcqjy6kykvYTRUDiCVxgRBSs36xBGEDWSP/dUB/I=; b=ZFI2gimm16EKzjK9vfVW8REjgWGJpy2pfgd55x1xDnRWrnCRwZuXoTH8TqzjKE6RVV q+6Un0m1EbkvPNutW1FNFgn4sZLh8/1NeO63JhnWei92MjmDEztXSK386fdAuyYaSeLl UV/z/IFxiLo4+o0/Kab/ZBUocnafg1f3HJy87k+iEET1ZAF7Az61y0B/ient8397sUcp +az4F2+9cGU9JXqcrOYpU6gILy9mYlmPcuYvB+j92aZf1S0DTnOBctiP0ZUTZiyIRMZO INch1YZfXVhakBFY0j+/+4nDMbB2+qx3ljttE50MumBZT8nZtffU4wodjjVuyKLyvX5w 1QvQ==
X-Gm-Message-State: AD7BkJL2qGV4tejZ5GucKCqiZ+QwGmMSw6oyk4m1yvx40/0NNjkTtZJpjFCvSdh6d85igQ==
X-Received: by 10.13.240.194 with SMTP id z185mr4640541ywe.317.1456614940938;  Sat, 27 Feb 2016 15:15:40 -0800 (PST)
Received: from [12.35.22.83] ([12.35.22.83]) by smtp.gmail.com with ESMTPSA id j198sm15244298ywg.16.2016.02.27.15.15.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 27 Feb 2016 15:15:40 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2873372F-B68C-4312-8A19-F9E9148CD71D"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56D1E7E7.7070200@connect2id.com>
Date: Sat, 27 Feb 2016 18:15:41 -0500
Message-Id: 
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net>  <56D1E7E7.7070200@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2016 23:15:44 -0000

--Apple-Mail=_2873372F-B68C-4312-8A19-F9E9148CD71D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If the malicious client is registering it=E2=80=99s own redirect URI =
then option A won=E2=80=99t help.=20

On the other hand the Good AS should identify the malicious client to =
the user.

I think this is a separate problem of client impersonation being used =
for Phishing.

This is really a case of bad guy registers client and phishes the user =
to login pretending to be some other client.

That can all be done with the good client not being involved at all.=20

John B.

> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov =
 wrote:
>=20
> Hi Brian,
>=20
> On 27/02/16 00:27, Brian Campbell wrote:
>> My preference is for Option A.
>>=20
>> The mix-up attack, in all it's variations, relies on there being no =
means
>> in OAuth for the AS to identify itself to the client when it returns =
the
>> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up =
Mitigation'
>> addresses that fundamental missing piece by including the 'iss'
>> authorization response parameter.
>=20
> This fundamental piece is indeed missing. I'm not sure measure "A" can
> also cover dynamic discovery and registration though. The mixup attack
> was originally described there, with OpenID Connect.
>=20
> How about this variation:
>=20
> Suppose the malicious IdP:
>=20
> 1. Registers the client under attack for
> a) malicious authz endpoint
> b) malicious token endpoint (optional)
>=20
> ... while also acting as proxy, where there are two variants:
> a) repeats the client registration with the honest IdP to obtain
> client_id + credentials that it keeps for itself; or
> b) is already registered as a client with the honest IdP
>=20
> Then:
>=20
> 1. When the authz request is made to the malicious authz endpoint, the
> request is rewritten with the client_id and redirect_uri which the
> malicious IdP has with the honest IdP. The state may or may not be =
replaced.
>=20
> 2. The browser is then given a second redirect with the rewritten
> parameters to the authz endpoint of the honest IdP.
>=20
> 3. The user doesn't notice this double redirect, and logs in / gives
> consent.
>=20
> 4. The honest IdP sends the browser back to the registered malicious
> redirect_uri. The attacker receives the code or tokens (depending on =
the
> response type)
>=20
> 5. A second redirect is made back to the redirect_uri of the client,
> with rewritten state, iss, client_id
>=20
>=20
> What is your take on this?
>=20
> The ideal fix for me would be one that covers dynamic discovery and
> registration as well. I'm not convinced option A does that.
>=20
> Cheers,
>=20
> Vladimir
>=20
>> During the course of the discussions in Darmstadt Hans and I =
independently
>> implemented and successfully interop tested the 'iss' and 'client_id'
>> authorization response parameters, which is what was anticipated to =
be in
>> the mitigation draft. Doing so was very simple and straightforward. =
And it
>> addresses the vulnerability. We decided, unfortunately, to pull that
>> functionality out of a looming a product release due to the churn in =
this
>> WG and the perceived risk of changes in what would eventually become =
the
>> standard solution. Of course, that kind of risk is always present =
with
>> draft standards but it's been very frustrating in this case to have =
worked
>> towards a simple solution to a known problem only to have progress =
get hung
>> up in lack of agreement in this WG.
>>=20
>> I'll also say that in many/most cases the AS doesn't explicitly know =
all of
>> the resources that tokens it issues can or will be used at (and there =
are
>> often more than one). So the ruri/Resource URI parameter isn't really =
a
>> workable option.
>>=20
>>=20
>>=20
>> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
>> hannes.tschofenig@gmx.net> wrote:
>>=20
>>> Vladimir,
>>>=20
>>> yes, we could do a formal analysis and it would be a very good idea.
>>> It would even go faster if a few of us work together on it. Anyone
>>> interested?
>>>=20
>>> This would be a good contribution for the workshop in July, btw.
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>>>> Hi Mike,
>>>>=20
>>>> You mention that you spent considerable time in research. I wonder =
if
>>>> there is existing theory, in communications or information theory, =
that
>>>> can be used to formally establish and prove (or disprove) the =
security
>>>> of the proposed OAuth measures? Perhaps some work that is totally
>>>> unrelated to identity and the web protocols, but could well apply =
here?
>>>>=20
>>>> My reasoning is that we have a closed system that is fairly simple, =
so
>>>> formal analysis must be entirely possible.
>>>>=20
>>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>>=20
>>>> 2. The OAuth protocol follows a simple and well-defined pattern of
>>>> messages between the parties.
>>>>=20
>>>> 3. The points and the number of ways by which an adversary may =
break
>>>> into OAuth must therefore be finite.
>>>>=20
>>>> 4. The security requirement is essentially to guarantee the =
precedence
>>>> and authenticity of the messages from discovery endpoint to RS, and =
the
>>>> preferred way to do that is by establishing a binding between the
>>>> messages, which can be forward or backward binding.
>>>>=20
>>>>=20
>>>> Right now the WG concern is whether all possible attacks have been
>>>> recognised, and then taken care of. If we can have a formal model =
that
>>>> can reliably reveal and prove that, this will be a huge =
breakthrough.
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Vladimir
>>>>=20
>>>>=20
>>>>=20
>>>> On 20/02/16 12:41, Mike Jones wrote:
>>>>> Suggesting that they be read is of course, the right long-term
>>> approach.  But as someone who spent 20+ years as a researcher before
>>> switching to digital identity, I was sensitive to not wanting to =
upstage
>>> their work by copying too much of their material into our draft =
before
>>> their publications were widely known.  I'll of course commit to =
working the
>>> researchers and the working group to create a self-contained concise
>>> description of the threats and mitigations in the working group =
document.
>>>>>                             Cheers,
>>>>>                             -- Mike
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>> To: Mike Jones ; William Denniss <
>>> wdenniss@google.com>; Phil Hunt (IDM) 
>>>>> Cc: oauth@ietf.org
>>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: =
Call
>>> for Adoption
>>>>> Hi Mike,
>>>>>=20
>>>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>>>> Have you read both of their publications?  If not, do yourself a =
favor
>>>>>> and do.  They're actually both very readable and quite =
informative.
>>>>> I have read both documents. In context of this discussion the =
question
>>> is whether we
>>>>> (a) require them to be read (in which case they should be a =
normative
>>> reference), or
>>>>> (b) suggest them to be read (since they provide additional =
background
>>> information). In this case they are an informative reference.
>>>>> I believe believe we want (b) for the OAuth WG document. While I
>>> encourage everyone to read the publications I also believe that =
there is
>>> lots of material in there that goes beyond the information our =
audience
>>> typically reads (such as the text about the formal analysis).
>>>>> There is probably also a middle-ground where we either copy =
relevant
>>> text from the papers into the draft or reference specific sections =
that are
>>> "must-read".
>>>>> One other issue: I actually thought that the threat that is =
outlined in
>>> the research paper is sufficiently well described but the second =
threat,
>>> which is called 'cut-and-paste attack', requires more work.
>>>>> I noted this in my summary mail to the list, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>>>>> Ciao
>>>>> Hannes
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_2873372F-B68C-4312-8A19-F9E9148CD71D
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAyMjcyMzE1NDJaMCMGCSqGSIb3DQEJBDEWBBTDcKlYm6eBleVTwM3RoMJi
wPknHzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCnYujavlw5eYlKwIeccXtMf0S2LUKXgXwapKzQvBB2YnlWgfwFOaGV
wK3bl1UQ8VplJmDZSmBx+/xe14QIbgB9uMXF7J+Rs6kWcfOHIft2wT1KFl3W9laaiseZVLp1yOEJ
U5fP0u9EZCiNXg3lh+p+FasoCa9H1weIYuLv6MxIpsv4N1L4FljvRB08evkvhCvM1K5R6jvs5xgi
9SIylzkZNX3tZHyBmdZVyOQHcPd55Z+Vtw00B0HB2Ipq1HN76MhK/1bSIUVMSEJmsSzya6m8wYot
lMCS3jWneIdvB7evtwcHw//Kg8RQeVgsdk12TklS72A+6M6NLk5ueiDq6utVAAAAAAAA
--Apple-Mail=_2873372F-B68C-4312-8A19-F9E9148CD71D--


From nobody Sun Feb 28 07:35:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6316C1A1A3B for ; Sun, 28 Feb 2016 07:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbXIG-o0CN9F for ; Sun, 28 Feb 2016 07:35:45 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC301A1A32 for ; Sun, 28 Feb 2016 07:35:44 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.106]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aa3Nn-0004Md-VB; Sun, 28 Feb 2016 16:35:44 +0100
To: Hannes Tschofenig , "oauth@ietf.org" 
References: <56C7702B.2000401@gmx.net>
From: Torsten Lodderstedt 
Message-ID: <56D313CF.4090107@lodderstedt.net>
Date: Sun, 28 Feb 2016 16:35:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C7702B.2000401@gmx.net>
Content-Type: multipart/alternative; boundary="------------090307010102010004050106"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 15:35:48 -0000

This is a multi-part message in MIME format.
--------------090307010102010004050106
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point 
simply because it gives some description of the threats we need to cope 
with. This does not preclude to eventually use 
draft-sakimura-oauth-meta-07 as solution or any other suitable 
mechanisms we find consensus on.

In my opinion, both proposals (iss and meta data) are very similar on a 
conceptual level as they inform the client about the sender of the 
redirect. iss could nicely fit with the upcoming OAuth AS discovery, 
whereas meta is appealing if we want a mechanism, which always keeps the 
client informed where it is considered secure to obtain/use credentials 
(tokens, codes, ...).

Beside this, I would like to emphasize again that code injection/copy 
and paste is not related to idp mix up (even if we discussed both in the 
same workshop). Even traditional OAuth deployments (single AS) are 
potentially affected by the attack. I suggest to split the draft into 
separat documents per threat/mitigation and move forward mitigation 
against code injection as quickly as possible. The current proposal to 
tie the authz code to the client state seems a pretty simple and 
straightforward solution to me.

kind regards,
Torsten.

Am 19.02.2016 um 20:42 schrieb Hannes Tschofenig:
> Early February I posted a mail to the list to make progress on the
> solution to the OAuth Authorization Server Mix-Up problem discovered
> late last year.
>
> Here is my mail about the Authorization Server Mix-Up:
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
>
> Here is my mail to the list that tries to summarize the discussion
> status and asked a few questions:
> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>
> Unfortunately, my mail didn't lead to the intended success. While there
> was some feedback I wasn't getting the desired response.
>
> In order to move forward I believe we need a working group document that
> serves as a starting point for further work in the group*. We have two
> documents that provide similar functionality in an attempt to solve the
> Authorization Server Mix-Up problem.
>
> So, here is the question for the group. Which document do you want as a
> starting point for work on this topic:
>
> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley
>
> Link:
> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>
> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
> Sascha Preibisch
>
> Link:
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
>
> Deadline for feedback is March, 4th.
>
> Ciao
> Hannes & Derek
>
> PS: (*) Regardless of the selected solution we will provide proper
> acknowledgement for those who contributed to the work.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------090307010102010004050106
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi all,

    

    I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting
    point simply because it gives some description of the threats we
    need to cope with. This does not preclude to eventually use
    draft-sakimura-oauth-meta-07 as solution or any other suitable
    mechanisms we find consensus on. 

    

    In my opinion, both proposals (iss and meta data) are very similar
    on a conceptual level as they inform the client about the sender of
    the redirect. iss could nicely fit with the upcoming OAuth AS
    discovery, whereas meta is appealing if we want a mechanism, which
    always keeps the client informed where it is considered secure to
    obtain/use credentials (tokens, codes, ...).  

    

    Beside this, I would like to emphasize again that code
    injection/copy and paste is not related to idp mix up (even if we
    discussed both in the same workshop). Even traditional OAuth
    deployments (single AS) are potentially affected by the attack. I
    suggest to split the draft into separat documents per
    threat/mitigation and move forward mitigation against code injection
    as quickly as possible. The current proposal to tie the authz code
    to the client state seems a pretty simple and straightforward
    solution to me. 

    

    kind regards,

    Torsten.

    

    
Am 19.02.2016 um 20:42 schrieb Hannes
      Tschofenig:

    

    

      
Early February I posted a mail to the list to make progress on the
solution to the OAuth Authorization Server Mix-Up problem discovered
late last year.

Here is my mail about the Authorization Server Mix-Up:
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html

Here is my mail to the list that tries to summarize the discussion
status and asked a few questions:
http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html

Unfortunately, my mail didn't lead to the intended success. While there
was some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that
serves as a starting point for further work in the group*. We have two
documents that provide similar functionality in an attempt to solve the
Authorization Server Mix-Up problem.

So, here is the question for the group. Which document do you want as a
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley

Link:
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
Sascha Preibisch

Link:
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07

Deadline for feedback is March, 4th.

Ciao
Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper
acknowledgement for those who contributed to the work.



      

      

      

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


    

    

  


--------------090307010102010004050106--


From nobody Sun Feb 28 07:44:54 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060AD1A1A99 for ; Sun, 28 Feb 2016 07:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGxg5f3tiKaT for ; Sun, 28 Feb 2016 07:44:50 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220B11A1ABC for ; Sun, 28 Feb 2016 07:44:47 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.106]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aa3WW-0000Bn-LK; Sun, 28 Feb 2016 16:44:44 +0100
To: Thomas.Kupka@bmw.de, oauth@ietf.org
References: <788977955ECA61468DD6F0FF5CAC14DB1DB40F@SMUCM70B.europe.bmw.corp>
From: Torsten Lodderstedt 
Message-ID: <56D315ED.6050209@lodderstedt.net>
Date: Sun, 28 Feb 2016 16:44:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <788977955ECA61468DD6F0FF5CAC14DB1DB40F@SMUCM70B.europe.bmw.corp>
Content-Type: multipart/alternative; boundary="------------010101040006020601060008"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 15:44:53 -0000

This is a multi-part message in MIME format.
--------------010101040006020601060008
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Thomas,

see comments inline.

Am 19.02.2016 um 12:14 schrieb Thomas.Kupka@bmw.de:
>
> Hi,
>
> we use the OAuth 2.0 Implicit grant to issue access_tokens to client 
> applications such as HTML 5 web apps that have no secure means to 
> securely authenticating themselves. Even if the credentials would be 
> obfuscated, any user could extract them from the HTTP requests their 
> User Agent makes with minimal effort. Since RFC 7009 also talks about 
> the usage of CORS to support User-Agent clients, however, I believe 
> that these clients should be supported.
>
> So I am having trouble supporting the revocation requirement in RFC 
> 7009 which states:
>
>    The client also includes its authentication credentials as described
> inSection 2.3. of [RFC6749] 
> .
>
> Looking at said section in in RFC 6749, it states:
>
>    If the client type is confidential, the client and authorization
>    server establish a client authentication method suitable for the
>    security requirements of the authorization server.  The authorization
>    server MAY accept any form of client authentication meeting its
> security requirements.
>
> I am unsure whether “having no form of client authentication” conforms 
> to the standard, can you comment on this?
>

Yes, it does. The client shall use the authentication means it would use 
on the AS's token endpoint as well. And in the same way as public 
clients only identify themself in this use case, they are supposed to do 
the same at the revocation endpoint.

> As a side note, I wonder why client authentication for token 
> revocations is required anyway, because if a client received a token 
> by any legit means, it should always be able to revoke it, regardless 
> of authentication. And if an unauthorized client ‘stole’ any type of 
> token, revoking it should also be possible, since loss of service for 
> the intended client should always be preferred over misusing the token.
>

Good catch :-) We discussed this when we went through WG review. The 
position we finally decided to take is: what is the worst thing an 
attacker could do on the revocation endpoint? It would revoke tokens in 
order to interupt the respective service for the resource owner. 
Requiring authentication will prevent this.

best regards,
Torsten.

> Cheers,
>
> Thomas
>
> *BMW Group*
> Thomas Kupka
>
> Customer Data Management, FG-6301
>
> GCDM Identity & Access Management
>
> Bremer Straße 6
>
> 80807 München
>
> Postanschrift:
>
> 80788 München
>
>
> Tel: +49-89-382-54083
> Mail: Thomas.Kupka@bmw.de 
> Web: http://www.bmwgroup.com/
> --------------------------------------------------------
> Bayerische Motoren Werke Aktiengesellschaft
> Vorstand: Harald Krüger (Vorsitzender),
> Milagros Caiña Carreiro-Andree, Klaus Draeger,
> Friedrich Eichiner, Klaus Fröhlich, Ian Robertson,
> Peter Schwarzenbauer, Oliver Zipse.
> Vorsitzender des Aufsichtsrats: Norbert Reithofer
> Sitz und Registergericht: München HRB 42243
> --------------------------------------------------------
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------010101040006020601060008
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Thomas,

    

    see comments inline. 

    

    
Am 19.02.2016 um 12:14 schrieb
      Thomas.Kupka@bmw.de:

    

    

      
      
      
      

        
Hi,

        
 

        
we use the OAuth 2.0
            Implicit grant to issue access_tokens to client applications
            such as HTML 5 web apps that have no secure means to
            securely authenticating themselves. Even if the credentials
            would be obfuscated, any user could extract them from the
            HTTP requests their User Agent makes with minimal effort.
            Since RFC 7009 also talks about the usage of CORS to support
            User-Agent clients, however, I believe that these clients
            should be supported.

        
 

        
So I am having trouble
            supporting the revocation requirement in RFC 7009 which
            states:

        
 

        
   The client also includes its authentication credentials as described

        
   in Section 2.3. of [RFC6749].

        
 

        
Looking at said section
            in in RFC 6749, it states:

        
 

        
   If the client type is confidential, the client and authorization

        
   server establish a client authentication method suitable for the

        
   security requirements of the authorization server.  The authorization

        
   server MAY accept any form of client authentication meeting its

        
   security requirements.

        
 

        
I am unsure whether
            “having no form of client authentication” conforms to the
            standard, can you comment on this?

        
 

      

    

    

    Yes, it does. The client shall use the authentication means it would
    use on the AS's token endpoint as well. And in the same way as
    public clients only identify themself in this use case, they are
    supposed to do the same at the revocation endpoint. 

    

    

      

        
As a side note, I wonder
            why client authentication for token revocations is required
            anyway, because if a client received a token by any legit
            means, it should always be able to revoke it, regardless of
            authentication. And if an unauthorized client ‘stole’ any
            type of token, revoking it should also be possible, since
            loss of service for the intended client should always be
            preferred over misusing the token.

      

    

    

    Good catch :-) We discussed this when we went through WG review. The
    position we finally decided to take is: what is the worst thing an
    attacker could do on the revocation endpoint? It would revoke tokens
    in order to interupt the respective service for the resource owner.
    Requiring authentication will prevent this.

    

    best regards,

    Torsten.

    

    

      

        

        
 

        
Cheers,

        
 

        
Thomas

        
 

        
 

        
BMW Group

            Thomas Kupka

        
Customer Data Management, FG-6301

        
GCDM Identity & Access Management

        
Bremer Straße 6

        
80807 München

        
 

        
Postanschrift:

        
80788 München

        


            Tel: +49-89-382-54083

            Mail: Thomas.Kupka@bmw.de

            Web:  http://www.bmwgroup.com/

            --------------------------------------------------------

          Bayerische
            Motoren Werke Aktiengesellschaft

            Vorstand: Harald Krüger (Vorsitzender),

            Milagros Caiña Carreiro-Andree, Klaus Draeger,

            Friedrich Eichiner, Klaus Fröhlich, Ian Robertson,

            Peter Schwarzenbauer, Oliver Zipse.

            Vorsitzender des Aufsichtsrats: Norbert Reithofer

            Sitz und Registergericht: München HRB 42243

            --------------------------------------------------------

        
 

      

      

      

      

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


    

    

  


--------------010101040006020601060008--


From nobody Sun Feb 28 13:32:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3B1B2C6E for ; Sun, 28 Feb 2016 13:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_3L3jMKi5O4 for ; Sun, 28 Feb 2016 13:31:57 -0800 (PST)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6B51B2B8C for ; Sun, 28 Feb 2016 13:31:57 -0800 (PST)
Received: by mail-pa0-x235.google.com with SMTP id fl4so80149863pad.0 for ; Sun, 28 Feb 2016 13:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=wdaeUNMYKMw+6Ul2sBIzsUjIwJww6ZDsCB+qclGHnlQ=; b=ZPl0qLCZ1ZXiA/etB8CiW7dMw72E7LuIbkxPR+Z7xsLdG1LJVqIVdxu1F+s+mOv2R3 cNU7F6PgwucKz0KhWGvDRRUXBfUDXwz8w2rYJ23k57f2fzVZAH5GfyN/fHnVlyr9QQhS JolxbtJnEyJcNi1nrbTvV3QJudauiybHBB0FuxZ2jSXhagr1B+OuByh0esvXdDz7K+so 7iPVdBrjMQHtFGQKLH7DWy8a4WcmFn6D/pBZi3Yu461ue0xJBC8zvnpReHnIsl8AfRdd SnTLI+V32mUOKlBTRa4s6mu2xSybubfHE6u6LvTnCxSyDtfp/NRJg6XqCH+Er7qb4vLf 6L3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=wdaeUNMYKMw+6Ul2sBIzsUjIwJww6ZDsCB+qclGHnlQ=; b=XYY1CaLDiLbn5j4ZZLp4rNkQDMw0AFa7sGp2xHne+xkkaA3Xvm9PofjVO38K8Mfnw/ BbAzDd6fdRtNA3z39gQUD8uz+7SFOCIwKTRQDacGZzwMgFTabbNuN7pf+0fzpDv0iCPl 86j1xlqb33n2t7b/Oc5vR+vLckKImiEHy5XFOLJVBWyvBfEQVfFoBdDiNiUPI+OCyrtX llDu/CzAO4SmmrX++YKcDOYKvdTYfjPa4s9oCr7WpV1s90H+6ANLU38R7jyy8dGoNRFb DlIV/yhzf2MrvGNGw+1xkOW7XGMsdgCTSdbYhc4kiRkLN/F4f8maHO6k1OW73DhKkYAm qP6Q==
X-Gm-Message-State: AD7BkJI3KGhIE57m30FKmWMeUduu5iXjru00YEendS32s/sqG7vz1jV9gTQSUvx7biFtYA==
X-Received: by 10.66.234.104 with SMTP id ud8mr17754601pac.143.1456695116911;  Sun, 28 Feb 2016 13:31:56 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id v3sm2386158par.17.2016.02.28.13.31.54 for  (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:31:55 -0800 (PST)
From: "Brock Allen" 
To: 
Date: Sun, 28 Feb 2016 16:31:33 -0500
Message-ID: <003b01d1726f$66036590$320a30b0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01D17245.7D2FA780"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFyb0yKpLxOPzSXQhyhHtvnfR8zww==
Content-Language: en-us
Archived-At: 
Subject: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:31:59 -0000

This is a multipart message in MIME format.

------=_NextPart_000_003C_01D17245.7D2FA780
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Given that the client can iterate over the query/headers in any order to
generate the concatenated value to hash, I think there's an issue with query
string or header values with repeated keys. I'll stick with query params for
simplicity in my sample. 

 

If a client signs this concatenated query: "a=1&a=2" then the "p" value in
the signed JSON object could be this:

 

"p": [["a", "a"], "blah"]

 

On the resource server, how do you know which key/value pair to put in which
order for verification? Also, given that different server implementations
express these incoming parameters in different ways, it seems problematic to
be consistent.

 

Thanks.

 

-Brock

 


------=_NextPart_000_003C_01D17245.7D2FA780
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Given that the =
client can iterate over the query/headers in any order to generate the =
concatenated value to hash, I think there’s an issue with query =
string or header values with repeated keys. I’ll stick with query =
params for simplicity in my sample. 
 
If a client signs =
this concatenated query: “a=3D1&a=3D2” then the =
“p” value in the signed JSON object could be =
this:
 
"p": =
[["a", "a"], =
"blah"]
 
On the resource =
server, how do you know which key/value pair to put in which order for =
verification? Also, given that different server implementations express =
these incoming parameters in different ways, it seems problematic to be =
consistent.
 
Thanks.
 
-Brock
 

------=_NextPart_000_003C_01D17245.7D2FA780--


From nobody Sun Feb 28 13:34:12 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08E21B2F1D for ; Sun, 28 Feb 2016 13:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nLQspvTAGBc for ; Sun, 28 Feb 2016 13:34:08 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6B41B2E33 for ; Sun, 28 Feb 2016 13:34:07 -0800 (PST)
X-AuditID: 12074425-593ff70000000508-6d-56d367ce6d0c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 41.05.01288.EC763D65; Sun, 28 Feb 2016 16:34:06 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u1SLY5CP016614; Sun, 28 Feb 2016 16:34:06 -0500
Received: from [10.0.1.8] (ip68-104-118-32.lv.lv.cox.net [68.104.118.32]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1SLY1U7027857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Feb 2016 16:34:04 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_497B2CDF-277D-4A20-B972-D083D20512B0"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: 
Date: Sun, 28 Feb 2016 13:34:01 -0800
Message-Id: <4DF9257B-EAFE-440C-B1DD-FB7507F1BB18@mit.edu>
References: <008201d170a4$f5216910$df643b30$@gmail.com> <69709F83-8D24-44DE-9A3B-D3BF8F70C201@mit.edu> 
To: Dominick Baier 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT1z2XfjnM4NtUNYsZP46yW8y4cJXZ 4uTbV2wOzB47Z91l91iy5CeTx/Y1F5gCmKO4bFJSczLLUov07RK4Mqbe2spa8Nyt4vWXwywN jBNsuxg5OCQETCQuHyjpYuTiEBJoY5JY/vgnO4SzkVGid8ZUVgjnGJNEy+TVQA4nB7NAgsTT fw9YQGxeAT2JV7cus4JMEhYwlpj2MRUkzCagKjF9TQsTSJhTwEZix3YDkDALUHjjFohOZgFv iVfL+tkgplhJLOt7xwixahqjxNFjf5lBEiJA4yetmsEOYksIyErs/v2IaQIj/ywkV8xCcgVE XFti2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZ opeaUrqJERzqLqo7GCccUjrEKMDBqMTD+0LzcpgQa2JZcWXuIUZJDiYlUd4+8YthQnxJ+SmV GYnFGfFFpTmpxYcYJTiYlUR43S2BynlTEiurUovyYVLSHCxK4rwxN4+GCQmkJ5akZqemFqQW wWRlODiUJHhT04AaBYtS01Mr0jJzShDSTBycIMN5gIbLg9TwFhck5hZnpkPkTzEqSonz6oEk BEASGaV5cL2gVOSSUabwilEc6BVh3g0gVTzANAbX/QpoMBPQYIn1l0AGlyQipKQaGA8ez1Jx 0TLW3Ze4xYzxpcWCx9He83J/OKX/PrS2SCV+/tSQzpx5giLfz95wql2QN+Ek+9rnL/648CjY RM05elbF9rwsV46DzCdBFddv8eys5jbXN2dP/1u37fOJSXz6n369VT3hYtW1Ufh1vciPEj53 Ad74iadVrrP3ZZatZJDZMnn21NR/65RYijMSDbWYi4oTAUNRdG8gAwAA
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP signing spec and nonce
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:34:10 -0000

--Apple-Mail=_497B2CDF-277D-4A20-B972-D083D20512B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I understand how they work, I=E2=80=99ve built exactly that cache =
before. But I askWouldn=E2=80=99t a unique timestamp have the same =
effect? Currently it=E2=80=99s integer seconds but slicing that down =
further (floating point seconds?) if people desired would allow for =
multiple signed messages in the same second from the same client using =
the otherwise same parameters.=20

=E2=80=9COther protocols do it=E2=80=9D is not a compelling reason on =
its own, especially when the example of =E2=80=9Cother protocols=E2=80=9D =
includes WS-* ;)

Seriously though, an optional nonce is easy to add to the draft if =
there=E2=80=99s enough WG support, I=E2=80=99m just hesitant to add more =
complexity than needed to this.

 =E2=80=94 Justin

> On Feb 26, 2016, at 11:06 PM, Dominick Baier =
 wrote:
>=20
> The nonce would allow to build a replay cache, the timestamp to trim =
that cache and reject messages that are too old.
>=20
> Similar protocols have a nonce for the above reasons (ws-sec msg =
security, hawk)...
>=20
> =E2=80=94=20
> cheers
> Dominick Baier
>=20
> On 27 February 2016 at 03:48:00, Justin Richer (jricher@mit.edu =
) wrote:
>=20
>> I=E2=80=99d be glad to add in a nonce if there=E2=80=99s a compelling =
reason for it, such as closing a security attack vector.
>>=20
>> What=E2=80=99s the proposed purpose of the nonce? Is it just to add =
randomness to the signing base? Or is it to prevent replay at the RS? If =
the former, the timestamp should add enough of that and it can be =
verified to be within a reasonable window by the RS by comparing it with =
the time the request was made. If the latter, the RS is going to have to =
track previously used nonces for some amount of time.=20
>>=20
>> There was a small discussion of just signing an outgoing =E2=80=9CDate:=
=E2=80=9D header instead of the separate timestamp, but the timestamp =
seemed to be more robust. I forget the full reasoning though.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Feb 26, 2016, at 9:49 AM, Brock Allen > wrote:
>>>=20
>>> Question about the HTTP signing spec =E2=80=93 why is there no nonce =
(and just a timestamp)?
>>> =20
>>> TIA
>>> =20
>>> -Brock
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> _______________________________________________=20
>> OAuth mailing list=20
>> OAuth@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/oauth=20


--Apple-Mail=_497B2CDF-277D-4A20-B972-D083D20512B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I understand how they work, I=E2=80=99ve built exactly that =
cache before. But I askWouldn=E2=80=99t a unique timestamp have the same =
effect? Currently it=E2=80=99s integer seconds but slicing that down =
further (floating point seconds?) if people desired would allow for =
multiple signed messages in the same second from the same client using =
the otherwise same parameters. 

=E2=80=9COther protocols do it=E2=80=9D =
is not a compelling reason on its own, especially when the example of =
=E2=80=9Cother protocols=E2=80=9D includes WS-* ;)

Seriously though, an =
optional nonce is easy to add to the draft if there=E2=80=99s enough WG =
support, I=E2=80=99m just hesitant to add more complexity than needed to =
this.

 =E2=80=94 Justin

On =
Feb 26, 2016, at 11:06 PM, Dominick Baier <dbaier@leastprivilege.com> wrote:



The nonce would allow to build =
a replay cache, the timestamp to trim that cache and reject messages =
that are too old.

Similar =
protocols have a nonce for the above reasons (ws-sec msg security, =
hawk)...
 
 
=E2=80=94 
cheers
Dominick Baier
 
On 27 February 2016 at 03:48:00, =
Justin Richer (jricher@mit.edu) wrote:
 











I=E2=80=99d be glad to add in a nonce if there=E2=80=99s =
a compelling
reason for it, such as closing a security attack vector.




What=E2=80=99s the proposed purpose of the nonce? Is it just to add
randomness to the signing base? Or is it to prevent replay at the
RS? If the former, the timestamp should add enough of that and it
can be verified to be within a reasonable window by the RS by
comparing it with the time the request was made. If the latter, the
RS is going to have to track previously used nonces for some amount
of time. 




There was a small discussion of just signing an
outgoing =E2=80=9CDate:=E2=80=9D header instead of the separate =
timestamp, but the
timestamp seemed to be more robust. I forget the full reasoning
though.







 =E2=80=94 Justin









On Feb 26, 2016, at 9:49 AM, Brock Allen <brockallen@gmail.com>
wrote:










Question about the HTTP signing spec =E2=80=93 why is there =
no nonce
(and just a timestamp)?


 


TIA


 


-Brock


 





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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











_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

=

=

--Apple-Mail=_497B2CDF-277D-4A20-B972-D083D20512B0--


From nobody Sun Feb 28 13:37:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718EC1A6F8C for ; Sun, 28 Feb 2016 13:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfPMh3c7xBFT for ; Sun, 28 Feb 2016 13:37:21 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356401A6F93 for ; Sun, 28 Feb 2016 13:37:20 -0800 (PST)
X-AuditID: 1209190f-077ff7000000091f-44-56d3688f443f
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id F1.6A.02335.F8863D65; Sun, 28 Feb 2016 16:37:19 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u1SLbJoo011543; Sun, 28 Feb 2016 16:37:19 -0500
Received: from [10.0.1.8] (ip68-104-118-32.lv.lv.cox.net [68.104.118.32]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1SLbF2o028791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Feb 2016 16:37:18 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC585A9F-94EA-4CEA-8EDC-DD148CB206B4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <003b01d1726f$66036590$320a30b0$@gmail.com>
Date: Sun, 28 Feb 2016 13:37:14 -0800
Message-Id: <16802C28-5478-41D5-8596-30C617C89016@mit.edu>
References: <003b01d1726f$66036590$320a30b0$@gmail.com>
To: Brock Allen 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1u3PuBxmcPy0icWMH0fZLU6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGV8+DeRvWCmXcXfDW0sDYz7TLsYOTkkBEwk dl1tY+ti5OIQEmhjkpgxcxorhLORUWJh6yIo5xiTxLvJM1hAWpgFEiQ+Lj3JBGLzCuhJvLp1 mRXEFhbwlvh7qB/MZhNQlZi+pgWshlPAQuLzuSagOAcHC1D8zFUdEJNZQF1i7soIEJNXwEpi X5ccSLGQgLnEw7/LmUFsEQE1iYXT5zND3Ckrsfv3I6YJjPyzkNwwC8kNEHFtiWULXzND2JoS +7uXs2CKa0h0fpvIuoCRbRWjbEpulW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwUEvy 72D8dlDpEKMAB6MSD+8LzcthQqyJZcWVuYcYJTmYlER5+8QvhgnxJeWnVGYkFmfEF5XmpBYf YpTgYFYS4XW3BCrnTUmsrEotyodJSXOwKInzxtw8GiYkkJ5YkpqdmlqQWgSTleHgUJLgPZQO 1ChYlJqeWpGWmVOCkGbi4AQZzgM0nDkDZHhxQWJucWY6RP4Uo6KUOO9ukGYBkERGaR5cLyjp uGSUKbxiFAd6RZg3GaSKB5iw4LpfAQ1mAhossf4SyOCSRISUVANjV5sOE9Ot1/GiQQI3g9XT fn/7vN/i/b+t17e93Kn5MU39XExOS16S1MdlD6bxs09T+cm5+vo0jmzhyhdX1x448PblMW++ Q7d/7FXcJ9QZO8Ng6dzkGb0fmPwW750e+Mr+RkO8ad5+3qr/RXcTyiJ9Z/2aE77MwsHw3onH Vq23t55rZJC2F/t3TImlOCPRUIu5qDgRAL49mvYVAwAA
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:37:23 -0000

--Apple-Mail=_AC585A9F-94EA-4CEA-8EDC-DD148CB206B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In =C2=A77.5 we currently have:

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

Which is to say: Yeah, that=E2=80=99s a problem, probably. We either =
declare this behavior out of scope and say you can=E2=80=99t use this =
method with that kind of API (or at least those parameters/headers) or =
we define a mechanism for handling that. I=E2=80=99m in favor of the =
former, and removing the text from the generation sections that says =
repeated parameters are processed with no special handling, making them =
explicitly out of scope throughout.

I would love to see more feedback from the group about this, especially =
if someone=E2=80=99s got a clever solution.

 =E2=80=94 Justin

> On Feb 28, 2016, at 1:31 PM, Brock Allen  wrote:
>=20
> Given that the client can iterate over the query/headers in any order =
to generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. I=E2=80=99ll =
stick with query params for simplicity in my sample.
> =20
> If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D=
 then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
> =20
> "p": [["a", "a"], "blah"]
> =20
> On the resource server, how do you know which key/value pair to put in =
which order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be consistent.
> =20
> Thanks.
> =20
> -Brock
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_AC585A9F-94EA-4CEA-8EDC-DD148CB206B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In =C2=A77.5 we currently have:

   The behavior =
of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]


Which is to =
say: Yeah, that=E2=80=99s a problem, probably. We either declare this =
behavior out of scope and say you can=E2=80=99t use this method with =
that kind of API (or at least those parameters/headers) or we define a =
mechanism for handling that. I=E2=80=99m in favor of the former, and =
removing the text from the generation sections that says repeated =
parameters are processed with no special handling, making them =
explicitly out of scope throughout.

I would love to see more feedback from =
the group about this, especially if someone=E2=80=99s got a clever =
solution.

 =E2=80=94 Justin

On =
Feb 28, 2016, at 1:31 PM, Brock Allen <brockallen@gmail.com> wrote:



Given =
that the client can iterate over the query/headers in any order to =
generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. I=E2=80=99ll =
stick with query params for simplicity in my sample. 
 
If a =
client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D =
then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
 
"p": =
[["a", "a"], "blah"]
 
On the resource server, how do =
you know which key/value pair to put in which order for verification? =
Also, given that different server implementations express these incoming =
parameters in different ways, it seems problematic to be consistent.
 
Thanks.
 
-Brock
 
_________________________________=
______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_AC585A9F-94EA-4CEA-8EDC-DD148CB206B4--


From nobody Sun Feb 28 13:40:47 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B44C1A702E for ; Sun, 28 Feb 2016 13:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixVIOsjFVMJ0 for ; Sun, 28 Feb 2016 13:40:44 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 DBF361A7028 for ; Sun, 28 Feb 2016 13:40:43 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id t66so14340135pfb.3 for ; Sun, 28 Feb 2016 13:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=VWVleGXubf9/1AzwxqkDJeu8V4yTGLvhMVXDlnqSpOc=; b=RaVl6BaOxJPzbrhXsRG+C9fWvbo+hbiwNcB3PPsPEwe7JKn+sCmG81XfgO1RZlHaR9 xZLLJnkOOAT665wi49lgQW7zBQ37OvixGtUqtjJt+m7Wm53uW2cEce5qSeiCUCtdewoZ Gf39A3p0D/FrNWyYDKO3ezskwuxd8FzBEoMVNvMrizeF1tzFdnxnQjRyYSUQlzHmuEwc gHfkI6qm6FtK1OBQiChaONyGrFK5UdNfmhNNRGBA9Gu4lCCMmZNoHH5UD+lXUmZTICYK FhB/LDupTfRLVwPrObHpXcq7WOyTHGOc/Li5BUn1y02rILaIbcirColoGDOLscIMpLre Dftg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=VWVleGXubf9/1AzwxqkDJeu8V4yTGLvhMVXDlnqSpOc=; b=C3ShMEcmjF9upraRw5t/fqhlxWNkR/fFmC9HJd6EIDewAYP9F33LRP3R1YDWejTo+7 iGDYp5OXG07XGCnHLctZz0mtszqJf8VfZfWJOGvJucV2z98RJ1u9gE0Nu2IQD+eYrfOB XxzGp31LTqG9IiGqSKcfrw3qVNKlCh5jO7XloKVwq0LRM21kjCWxMr3s2d0BkeDLmze/ 4VcmWaMgKiOHPCoydferxo9Buz0J6QjVFfALKMiR5znGYBtVYrKOYaTi5a6DbwqVQAqp aTzk1pxjqiQZvwk0UkflOrQvauLCfkviJmXfIgI/W6cKnhN3ead+7pdFTPl7AmUbNC/U +Hag==
X-Gm-Message-State: AD7BkJICeUdcHRyslX5poF8hcWeU986m37+Juf5/XcFTDUDttqO15FtD+POElu1Gdim1Nw==
X-Received: by 10.98.33.67 with SMTP id h64mr12591764pfh.157.1456695643452; Sun, 28 Feb 2016 13:40:43 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id w12sm33001143pfa.79.2016.02.28.13.40.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:40:42 -0800 (PST)
From: "Brock Allen" 
To: "'Justin Richer'" 
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu>
In-Reply-To: <16802C28-5478-41D5-8596-30C617C89016@mit.edu>
Date: Sun, 28 Feb 2016 16:40:20 -0500
Message-ID: <004401d17270$a0183660$e048a320$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01D17246.B7449F60"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHoC835bA=
Content-Language: en-us
Archived-At: 
Cc: "''" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:40:46 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0045_01D17246.B7449F60
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ok, missed that =E2=80=93 thanks.

=20

For now in my implementation I=E2=80=99m also ignoring this problem :)

=20

-Brock

=20

From: Justin Richer [mailto:jricher@mit.edu]=20
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen 
Cc:  
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys

=20

In =C2=A77.5 we currently have:

=20

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

=20

Which is to say: Yeah, that=E2=80=99s a problem, probably. We either =
declare this behavior out of scope and say you can=E2=80=99t use this =
method with that kind of API (or at least those parameters/headers) or =
we define a mechanism for handling that. I=E2=80=99m in favor of the =
former, and removing the text from the generation sections that says =
repeated parameters are processed with no special handling, making them =
explicitly out of scope throughout.

=20

I would love to see more feedback from the group about this, especially =
if someone=E2=80=99s got a clever solution.

=20

 =E2=80=94 Justin

=20

On Feb 28, 2016, at 1:31 PM, Brock Allen  > wrote:

=20

Given that the client can iterate over the query/headers in any order to =
generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. =
I=E2=80=99ll stick with query params for simplicity in my sample.=20

=20

If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D =
then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:

=20

"p": [["a", "a"], "blah"]

=20

On the resource server, how do you know which key/value pair to put in =
which order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be consistent.

=20

Thanks.

=20

-Brock

=20

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

=20


------=_NextPart_000_0045_01D17246.B7449F60
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ok, =
missed that =E2=80=93 thanks.
 
=

For now in my =
implementation I=E2=80=99m also ignoring this problem =
:)
 
=

-Brock
=

 
=

From: =
Justin Richer [mailto:jricher@mit.edu] 
Sent: Sunday, February =
28, 2016 4:37 PM
To: Brock Allen =
<brockallen@gmail.com>
Cc: <oauth@ietf.org> =
<OAuth@ietf.org>
Subject: Re: [OAUTH-WG] HTTP request =
signing and repeated query/header keys
 
In =C2=A77.5 =
we currently have:
 
=C2=A0=C2=A0 The =
behavior of repeated query parameters or repeated HTTP headers =
is
=C2=A0=C2=A0 undefined by this =
specification.=C2=A0 If a header or query parameter =
is
=C2=A0=C2=A0 repeated on either the outgoing =
request from the client or the
=C2=A0=C2=A0 =
incoming request to the protected resource, that query parameter =
or
=C2=A0=C2=A0 header name MUST NOT be covered by =
the hash and signature. [[ Note to
=C2=A0=C2=A0 the =
WG: is this something we need to cover? ]]
 
Which is to say: Yeah, that=E2=80=99s a problem, =
probably. We either declare this behavior out of scope and say you =
can=E2=80=99t use this method with that kind of API (or at least those =
parameters/headers) or we define a mechanism for handling that. =
I=E2=80=99m in favor of the former, and removing the text from the =
generation sections that says repeated parameters are processed with no =
special handling, making them explicitly out of scope =
throughout.
 
I =
would love to see more feedback from the group about this, especially if =
someone=E2=80=99s got a clever solution.
 
 =E2=80=94 Justin
 
On Feb 28, 2016, at 1:31 PM, Brock Allen <brockallen@gmail.com> =
wrote:
 
Given that the =
client can iterate over the query/headers in any order to generate the =
concatenated value to hash, I think there=E2=80=99s an issue with query =
string or header values with repeated keys. I=E2=80=99ll stick with =
query params for simplicity in my sample. =

 
If a client signs =
this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D then the =
=E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
 
"p": =
[["a", "a"], =
"blah"]
 
On the resource =
server, how do you know which key/value pair to put in which order for =
verification? Also, given that different server implementations express =
these incoming parameters in different ways, it seems problematic to be =
consistent.
 
Thanks.
 
-Brock
 
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 

------=_NextPart_000_0045_01D17246.B7449F60--


From nobody Sun Feb 28 13:41:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414B11A702E for ; Sun, 28 Feb 2016 13:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWg7e1Hdoyig for ; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 95A571A700F for ; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id 4so2095228pfd.1 for ; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=6/V4o7STht1sxdD/VQ1G9JI/XRchl+OpHQyiAv1zH98=; b=S1fNdWPKOpvXT5fruTFH7qHXziFVDUf8vu00KWKVsA9AWBFqxNQ564ToUdUJ3y0ITu 2IBROb1iG1UCQ+cnCOQucQ+6bj6HMKdb0loLQpB1hzDPH+S53rCYLArMlRSmyB0lcGNA SjpGhecEy3Ib9SD3ZJX+ibakwEOxLhaQWT3G6/mIkPZ2+8MjVf7WQixaH2SbG97Ih+ty yIzmJdalsb6hdqUyhNGQpXr5zzXccYRs4UKPgk1YREYchhVfScTY0o1vJUnLMkkGE09q 6+wzUl9s2xKDCWiBtgt8dxfq+i2R/svzbE0l5ERcq0/5FTFB4h0q4YhAxkpPElX/CzC3 45OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=6/V4o7STht1sxdD/VQ1G9JI/XRchl+OpHQyiAv1zH98=; b=FBrT57GTpsR3TNuSNLa0LEI95owuhtMm/TYK9IYxL5xtQPOvY7yhg4g6Ju0OrCcW9Y Nnwkpui4sS5gU7espowqFGUV2krvNRbThNQ2jX/XlKN7rf7W8+yHpX0D+36hMCem/ip2 Nmj3pqt4WZACTk7BAs77h9xeOMI6VXrV4EXDeSfbXzxdmM6nBv4DLX0+b2X4Wxdkica2 jTeZG/leBbD6KaSoBVg8dGLkuv70aWFQ5RCSuwJiAMWPhwmR6vHl6df9q5IComY9u450 Oqdl4ycVOV6BiK7pu0ZtpQWb0rhSiACAwHdoRzVpqiuPRZuTYoolprruYlYbOm+WsR/Q j9hA==
X-Gm-Message-State: AD7BkJJwUl3CfjEAx720BkU2JYo4HKILBjTeOP4rCKaWyraeyqBUC010Jwln0ETWVpZpng==
X-Received: by 10.98.68.220 with SMTP id m89mr17878084pfi.65.1456695704291; Sun, 28 Feb 2016 13:41:44 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id ll7sm33089178pab.6.2016.02.28.13.41.43 for  (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:41:43 -0800 (PST)
From: "Brock Allen" 
To: 
Date: Sun, 28 Feb 2016 16:41:12 -0500
Message-ID: <004901d17270$c49dbaf0$4dd930d0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01D17246.DBC8EB70"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFyb3Cta2A+egHyQ++Wc8zo3PDaMw==
Content-Language: en-us
Archived-At: 
Subject: [OAUTH-WG] HTTP signing and parameter validation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:41:46 -0000

This is a multipart message in MIME format.

------=_NextPart_000_004A_01D17246.DBC8EB70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Another question related to HTTP signing.

 

It's not clear to me from the RFC if the resource server should be using the
incoming pop token JWS to know what to verify, or if the resource server
should have a preconceived notion of what should be sent in the pop token.
For example, the query params: should the resource server decode the pop
token to see what a client included, or should a resource server always know
query params "a, b and c" should always be expected. The same goes for any
of the params (method, path, body, etc).

 

Thanks.

 

-Brock

 


------=_NextPart_000_004A_01D17246.DBC8EB70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Another question =
related to HTTP signing.
 
It’s not =
clear to me from the RFC if the resource server should be using the =
incoming pop token JWS to know what to verify, or if the resource server =
should have a preconceived notion of what should be sent in the pop =
token. For example, the query params: should the resource server decode =
the pop token to see what a client included, or should a resource server =
always know query params “a, b and c” should always be =
expected. The same goes for any of the params (method, path, body, =
etc).
 
Thanks.
 
-Brock
 

------=_NextPart_000_004A_01D17246.DBC8EB70--


From nobody Sun Feb 28 13:45:18 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F350C1A7D82 for ; Sun, 28 Feb 2016 13:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsN88wXT9hU5 for ; Sun, 28 Feb 2016 13:45:15 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2C91A7D85 for ; Sun, 28 Feb 2016 13:45:14 -0800 (PST)
X-AuditID: 12074422-f87ff700000071cb-5a-56d36a696d6d
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id FD.96.29131.96A63D65; Sun, 28 Feb 2016 16:45:13 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u1SLjC1k012226; Sun, 28 Feb 2016 16:45:12 -0500
Received: from [10.0.1.8] (ip68-104-118-32.lv.lv.cox.net [68.104.118.32]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1SLj8Tm031275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Feb 2016 16:45:11 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_695BF99B-FC7E-45F2-A58D-6FD4890D7D07"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <004901d17270$c49dbaf0$4dd930d0$@gmail.com>
Date: Sun, 28 Feb 2016 13:45:07 -0800
Message-Id: <6C411BBF-9F01-4EA5-977B-B60517B698BC@mit.edu>
References: <004901d17270$c49dbaf0$4dd930d0$@gmail.com>
To: Brock Allen 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hTV1s3Muhxm0P2N12LGj6PsFiffvmJz YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIOLEkvWGhQMbFvPmMD43nNLkYODgkBE4lX G5m6GLk4hATamCQe7WyCcjYySjS+7meHcI4xScy9NpcJpINZIEHi0kG+LkZODl4BPYlXty6z gtjCArYS3x4tZQOx2QRUJaavaWECsTkFLCS2r13KAmKzAMXvtU5ggxijLjF3ZQTEGCuJBRsP gZUICZhL9D7/BDZGREBNYuH0+cwgtoSArMTu34+YJjDyz0I4YhaSI0BsZgFtiWULXzND2JoS +7uXs2CKa0h0fpvIuoCRbRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQQLO7 KO1gnPjP6xCjAAejEg/vC83LYUKsiWXFlbmHGCU5mJREefvEL4YJ8SXlp1RmJBZnxBeV5qQW H2KU4GBWEuF1twQq501JrKxKLcqHSUlzsCiJ8wZFHgsTEkhPLEnNTk0tSC2CycpwcChJ8GZm AjUKFqWmp1akZeaUIKSZODhBhvMADc8GqeEtLkjMLc5Mh8ifYlSUEudNBUkIgCQySvPgekEJ xyWjTOEVozjQK8K8XiBVPMBkBdf9CmgwE9BgifWXQAaXJCKkpBoYW6+mVOYZ+9n/WhjAN3HD k28cpzcsY7n0R+K/4Yw107l5b53+/l/ZpFNhR+j/tTuqckxC/j+0ecWQy2famxvB87/P++D+ 9Mnr9yxVM1e4a3ejVfr9TJ8fu3YfeWLzwm3N5E2hN18e0eW6rbV6wuWE+w97OQ+cPilkfPu1 ZM6FJ3u1ilplnxmsaFNiKc5INNRiLipOBAAszyoiEwMAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP signing and parameter validation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:45:17 -0000

--Apple-Mail=_695BF99B-FC7E-45F2-A58D-6FD4890D7D07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It=E2=80=99s a bit of both and it=E2=80=99s going to be highly specific =
to the API being protected. The RS should reject a signed request in =
which a critical parameter is unsigned =E2=80=94 some implementations of =
OpenID 2.0 were susceptible to exactly this kind of attack a number of =
years ago.=20

We could probably add more guidance text to describe what the API =
designers need to communicate to the client and the RS in terms of =
what=E2=80=99s expected to be covered by the signature. I=E2=80=99m open =
to suggested text on that point!

 =E2=80=94 Justin

> On Feb 28, 2016, at 1:41 PM, Brock Allen  wrote:
>=20
> Another question related to HTTP signing.
> =20
> It=E2=80=99s not clear to me from the RFC if the resource server =
should be using the incoming pop token JWS to know what to verify, or if =
the resource server should have a preconceived notion of what should be =
sent in the pop token. For example, the query params: should the =
resource server decode the pop token to see what a client included, or =
should a resource server always know query params =E2=80=9Ca, b and c=E2=80=
=9D should always be expected. The same goes for any of the params =
(method, path, body, etc).
> =20
> Thanks.
> =20
> -Brock
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_695BF99B-FC7E-45F2-A58D-6FD4890D7D07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It=E2=80=99s a bit of both and it=E2=80=99s going to be =
highly specific to the API being protected. The RS should reject a =
signed request in which a critical parameter is unsigned =E2=80=94 some =
implementations of OpenID 2.0 were susceptible to exactly this kind of =
attack a number of years ago. 

We could probably add more guidance =
text to describe what the API designers need to communicate to the =
client and the RS in terms of what=E2=80=99s expected to be covered by =
the signature. I=E2=80=99m open to suggested text on that =
point!

 =E2=
=80=94 Justin

On Feb 28, 2016, at 1:41 PM, =
Brock Allen <brockallen@gmail.com> wrote:



Another question related to HTTP signing.
 
It=E2=80=
=99s not clear to me from the RFC if the resource server should be using =
the incoming pop token JWS to know what to verify, or if the resource =
server should have a preconceived notion of what should be sent in the =
pop token. For example, the query params: should the resource server =
decode the pop token to see what a client included, or should a resource =
server always know query params =E2=80=9Ca, b and c=E2=80=9D should =
always be expected. The same goes for any of the params (method, path, =
body, etc).
 
Thanks.
 
-Brock
 
_________________________________=
______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_695BF99B-FC7E-45F2-A58D-6FD4890D7D07--


From nobody Sun Feb 28 13:50:50 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2321A854C for ; Sun, 28 Feb 2016 13:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDFhgM1IWxnK for ; Sun, 28 Feb 2016 13:50:46 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 0B0431A871C for ; Sun, 28 Feb 2016 13:50:45 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id w128so35009603pfb.2 for ; Sun, 28 Feb 2016 13:50:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=OYySqBMf/XJO7f8xpz+o0IOrL2kjO7JIZ3Yg9XWUj4M=; b=xoCykQJ0/q2XlR7MBfp8Y3erJMMpLH81G9PC6MyH2j20xjFu+GOAqOL+j+n1g0HwTC 5q244S7Y9VcdCECOE0N6egVpfc9+Mf7aoN06GA1VclUCWwb0RoAdY2mL1qb1NSPlN1S2 L0CyIgiqIcqKLa4gR+BfvyeqiHUlYzCfpNDmeN3cVEqxly30bMkvoI/9kna6uorSwvPV vmEl5lGZQp85v9Ubo7MdVFwoGffkF60YXBVj//8Y3lDEjaREqP05413+LJDgXnDPtOUl heDjpQ/nxA33aIgC3Cw2f3BINEwo9Igka6ykFhEdXjt9uaZSBp1qMaOg7BqGjZy1TGUO vy/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=OYySqBMf/XJO7f8xpz+o0IOrL2kjO7JIZ3Yg9XWUj4M=; b=RqU0p5tIz2vUDdd5CO389u3S5MS+0Mv40J/sayCn6/B/vFcjzey5snsUn5zXVkSu3B v1BPtEASZ70wocJXvpiOO4u9xOP2PGs7JLX5hqwJYXk3Kh+9wqmqErghzFccJm8EDbgb 7Crw5YfovAG0VmKZybl+sdEbFZzmXCkCN0Q/hhGG2py3WgF8SJWLT6wpbg4DqKivR77A kgiMsbar1NyEZ2qzUV5+MWfWAbQlYOcX2MZ1M518ASka98EcOd0si0tERD9shT0KHE5Y IRhZ8ZIoym4gIr1MJvatH/k3YpidjdyiCDQUJZwyBNzVE1Lqsm+j2uM+TjdVvGHKz2PU zlHQ==
X-Gm-Message-State: AD7BkJLNrQhy8XOr6cgNv7o/EUZLksWd63/F7j6IcI7zbw9cBYTAWk1hD9ObyzKXzIvB1w==
X-Received: by 10.98.34.5 with SMTP id i5mr17699314pfi.160.1456696245336; Sun, 28 Feb 2016 13:50:45 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id xu1sm33101340pab.31.2016.02.28.13.50.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 13:50:44 -0800 (PST)
From: "Brock Allen" 
To: "'Justin Richer'" 
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> 
In-Reply-To: 
Date: Sun, 28 Feb 2016 16:50:22 -0500
Message-ID: <005401d17272$070325a0$150970e0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01D17248.1E324DC0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHoC835bCAAAHpEA==
Content-Language: en-us
Archived-At: 
Cc: "''" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Feb 2016 21:50:48 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0055_01D17248.1E324DC0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Now that I=E2=80=99m thinking about this, the only thing that comes to =
mind is a hash of the value included somehow (which I=E2=80=99m sure =
you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case.=20

=20

-Brock

=20

From: Brock Allen [mailto:brockallen@gmail.com]=20
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' 
Cc: '' 
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header =
keys

=20

Ok, missed that =E2=80=93 thanks.

=20

For now in my implementation I=E2=80=99m also ignoring this problem :)

=20

-Brock

=20

From: Justin Richer [mailto:jricher@mit.edu]=20
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen  >
Cc:  >  >
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys

=20

In =C2=A77.5 we currently have:

=20

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

=20

Which is to say: Yeah, that=E2=80=99s a problem, probably. We either =
declare this behavior out of scope and say you can=E2=80=99t use this =
method with that kind of API (or at least those parameters/headers) or =
we define a mechanism for handling that. I=E2=80=99m in favor of the =
former, and removing the text from the generation sections that says =
repeated parameters are processed with no special handling, making them =
explicitly out of scope throughout.

=20

I would love to see more feedback from the group about this, especially =
if someone=E2=80=99s got a clever solution.

=20

 =E2=80=94 Justin

=20

On Feb 28, 2016, at 1:31 PM, Brock Allen  > wrote:

=20

Given that the client can iterate over the query/headers in any order to =
generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. =
I=E2=80=99ll stick with query params for simplicity in my sample.=20

=20

If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D =
then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:

=20

"p": [["a", "a"], "blah"]

=20

On the resource server, how do you know which key/value pair to put in =
which order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be consistent.

=20

Thanks.

=20

-Brock

=20

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

=20


------=_NextPart_000_0055_01D17248.1E324DC0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Now =
that I=E2=80=99m thinking about this, the only thing that comes to mind =
is a hash of the value included somehow (which I=E2=80=99m sure =
you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case. =

 
=

-Brock
=

 
=

From: Brock =
Allen [mailto:brockallen@gmail.com] 
Sent: Sunday, February =
28, 2016 4:40 PM
To: 'Justin Richer' =
<jricher@mit.edu>
Cc: '<oauth@ietf.org>' =
<OAuth@ietf.org>
Subject: RE: [OAUTH-WG] HTTP request =
signing and repeated query/header keys
 
Ok, missed that =E2=80=93 =
thanks.
 
=

For now in my =
implementation I=E2=80=99m also ignoring this problem =
:)
 
=

-Brock
=

 
=

From: =
Justin Richer [mailto:jricher@mit.edu] =

Sent: Sunday, February 28, 2016 4:37 PM
To: Brock =
Allen <brockallen@gmail.com>
C=
c: <oauth@ietf.org> =
<OAuth@ietf.org>
Subject: =
Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys
 
In =C2=A77.5 =
we currently have:
 
   The =
behavior of repeated query parameters or repeated HTTP headers =
is
   undefined by this =
specification.  If a header or query parameter =
is
   repeated on either the outgoing =
request from the client or the
   =
incoming request to the protected resource, that query parameter =
or
   header name MUST NOT be covered by =
the hash and signature. [[ Note to
   the =
WG: is this something we need to cover? ]]
 
Which is to say: Yeah, that=E2=80=99s a problem, =
probably. We either declare this behavior out of scope and say you =
can=E2=80=99t use this method with that kind of API (or at least those =
parameters/headers) or we define a mechanism for handling that. =
I=E2=80=99m in favor of the former, and removing the text from the =
generation sections that says repeated parameters are processed with no =
special handling, making them explicitly out of scope =
throughout.
 
I =
would love to see more feedback from the group about this, especially if =
someone=E2=80=99s got a clever solution.
 
 =E2=80=94 Justin
 
On Feb 28, 2016, at 1:31 PM, Brock Allen <brockallen@gmail.com> =
wrote:
 
Given that the =
client can iterate over the query/headers in any order to generate the =
concatenated value to hash, I think there=E2=80=99s an issue with query =
string or header values with repeated keys. I=E2=80=99ll stick with =
query params for simplicity in my sample. =

 
If a client signs =
this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D then the =
=E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
 
"p": =
[["a", "a"], =
"blah"]
 
On the resource =
server, how do you know which key/value pair to put in which order for =
verification? Also, given that different server implementations express =
these incoming parameters in different ways, it seems problematic to be =
consistent.
 
Thanks.
 
-Brock
 
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 

------=_NextPart_000_0055_01D17248.1E324DC0--


From nobody Sun Feb 28 17:13:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8AA1AD0A6 for ; Sun, 28 Feb 2016 17:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX7ip_Uh654J for ; Sun, 28 Feb 2016 17:12:58 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E491AD0B3 for ; Sun, 28 Feb 2016 17:12:56 -0800 (PST)
X-AuditID: 1209190c-c97ff70000002c85-1e-56d39b164681
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 0A.18.11397.61B93D65; Sun, 28 Feb 2016 20:12:55 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u1T1Cs7e010274; Sun, 28 Feb 2016 20:12:54 -0500
Received: from [10.0.1.8] (ip68-104-118-32.lv.lv.cox.net [68.104.118.32]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1T1CoVi031465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Feb 2016 20:12:52 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_F32D6EBC-F5A9-46B3-92DE-DCB70091EB19"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <005401d17272$070325a0$150970e0$@gmail.com>
Date: Sun, 28 Feb 2016 17:12:49 -0800
Message-Id: <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu>
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> <005401d17272$070325a0$150970e0$@gmail.com>
To: Brock Allen 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT1xWffTnM4McNRosZP46yW5x8+4rN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpY9Zyl4G4DY8XMTb/YGhgfFXQxcnJICJhI /Ny0hq2LkYtDSKCNSWL79e2sEM5GRok5c+cxQTjHmCTO/l3ICtLCLJAg8XbTexYQm1dAT+LV rctgcWEBb4m/h/rBbDYBVYnpa1qAmjk4OAUsJOY95AUJswCFP/98yQwSZhZQl5i7MgJiipXE 6kNb2SFWTWKU2Nz3nQ0kISKgJrFw+nxmiEtlJXb/fsQ0gZF/FpIrZiG5AiKuLbFs4WtmCFtT Yn/3chZMcQ2Jzm8TWRcwsq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdTLzSzRS00p3cQICmxO SZ4djGfeeB1iFOBgVOLhfaF5OUyINbGsuDL3EKMkB5OSKG+f+MUwIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK87pZA5bwpiZVVqUX5MClpDhYlcd7C/afDhATSE0tSs1NTC1KLYLIyHBxKErx+ s4AaBYtS01Mr0jJzShDSTBycIMN5gIYrgdTwFhck5hZnpkPkTzEqSonzTp8JlBAASWSU5sH1 ghKPS0aZwitGcaBXhHnXg1TxAJMWXPcroMFMQIMl1l8CGVySiJCSamA8+qvRmkerrdho9lSX jeys2g4alwru7DVady9w5+ZvP/h3TU+0y7/Pcn7F5OOlrxmDz+9wdu/LvBgzeQOL/N83LyZ2 83ZEvT+W1n7bOGLNw4mOt1x2qS6rq015tkmdJSc84GTM/4x/R9q/J/zrvlKy8dr7Kwce88xU OBoa4HO/s7rnXm3BrNb1SizFGYmGWsxFxYkAunWXbxcDAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 01:13:01 -0000

--Apple-Mail=_F32D6EBC-F5A9-46B3-92DE-DCB70091EB19
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yeah, that=E2=80=99s the trick =E2=80=94 you don=E2=80=99t want to end =
up replicating the entire HTTP message inside the JWS envelope, because =
then you end up with a SOAP kind of approach where you=E2=80=99re not =
really using the outside HTTP constructs to their fullest anymore.=20

In the end, I don=E2=80=99t think this spec is ever going to be =
perfectly universal, but if it can hit a majority of use cases with a =
simple and robust solution, I think we=E2=80=99re in good shape.

 =E2=80=94 Justin

> On Feb 28, 2016, at 1:50 PM, Brock Allen  wrote:
>=20
> Now that I=E2=80=99m thinking about this, the only thing that comes to =
mind is a hash of the value included somehow (which I=E2=80=99m sure =
you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case.
> =20
> -Brock
> =20
> From: Brock Allen [mailto:brockallen@gmail.com]=20
> Sent: Sunday, February 28, 2016 4:40 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header =
keys
> =20
> Ok, missed that =E2=80=93 thanks.
> =20
> For now in my implementation I=E2=80=99m also ignoring this problem :)
> =20
> -Brock
> =20
> From: Justin Richer [mailto:jricher@mit.edu ]=20=

> Sent: Sunday, February 28, 2016 4:37 PM
> To: Brock Allen >
> Cc: > >
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys
> =20
> In =C2=A77.5 we currently have:
> =20
>    The behavior of repeated query parameters or repeated HTTP headers =
is
>    undefined by this specification.  If a header or query parameter is
>    repeated on either the outgoing request from the client or the
>    incoming request to the protected resource, that query parameter or
>    header name MUST NOT be covered by the hash and signature. [[ Note =
to
>    the WG: is this something we need to cover? ]]
> =20
> Which is to say: Yeah, that=E2=80=99s a problem, probably. We either =
declare this behavior out of scope and say you can=E2=80=99t use this =
method with that kind of API (or at least those parameters/headers) or =
we define a mechanism for handling that. I=E2=80=99m in favor of the =
former, and removing the text from the generation sections that says =
repeated parameters are processed with no special handling, making them =
explicitly out of scope throughout.
> =20
> I would love to see more feedback from the group about this, =
especially if someone=E2=80=99s got a clever solution.
> =20
>  =E2=80=94 Justin
> =20
>> On Feb 28, 2016, at 1:31 PM, Brock Allen > wrote:
>> =20
>> Given that the client can iterate over the query/headers in any order =
to generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. I=E2=80=99ll =
stick with query params for simplicity in my sample.
>> =20
>> If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D=
 then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
>> =20
>> "p": [["a", "a"], "blah"]
>> =20
>> On the resource server, how do you know which key/value pair to put =
in which order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be consistent.
>> =20
>> Thanks.
>> =20
>> -Brock
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

> =20


--Apple-Mail=_F32D6EBC-F5A9-46B3-92DE-DCB70091EB19
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yeah, that=E2=80=99s the trick =E2=80=94 you don=E2=80=99t =
want to end up replicating the entire HTTP message inside the JWS =
envelope, because then you end up with a SOAP kind of approach where =
you=E2=80=99re not really using the outside HTTP constructs to their =
fullest anymore. 

In the end, I don=E2=80=99t think this spec is ever going to =
be perfectly universal, but if it can hit a majority of use cases with a =
simple and robust solution, I think we=E2=80=99re in good =
shape.

 =E2=
=80=94 Justin

On Feb 28, 2016, at 1:50 PM, =
Brock Allen <brockallen@gmail.com> wrote:



Now that I=E2=80=99m thinking about this, the only thing that =
comes to mind is a hash of the value included somehow (which I=E2=80=99m =
sure you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case. =

 
-Brock
 
From: =
Brock Allen [mailto:brockallen@gmail.com] 
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' <jricher@mit.edu>
Cc: =
'<oauth@ietf.org>' =
<OAuth@ietf.org>Subject: RE: [OAUTH-WG] HTTP request =
signing and repeated query/header keys
 
Ok, missed that =
=E2=80=93 thanks.
 
For now in my =
implementation I=E2=80=99m also ignoring this problem :)
 
-Brock
 
From: =
Justin Richer [mailto:jricher@mit.edu] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen <brockallen@gmail.com>
Cc: <oauth@ietf.org> <OAuth@ietf.org>
Subject:=
 Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
 
In =C2=A77.5 we =
currently have:
 
   The behavior of repeated query =
parameters or repeated HTTP headers is
   undefined by this specification.  If a =
header or query parameter is
   repeated on either the outgoing request from the =
client or the
   =
incoming request to the protected resource, that query parameter or
   header name MUST NOT =
be covered by the hash and signature. [[ Note to
   the WG: is this =
something we need to cover? ]]
 
Which is to say: Yeah, that=E2=80=99s a problem, =
probably. We either declare this behavior out of scope and say you =
can=E2=80=99t use this method with that kind of API (or at least those =
parameters/headers) or we define a mechanism for handling that. I=E2=80=99=
m in favor of the former, and removing the text from the generation =
sections that says repeated parameters are processed with no special =
handling, making them explicitly out of scope throughout.
 
I would love to see more feedback from the group =
about this, especially if someone=E2=80=99s got a clever solution.
 
 =E2=80=94 Justin
 
On Feb 28, 2016, =
at 1:31 PM, Brock Allen <brockallen@gmail.com> wrote:
 
Given that the client can iterate over the query/headers in =
any order to generate the concatenated value to hash, I think there=E2=80=99=
s an issue with query string or header values with repeated keys. I=E2=80=99=
ll stick with query params for simplicity in my sample. 
 
If a client signs this concatenated query: =E2=80=9Ca=3D1&a=
=3D2=E2=80=9D then the =E2=80=9Cp=E2=80=9D value in the signed JSON =
object could be this:
 
"p": [["a", "a"], "blah"]
 
On the resource server, how do you know which key/value pair =
to put in which order for verification? Also, given that different =
server implementations express these incoming parameters in different =
ways, it seems problematic to be consistent.
 
Thanks.
 
-Brock
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
<=
/div>
=

--Apple-Mail=_F32D6EBC-F5A9-46B3-92DE-DCB70091EB19--


From nobody Sun Feb 28 17:17:55 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA741AD0A6 for ; Sun, 28 Feb 2016 17:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0yxR_zEuTvx for ; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 A43441AD0A4 for ; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id w128so37147574pfb.2 for ; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=2p1FVcmw+R9qz7TmvqG9R7uUcEEANgxXRVmOmwz4Q5Q=; b=ROuvwNcAB76P6GlyEJhQ3bZIATT97vd0z7NMv+zJSZRGPwmYHhLKlRUpTf7Hwk+Rxc 4W2saX9Uw7x4KkV0kl7TITKCWCsmb6l5Dx78C+3zJWUmvlDHkYY18TwJKlIEb5DAH/hb k9R7KxUzPyoLQIHKKFsXxdXOSePTX62jpXrKIY6oWgv81myiHsGTsIaHaFlSQW7a8d/1 RR9mnAevBrSbAAhBmTw9ec1PP/GwynDV9/quI6GQn75G7U5sH/f7VN6vngNpOpx2JL60 Aw5fRXByGGMnf36+Iw19v9Ggj6UXhLPj/ebF2wTxhvD1lCpocjjtxSu8/LZdQ8lFUldo i/YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=2p1FVcmw+R9qz7TmvqG9R7uUcEEANgxXRVmOmwz4Q5Q=; b=GDceTKfNQSIEuM0iAe3WYIghI6uPGQMrTypgtx9+FQ6gpDvvU9ZuLYlCFfETGOX6AY AvPeE4aSW/kLjV0d59wmwSkyh6i0OB8HgCZ2uSygJ5/RqK6Ju6fFKzZJtyYIrEP+yhw1 6MZMVF3zbE8+HhK4kJYYb5hMAc+3vLjsvnh1/UiI/QskIopZsIU98AwaZf4laGkpO2b5 k5kDD544rX86Wfeh+GGrtX2H21cXEjcbgzvvMmI5wzsEz5hL5MTh86bgPS9gGzSK0rjH JKotgr+pBNVXvqT7D3xCt1IlrpAS+HlSaSSQbHdiFnMkFayosBBMsrJ9zTsGLr5ZvO/s CBKQ==
X-Gm-Message-State: AD7BkJIziWClbvDVr3ybOR//3zGZMQJNThg171kZpZqSsQU1EaEwz4PP5eVgYy5CHNTPlg==
X-Received: by 10.98.71.147 with SMTP id p19mr18657357pfi.165.1456708671076; Sun, 28 Feb 2016 17:17:51 -0800 (PST)
Received: from monk (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id h85sm19386524pfj.52.2016.02.28.17.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 17:17:49 -0800 (PST)
From: "Brock Allen" 
To: "'Justin Richer'" 
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> <005401d17272$070325a0$150970e0$@gmail.com> <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu>
In-Reply-To: <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu>
Date: Sun, 28 Feb 2016 20:17:27 -0500
Message-ID: <006f01d1728e$f52af250$df80d6f0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01D17265.0C56BF10"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHAaJuhE4B7FuyY6AS/gDA
Content-Language: en-us
Archived-At: 
Cc: "''" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 01:17:54 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0070_01D17265.0C56BF10
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yea, I=E2=80=99m cool with just saying =E2=80=9Cduplicate keys =
won=E2=80=99t work=E2=80=9D for my implementation, unless I do some =
implementation specific thing like sort them by value order or some such =
(but that would have to be on both sides).

=20

-Brock

=20

From: Justin Richer [mailto:jricher@mit.edu]=20
Sent: Sunday, February 28, 2016 8:13 PM
To: Brock Allen 
Cc:  
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys

=20

Yeah, that=E2=80=99s the trick =E2=80=94 you don=E2=80=99t want to end =
up replicating the entire HTTP message inside the JWS envelope, because =
then you end up with a SOAP kind of approach where you=E2=80=99re not =
really using the outside HTTP constructs to their fullest anymore.=20

=20

In the end, I don=E2=80=99t think this spec is ever going to be =
perfectly universal, but if it can hit a majority of use cases with a =
simple and robust solution, I think we=E2=80=99re in good shape.

=20

 =E2=80=94 Justin

=20

On Feb 28, 2016, at 1:50 PM, Brock Allen  > wrote:

=20

Now that I=E2=80=99m thinking about this, the only thing that comes to =
mind is a hash of the value included somehow (which I=E2=80=99m sure =
you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case.=20

=20

-Brock

=20

From: Brock Allen [mailto:brockallen@gmail.com]=20
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer'  >
Cc: ' >'  >
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header =
keys

=20

Ok, missed that =E2=80=93 thanks.

=20

For now in my implementation I=E2=80=99m also ignoring this problem :)

=20

-Brock

=20

From: Justin Richer [mailto:jricher@mit.edu]=20
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen  >
Cc:  >  >
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys

=20

In =C2=A77.5 we currently have:

=20

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

=20

Which is to say: Yeah, that=E2=80=99s a problem, probably. We either =
declare this behavior out of scope and say you can=E2=80=99t use this =
method with that kind of API (or at least those parameters/headers) or =
we define a mechanism for handling that. I=E2=80=99m in favor of the =
former, and removing the text from the generation sections that says =
repeated parameters are processed with no special handling, making them =
explicitly out of scope throughout.

=20

I would love to see more feedback from the group about this, especially =
if someone=E2=80=99s got a clever solution.

=20

 =E2=80=94 Justin

=20

On Feb 28, 2016, at 1:31 PM, Brock Allen  > wrote:

=20

Given that the client can iterate over the query/headers in any order to =
generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. =
I=E2=80=99ll stick with query params for simplicity in my sample.=20

=20

If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D =
then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:

=20

"p": [["a", "a"], "blah"]

=20

On the resource server, how do you know which key/value pair to put in =
which order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be consistent.

=20

Thanks.

=20

-Brock

=20

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

=20

=20


------=_NextPart_000_0070_01D17265.0C56BF10
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yea, I=E2=80=99m cool with =
just saying =E2=80=9Cduplicate keys won=E2=80=99t work=E2=80=9D for my =
implementation, unless I do some implementation specific thing like sort =
them by value order or some such (but that would have to be on both =
sides).
 
=

-Brock
=

 
=

From: =
Justin Richer [mailto:jricher@mit.edu] 
Sent: Sunday, February =
28, 2016 8:13 PM
To: Brock Allen =
<brockallen@gmail.com>
Cc: <oauth@ietf.org> =
<OAuth@ietf.org>
Subject: Re: [OAUTH-WG] HTTP request =
signing and repeated query/header keys
 
Yeah, =
that=E2=80=99s the trick =E2=80=94 you don=E2=80=99t want to end up =
replicating the entire HTTP message inside the JWS envelope, because =
then you end up with a SOAP kind of approach where you=E2=80=99re not =
really using the outside HTTP constructs to their fullest =
anymore. 
 
In the end, I don=E2=80=99t think this spec is ever =
going to be perfectly universal, but if it can hit a majority of use =
cases with a simple and robust solution, I think we=E2=80=99re in good =
shape.
 
 =E2=80=94 Justin
 
On Feb 28, 2016, at 1:50 PM, Brock Allen <brockallen@gmail.com> =
wrote:
 
Now =
that I=E2=80=99m thinking about this, the only thing that comes to mind =
is a hash of the value included somehow (which I=E2=80=99m sure =
you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case. =

 
=

-Brock
=

 
=

From: =
Brock Allen [mailto:brockallen@gmail.com] =

Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin =
Richer' <jricher@mit.edu>
Cc: =
'<oauth@ietf.org>' <OAuth@ietf.org>
Subject: =
RE: [OAUTH-WG] HTTP request signing and repeated query/header =
keys
 
Ok, =
missed that =E2=80=93 thanks.
 
=

For now in my =
implementation I=E2=80=99m also ignoring this problem =
:)
 
=

-Brock
=

 
=

From: =
Justin Richer [mailto:jricher@mit.edu] =

Sent: Sunday, February 28, 2016 4:37 PM
To: Brock =
Allen <brockallen@gmail.com>
C=
c: <oauth@ietf.org> =
<OAuth@ietf.org>
Subject: =
Re: [OAUTH-WG] HTTP request signing and repeated query/header =
keys
 
In =C2=A77.5 we currently =
have:
 
  =
 The behavior of repeated query parameters or repeated HTTP headers =
is
   undefined by this =
specification.  If a header or query parameter =
is
   repeated on either the outgoing =
request from the client or the
   =
incoming request to the protected resource, that query parameter =
or
   header name MUST NOT be covered by =
the hash and signature. [[ Note to
   the =
WG: is this something we need to cover? ]]
 
Which is to say: Yeah, that=E2=80=99s a problem, =
probably. We either declare this behavior out of scope and say you =
can=E2=80=99t use this method with that kind of API (or at least those =
parameters/headers) or we define a mechanism for handling that. =
I=E2=80=99m in favor of the former, and removing the text from the =
generation sections that says repeated parameters are processed with no =
special handling, making them explicitly out of scope =
throughout.
 
I would love to see more feedback from the group about =
this, especially if someone=E2=80=99s got a clever =
solution.
 
 =E2=80=94 =
Justin
 
On Feb 28, 2016, at 1:31 PM, Brock Allen <brockallen@gmail.com> =
wrote:
 
Given that the =
client can iterate over the query/headers in any order to generate the =
concatenated value to hash, I think there=E2=80=99s an issue with query =
string or header values with repeated keys. I=E2=80=99ll stick with =
query params for simplicity in my sample. =

 
If a =
client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D =
then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
 
"p": [["a", =
"a"], =
"blah"]
 
On the =
resource server, how do you know which key/value pair to put in which =
order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be =
consistent.
 
Thanks.
<=
div>
 
-Brock
 
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 








On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <samuel@erdtman.se> =
wrote:

+1 =
for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, =
Mike Jones <Michael.Jones@microsoft.com> wrote:









Thanks for your thoughts, Vladimir.  I=E2=80=99m=
 increasingly inclined to accept your suggestion to change the title =
from =E2=80=9COAuth 2.0 Discovery=E2=80=9D to =E2=80=9COAuth 2.0 =
Authorization
 Server Discovery=E2=80=9D.  While the abstract already makes it =
clear that the scope of the document is AS discovery, doing so in the =
title seems like it could help clarify things, given that a lot of the =
discussion seems to be about resource discovery, which is out
 of scope of the document.
 
I=E2=80=99m not saying that resource discovery =
isn=E2=80=99t important =E2=80=93 it is =E2=80=93 but unlike =
authorization server discovery, where there=E2=80=99s lots of existing =
practice, including
 using the existing data format for describing OAuth implementations =
that aren=E2=80=99t being used with OpenID Connect, there=E2=80=99s no =
existing practice to standardize for resource discovery.  The time =
to create a standard for that seems to be after existing practice
 has emerged.  It *might* or might not use new =
metadata values in the AS discovery document, but that=E2=80=99s still =
to be determined.  The one reason to leave the title as-is is that =
resource discovery might end up involving extensions to this metadata =
format
 in some cases.
 
I think an analogy to the core OAuth documents RFC =
6749 and RFC 6750 applies.  6749 is about the AS.  6750 is =
about the RS.  The discovery document is about the
 AS.  We don=E2=80=99t yet have a specification or existing =
practice for RS discovery, which would be the 6750 analogy.
 
In summary, which title do people prefer?
=C2=B7      
=E2=80=9COAuth 2.0 Discovery=E2=80=9D
=C2=B7      
=E2=80=9COAuth 2.0 Authorization Server =
Discovery=E2=80=9D
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 





From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Vladimir Dzhuvinov

Sent: Thursday, February 25, 2016 12:59 AM

To: oauth@ietf.org


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location





 
In OIDC the discovery doc is of great =
utility to developers and integrators. Developers also tend to find it a =
more accurate and complete description of how to set up a client for a =
particular deployment, compared
 to traditional online docs, which may be not be up to date, or even =
missing. Very much like auto-generated Swagger and JavaDocs.



Here are some example OIDC discovery docs:



https://accounts.google.com/.well-known/openid-configuration



https://www.paypalobjects.com/.well-known/openid-configuration<=
/a>



https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v=
2.0/.well-known/openid-configuration





With this discovery document in place setup of identity federation can =
then be easily scripted. For example:



http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_provid=
ers_create_oidc_verify-thumbprint.html





Now, does that dictate any particular app architecture? My reading of =
the spec is that it doesn't, and it shouldn't either. By staying neutral =
on the topics of RS discovery and registering RPs with RSs. And how one =
arrives at the ".well-known/...". I'm not
 even sure that resource discovery should be a topic of this WG. Perhaps =
to this end, and to prevent confusion that the spec is trying to do =
something more, a more specific title would suit it better. E.g. "AS =
Discovery".



Cheers,



Vladimir










On 25/02/16 02:25, Phil Hunt =
(IDM) wrote:






And so does oracle and so does google. Each different. =



 


So how can an app dictate it then unless we all go to a =
common architecture?


 


Phil


 




On Feb 24, 2016, at 16:04, Mike Jones <Michael.Jones@microsoft.com> wrote:


 


Azure defines ways for resource servers to be registered =
for use with a client and for clients to dynamically request an access =
token for use at a particular resource server.  You can call that =
custom architecture if you want.  It=E2=80=99s well-defined but =
it=E2=80=99s not currently in the standards realm.  I know that =
Google has syntax for doing the same, as I=E2=80=99m sure do a lot of =
other cloud OAuth deployments, such as Oracle=E2=80=99s.  For what =
it=E2=80=99s worth, the working group talked about possibly producing a =
standard version of syntax for making these kinds of requests during our =
discussions in Prague (during the Token Exchange discussion) but nobody =
has run with this yet.


 


In this sense, yes, Azure is an application of the kind =
we=E2=80=99re talking about.  Azure already does define specific =
new OAuth 2.0 discovery metadata values that are used in =
production.  A registry just doesn=E2=80=99t yet exist in which it =
can register those that are of general applicability.


 


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


 


From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 


Sent: Wednesday, February 24, 2016 3:52 PM


To: Mike Jones


Cc: <oauth@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


 


Mike


 


Take a look at the assumptions you are making. 


 


You seem to be assuming application software dictates =
oauth infrastructure architecture by suggesting that apps register in =
iana.  


 


Would ms azure allow custom arch?


 


Phil


 


On Feb 24, 2016, at 15:28, Mike Jones <Michael.Jones@microsoft.com> wrote:


 


The UserInfo Endpoint path isn=E2=80=99t fixed and so =
has to be discovered.


 


I agree that for some OAuth profiles, one or more =
resource servers will have to be discovered starting from the =
authorization server.  Working group members have also described =
wanting to discover authorization servers starting from resource =
servers.  There isn=E2=80=99t a standard practice for any of this, =
which is why it=E2=80=99s intentionally left out of the current =
specification.


 


Once the IANA OAuth Discovery Metadata Registry has been =
established, which will happen after the current specification has been =
approved, it will be easy for subsequent specifications to document =
existing practice for different OAuth profiles and register discovery =
metadata values supporting them.  Some of those values will likely =
define ways to discover resource servers, when applicable.


 


But first, we need to finish the existing spec, so that =
the registry enabling these extensions gets established in the first =
place.


 


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


 


From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 


Sent: Wednesday, February 24, 2016 2:13 PM


To: Mike Jones <Michael.Jones@microsoft.com>


Cc: <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


 


Yup. And because there many relations the client mist be =
able to discover it. The client does not know if the res server is =
legit. 


 


The userinfo is always fix and so u dont need discovery. =



 


Phil


 


On Feb 24, 2016, at 14:05, Mike Jones <Michael.Jones@microsoft.com> wrote:


 


In OpenID Connect, there=E2=80=99s a resource server =
called the UserInfo Endpoint that returns claims about the authenticated =
user as a JSON data structure.  Its location is published in OpenID =
Connect discovery metadata as the =E2=80=9Cuserinfo_endpoint=E2=80=9D =
metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#Provi=
derMetadata.


 


We didn=E2=80=99t include the UserInfo Endpoint in the =
generic OAuth discovery spec since in OAuth, there are lots of possible =
relationships between authorization servers and resource servers and =
they needn=E2=80=99t be one-to-one, as is being actively discussed by =
the working group.  For instance, see George Fletcher=E2=80=99s =
recent contribution.


 


Thanks for the good discussion, Phil.


 


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


 


From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 


Sent: Wednesday, February 24, 2016 1:25 PM


To: Mike Jones


Cc: <oauth@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


 


Where is the profile endpoint (oidc's resource server) =
published? (For the non OIDC people on the list). 


 


Phil


 


On Feb 24, 2016, at 13:09, Mike Jones <Michael.Jones@microsoft.com> wrote:


 


To the extent that generic OAuth 2.0 needs to publish =
some of the same information as OpenID Connect =E2=80=93 which is built =
on generic OAuth 2.0 =E2=80=93 it makes sense to publish that =
information using exactly the same syntax, since that syntax is already =
in widespread use.  That what this draft accomplishes.


 


There=E2=80=99s nothing Connect-specific about using =
metadata response values like:


 


   "authorization_endpoint": "https://server.example.com/authorize",


   "token_endpoint": "https://server.example.com/token",


   "token_endpoint_auth_methods_supported": =
["client_secret_basic", "private_key_jwt"],


   "registration_endpoint": "https://server.example.com/register",


   "response_types_supported":  ["code", =
"token"],


   "service_documentation": "http://server.example.com/service_documentation.html",


 


Is there a reason that you would like the syntax for any =
of these or the other generally applicable OAuth 2.0 metadata values to =
be different?  I don=E2=80=99t see any good reason for unnecessary =
differences to be introduced.


 


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


 


From: Phil Hunt (IDM) [mailto:phil.hunt@oracle.com] 


Sent: Wednesday, February 24, 2016 12:45 PM


To: Anthony Nadalin <tonynad@microsoft.com>


Cc: Mike Jones <Michael.Jones@microsoft.com>; <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


 


Mike


 


Publishing on dev pages does not work for software (esp =
open source) that is deployed both in enterprises and on PaaS cloud =
providers. 


 


The current draft is may codify current OIDC practice =
and be appropriate for oidc but it is not ready for generic oauth. There =
is no generic oauth experience at this time. 


 


Phil


 


On Feb 24, 2016, at 10:25, Anthony Nadalin <tonynad@microsoft.com> wrote:


 


Sure there is, it is as you have now made it far easier =
and the security considerations does not even address this


 


From: Mike Jones 


Sent: Wednesday, February 24, 2016 10:22 AM


To: Anthony Nadalin <tonynad@microsoft.com>


Cc: <oauth@ietf.org> <oauth@ietf.org>


Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location


 


As we=E2=80=99d discussed in person, there=E2=80=99s no =
effective security difference between discovery information being =
published in an ad-hoc fashion on developer pages and it being published =
in a standard format.  =E2=80=9CSecurity by obscurity=E2=80=9D adds =
no real security at all.


 


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


 


From: Anthony Nadalin 


Sent: Wednesday, February 24, 2016 10:01 AM


To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>


Cc: <oauth@ietf.org> <oauth@ietf.org>


Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location


 




The point of the WGLC is to finish standardizing the =
core discovery functionality that=E2=80=99s already widely deployed.




 


That may be widely deployed for OIDC but not widely =
deployed for OAuth. There are some authentication mechanism discovery =
for endpoint that really should not be in an OAuth standard since it=E2=80=
=99s really not dealt with. Now that all this information is available =
it makes poking around the endpoint more focused for people that want to =
disrupt your endpoints, that is really not addressed in the security =
considerations  section at all


 


From: OAuth [mailto:oauth-bounces@ietf.org] On =
Behalf Of Mike Jones


Sent: Wednesday, February 24, 2016 9:54 AM


To: Phil Hunt (IDM) <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>


Cc: <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


 


The point of the WGLC is to finish standardizing the =
core discovery functionality that=E2=80=99s already widely deployed.


 


None of Nat or John or I are suggesting that additional =
related functionality won=E2=80=99t be created.  I=E2=80=99m sure =
it will be.  Some applications will use WebFinger to locate the =
discovery metadata.  Some will possibly use link headers.  =
Some will possibly use application-specific .well-known values.  =
I=E2=80=99m sure there=E2=80=99s other things I haven=E2=80=99t even =
thought about.  All of these depend upon having a discovery =
metadata document format and none of them change it =E2=80=93 other than =
possibly to register additional discovery metadata values.


 


So by all means, the working group should continue =
discussing inventing possible new related mechanisms that make sense in =
some contexts.  At the same time, we can finish standardizing the =
already widely deployed core functionality that all of these mechanisms =
will need.


 


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


 


From: OAuth [mailto:oauth-bounces@ietf.org] On =
Behalf Of Phil Hunt (IDM)


Sent: Wednesday, February 24, 2016 8:39 AM


To: Nat Sakimura <sakimura@gmail.com>


Cc: <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


 


I am suggesting that part of the discovery solution has =
to be the client indicating what resource endpoint it wants the oauth =
configuration data for. 


 


So if res.example.evil.com is not a valid =
resource endpoint for as.example.com the authz discovery should fail in some =
way (eg return nothing). 


 


There may be better ways to do this. Eg combine =
discovery. Or change the order of discovery. 


 


One of OAuth's strength's and weaknesses is that the =
target of authorization (the resource) is never specified. It is often =
bound up in the client registration and an often implied 1:1 =
relationship between resource and as. Given that in discovery phase =
registration has not yet occurred it seems important that the client =
know it has a valid combination of endpoints etc. 


 


This is why I was disappointed about wglc on discovery. =
We had a starting point for group adoption but we haven't really defined =
the full requirements IMO. 


 


I am on vacation or I would put some thought into some =
draft changes or a new draft. I apologize I can't do it now. 


 


Phil


 


On Feb 24, 2016, at 08:12, Nat Sakimura <sakimura@gmail.com> wrote:


 


Hi Phil, 


 


Are you suggesting that the AS metadata should include =
the RS URIs? Currently, it does not, but it can be done, I guess. 


 


The way oauth-meta works is that 


 


1. RS tells the client where the AS is. 


2. AS tells the client which RS endpoints the token can =
be used. 


 


Even if there is a bad AS with a valid certs that =
proxies to the good RS, the client will not send the token there as the =
authz server will say that is not the place the client may want to send =
the token to. 


 


Nat


 


2016=E5=B9=B42=E6=9C=8824=E6=97=A5(=E6=B0=B4) 23:59 Phil Hunt <phil.hunt@oracle.com>:


Nat,


 


I=E2=80=99m not sure that having the resource server =
tell the client where its authorization server is secure by itself. The =
relationship between the Authorization Server and the Resource server =
need to be bound together in one of the discovery endpoints (the =
resource and/or the oauth service discovery).


 


If a client discovers a fake resource server that is =
proxying for a real resource server the current discovery spec will not =
lead the client to understand it has the wrong resource server. Rather =
the fake resource service will just have a fake discovery service. The =
hacker can now intercept resource payload as well as tokens because they =
were able to convince the client to use the legit authorization service =
but use the token against the hackers proxy.


 


The OAuth Discovery service needs to confirm to the =
client that the server is able to issue tokens for a stated resource =
endpoint.


 


This not only works in normal OAuth but should add =
security even to UMA situations.
=


 


Phil


 


@independentid


www.independentid.com


phil.hunt@oracle.com


 


 


 


 


 


On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com> wrote:


 


 


Hi Thomas, 


 


inline: 


 


2016=E5=B9=B42=E6=9C=8822=E6=97=A5(=E6=9C=88) 18:44 Thomas Broyer <t.broyer@gmail.com>:


Couldn't the document only describe the metadata?


I quite like the idea of draft-sakimura-oauth-meta if =
you really want to do discovery, and leave it open to implementers / to =
other specs to define a .well-known URL for "auto-configuration".


The metadata described here would then either be used =
as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the =
RS; or as a basis for other metadata specs (like OpenID Connect). 


With draft-sakimura-oauth-meta's "duri" and the "scope" =
attribute of WWW-Authenticate response header, you have everything you =
need to proceed 


 


Yup. That's one of the requirements to be RESTful, is it =
not?  


 


In OAuth's case, the resource and the authorization =
server are usually tightly coupled. (Otherwise, you need another specs =
like UMA.) 


So, the resource server should be able to tell either =
the location of the authz endpoint. In some trusted environment, the =
resource may as well return the location of the authz server =
configuration data. In these cases, you do not have to decide on what =
.well-known uri as you say. This frees up developers from configuration =
file location collisions etc. We should strive not to pollute the uri =
space as much as possible. 


 


(well, except if there are several ASs each with =
different scopes; sounds like an edge-case to me though; maybe RFC6750 =
should instead be updated with such a parameter such that an RS could =
return several WWW-Authenticate: Bearer, each with its own "scope" and =
"duri" value?)


 


Yeah, I guess it is an edge case. I would rather like to =
see these authz servers to develop a trust framework under which they =
can agree on a single set of common scope parameter values. 


 


Cheers, 


 


Nat


 


 


 


On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:


The newly-trimmed OAuth Discovery document is helpful =
and moving in the right direction. It does, however, still have too many =
vestiges of its OpenID Connect origins. One issue in particular still =
really bothers me: the use of =E2=80=9C/.well-known/openid-configuration=E2=
=80=9D in the discovery portion. Is this an OAuth discovery document, or =
an OpenID Connect one? There is absolutely no compelling reason to tie =
the URL to the OIDC discovery mechanism.


 


I propose that we use =
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D as the default =
discovery location, and state that the document MAY also be reachable =
from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server =
also provides OpenID Connect on the same domain. Other applications =
SHOULD use the same parameter names to describe OAuth endpoints and =
functions inside their service-specific discovery document.


 


 =E2=80=94 Justin


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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




 









_______________________________________________


OAuth mailing list


OAuth@ietf.org


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









-- 


Vladimir Dzhuvinov :: vladimir@connect2id.com







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




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

<=
/blockquote>
 

------=_NextPart_000_0070_01D17265.0C56BF10--


From nobody Sun Feb 28 18:39:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BEB1B2A57 for ; Sun, 28 Feb 2016 18:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=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 2ts45blmBAbp for ; Sun, 28 Feb 2016 18:39:35 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6491B2A50 for ; Sun, 28 Feb 2016 18:39:34 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,518,1449493200"; d="scan'208,217"; a="62247624"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 29 Feb 2016 13:39:33 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8089"; a="110692505"
Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbvi.tcif.telstra.com.au with ESMTP; 29 Feb 2016 13:39:32 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([fe80::8dc9:173:3b72:6577%23]) with mapi; Mon, 29 Feb 2016 13:39:32 +1100
From: "Manger, James" 
To: Brock Allen , 'Justin Richer' 
Date: Mon, 29 Feb 2016 13:39:31 +1100
Thread-Topic: [OAUTH-WG] HTTP request signing and repeated query/header keys
Thread-Index: AQFXkD4wUaeZYzbNhPIxfaFoz/BUGADRFDTHAaJuhE4B7FuyY6AS/gDAgAAS31A=
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBCD3D02F@WSMSG3153V.srv.dir.telstra.com>
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> <005401d17272$070325a0$150970e0$@gmail.com> <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu> <006f01d1728e$f52af250$df80d6f0$@gmail.com>
In-Reply-To: <006f01d1728e$f52af250$df80d6f0$@gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBCD3D02FWSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: 
Cc: "''" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 02:39:38 -0000

--_000_255B9BB34FB7D647A506DC292726F6E13BBCD3D02FWSMSG3153Vsrv_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QmVpbmcgYWJsZSB0byBzZWxlY3RpdmVseSBpbmNsdWRlIG9yIGV4Y2x1ZGUgaW5kaXZpZHVhbCBx
dWVyeSBzdHJpbmcgbmFtZT12YWx1ZSBwYXJhbWV0ZXJzIGluIGEgc2lnbmF0dXJlIGZlZWxzIGZh
ciB0b28gZGFuZ2Vyb3VzLiBBbHdheXMgc2lnbiB0aGVtIGFsbCDigJQgd2l0aCB0aGUgb25seSBl
eGNlcHRpb24gYmVpbmcgdGhlIHNpZ25hdHVyZSBpdHNlbGYgaWYgdHJhbnNtaXR0ZWQgYXMgYSBx
dWVyeSBzdHJpbmcgcGFyYW1ldGVyLg0KVW5mb3J0dW5hdGVseSB3ZSBkbyBuZWVkIHRvIHNlbGVj
dGl2ZWx5IGluY2x1ZGUgb3IgZXhjbHVkZSBIVFRQIGhlYWRlcnMgYXMgdGhleSBhcmUgYSBtaXgg
b2YgdHJhbnNwb3J0LCBhcHAtbGF5ZXIsIGVuZC10by1lbmQsIGFuZCBob3AtYnktaG9wIGl0ZW1z
Lg0KDQpJZ25vcmluZyBkdXBsaWNhdGUgcXVlcnkgcGFyYW1ldGVyIG5hbWVzIGlzIGEgcG9vciBk
ZXNpZ24gZm9yIGEgZmFpcmx5IGdlbmVyaWMgSFRUUCBzaWduaW5nIG1ldGhvZC4gTXkgc3VnZ2Vz
dGlvbiB3b3VsZCBiZSB0byBkbyBhIHN0YWJsZSBzb3J0IG9uIHBhcmFtZXRlciBuYW1lcy4gVGhh
dCBpcywgc29ydCB0aGUgbmFtZXMsIGJ1dCBwcmVzZXJ2ZSB0aGUgb3JkZXIgb2YgdmFsdWVzIHdo
ZW4gYSBuYW1lIGFwcGVhcnMgbXVsdGlwbGUgdGltZXMuIOKApmhvcGluZyB0aGF0IHdvcmtzIHdp
dGggYWxtb3N0IGFsbCBmcmFtZXdvcmtzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IE9B
dXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyb2NrIEFs
bGVuDQpTZW50OiBNb25kYXksIDI5IEZlYnJ1YXJ5IDIwMTYgMTI6MTcgUE0NClRvOiAnSnVzdGlu
IFJpY2hlcicgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiAnPG9hdXRoQGlldGYub3JnPicgPE9BdXRo
QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSFRUUCByZXF1ZXN0IHNpZ25pbmcg
YW5kIHJlcGVhdGVkIHF1ZXJ5L2hlYWRlciBrZXlzDQoNClllYSwgSeKAmW0gY29vbCB3aXRoIGp1
c3Qgc2F5aW5nIOKAnGR1cGxpY2F0ZSBrZXlzIHdvbuKAmXQgd29ya+KAnSBmb3IgbXkgaW1wbGVt
ZW50YXRpb24sIHVubGVzcyBJIGRvIHNvbWUgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgdGhpbmcg
bGlrZSBzb3J0IHRoZW0gYnkgdmFsdWUgb3JkZXIgb3Igc29tZSBzdWNoIChidXQgdGhhdCB3b3Vs
ZCBoYXZlIHRvIGJlIG9uIGJvdGggc2lkZXMpLg0KDQotQnJvY2sNCg0KRnJvbTogSnVzdGluIFJp
Y2hlciBbbWFpbHRvOmpyaWNoZXJAbWl0LmVkdV0NClNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMjgs
IDIwMTYgODoxMyBQTQ0KVG86IEJyb2NrIEFsbGVuIDxicm9ja2FsbGVuQGdtYWlsLmNvbTxtYWls
dG86YnJvY2thbGxlbkBnbWFpbC5jb20+Pg0KQ2M6IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1
dGhAaWV0Zi5vcmc+PiA8T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPj4NClN1
YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEhUVFAgcmVxdWVzdCBzaWduaW5nIGFuZCByZXBlYXRlZCBx
dWVyeS9oZWFkZXIga2V5cw0KDQpZZWFoLCB0aGF04oCZcyB0aGUgdHJpY2sg4oCUIHlvdSBkb27i
gJl0IHdhbnQgdG8gZW5kIHVwIHJlcGxpY2F0aW5nIHRoZSBlbnRpcmUgSFRUUCBtZXNzYWdlIGlu
c2lkZSB0aGUgSldTIGVudmVsb3BlLCBiZWNhdXNlIHRoZW4geW91IGVuZCB1cCB3aXRoIGEgU09B
UCBraW5kIG9mIGFwcHJvYWNoIHdoZXJlIHlvdeKAmXJlIG5vdCByZWFsbHkgdXNpbmcgdGhlIG91
dHNpZGUgSFRUUCBjb25zdHJ1Y3RzIHRvIHRoZWlyIGZ1bGxlc3QgYW55bW9yZS4NCg0KSW4gdGhl
IGVuZCwgSSBkb27igJl0IHRoaW5rIHRoaXMgc3BlYyBpcyBldmVyIGdvaW5nIHRvIGJlIHBlcmZl
Y3RseSB1bml2ZXJzYWwsIGJ1dCBpZiBpdCBjYW4gaGl0IGEgbWFqb3JpdHkgb2YgdXNlIGNhc2Vz
IHdpdGggYSBzaW1wbGUgYW5kIHJvYnVzdCBzb2x1dGlvbiwgSSB0aGluayB3ZeKAmXJlIGluIGdv
b2Qgc2hhcGUuDQoNCiDigJQgSnVzdGluDQoNCk9uIEZlYiAyOCwgMjAxNiwgYXQgMTo1MCBQTSwg
QnJvY2sgQWxsZW4gPGJyb2NrYWxsZW5AZ21haWwuY29tPG1haWx0bzpicm9ja2FsbGVuQGdtYWls
LmNvbT4+IHdyb3RlOg0KDQpOb3cgdGhhdCBJ4oCZbSB0aGlua2luZyBhYm91dCB0aGlzLCB0aGUg
b25seSB0aGluZyB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgYSBoYXNoIG9mIHRoZSB2YWx1ZSBpbmNs
dWRlZCBzb21laG93ICh3aGljaCBJ4oCZbSBzdXJlIHlvdeKAmXZlIGFscmVhZHkgdGhvdWdodCBv
ZikuIFRoYXTigJlzIG9idmlvdXNseSBtb3JlIGNvbXBsZXhpdHkgYW5kIG92ZXJoZWFkIGZvciBh
bGwgc2NlbmFyaW9zIHRvIHN1cHBvcnQgdGhpcyBlZGdlIGNhc2UuDQoNCi1Ccm9jaw0KDQpGcm9t
OiBCcm9jayBBbGxlbiBbbWFpbHRvOmJyb2NrYWxsZW5AZ21haWwuY29tXQ0KU2VudDogU3VuZGF5
LCBGZWJydWFyeSAyOCwgMjAxNiA0OjQwIFBNDQpUbzogJ0p1c3RpbiBSaWNoZXInIDxqcmljaGVy
QG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+DQpDYzogJzxvYXV0aEBpZXRmLm9yZzxt
YWlsdG86b2F1dGhAaWV0Zi5vcmc+PicgPE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4+DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBIVFRQIHJlcXVlc3Qgc2lnbmluZyBhbmQg
cmVwZWF0ZWQgcXVlcnkvaGVhZGVyIGtleXMNCg0KT2ssIG1pc3NlZCB0aGF0IOKAkyB0aGFua3Mu
DQoNCkZvciBub3cgaW4gbXkgaW1wbGVtZW50YXRpb24gSeKAmW0gYWxzbyBpZ25vcmluZyB0aGlz
IHByb2JsZW0gOikNCg0KLUJyb2NrDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmlj
aGVyQG1pdC5lZHVdDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDI4LCAyMDE2IDQ6MzcgUE0NClRv
OiBCcm9jayBBbGxlbiA8YnJvY2thbGxlbkBnbWFpbC5jb208bWFpbHRvOmJyb2NrYWxsZW5AZ21h
aWwuY29tPj4NCkNjOiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4gPE9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI
LVdHXSBIVFRQIHJlcXVlc3Qgc2lnbmluZyBhbmQgcmVwZWF0ZWQgcXVlcnkvaGVhZGVyIGtleXMN
Cg0KSW4gwqc3LjUgd2UgY3VycmVudGx5IGhhdmU6DQoNCg0KICAgVGhlIGJlaGF2aW9yIG9mIHJl
cGVhdGVkIHF1ZXJ5IHBhcmFtZXRlcnMgb3IgcmVwZWF0ZWQgSFRUUCBoZWFkZXJzIGlzDQoNCiAg
IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24uICBJZiBhIGhlYWRlciBvciBxdWVyeSBw
YXJhbWV0ZXIgaXMNCg0KICAgcmVwZWF0ZWQgb24gZWl0aGVyIHRoZSBvdXRnb2luZyByZXF1ZXN0
IGZyb20gdGhlIGNsaWVudCBvciB0aGUNCg0KICAgaW5jb21pbmcgcmVxdWVzdCB0byB0aGUgcHJv
dGVjdGVkIHJlc291cmNlLCB0aGF0IHF1ZXJ5IHBhcmFtZXRlciBvcg0KDQogICBoZWFkZXIgbmFt
ZSBNVVNUIE5PVCBiZSBjb3ZlcmVkIGJ5IHRoZSBoYXNoIGFuZCBzaWduYXR1cmUuIFtbIE5vdGUg
dG8NCg0KICAgdGhlIFdHOiBpcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIGNvdmVyPyBdXQ0K
DQpXaGljaCBpcyB0byBzYXk6IFllYWgsIHRoYXTigJlzIGEgcHJvYmxlbSwgcHJvYmFibHkuIFdl
IGVpdGhlciBkZWNsYXJlIHRoaXMgYmVoYXZpb3Igb3V0IG9mIHNjb3BlIGFuZCBzYXkgeW91IGNh
buKAmXQgdXNlIHRoaXMgbWV0aG9kIHdpdGggdGhhdCBraW5kIG9mIEFQSSAob3IgYXQgbGVhc3Qg
dGhvc2UgcGFyYW1ldGVycy9oZWFkZXJzKSBvciB3ZSBkZWZpbmUgYSBtZWNoYW5pc20gZm9yIGhh
bmRsaW5nIHRoYXQuIEnigJltIGluIGZhdm9yIG9mIHRoZSBmb3JtZXIsIGFuZCByZW1vdmluZyB0
aGUgdGV4dCBmcm9tIHRoZSBnZW5lcmF0aW9uIHNlY3Rpb25zIHRoYXQgc2F5cyByZXBlYXRlZCBw
YXJhbWV0ZXJzIGFyZSBwcm9jZXNzZWQgd2l0aCBubyBzcGVjaWFsIGhhbmRsaW5nLCBtYWtpbmcg
dGhlbSBleHBsaWNpdGx5IG91dCBvZiBzY29wZSB0aHJvdWdob3V0Lg0KDQpJIHdvdWxkIGxvdmUg
dG8gc2VlIG1vcmUgZmVlZGJhY2sgZnJvbSB0aGUgZ3JvdXAgYWJvdXQgdGhpcywgZXNwZWNpYWxs
eSBpZiBzb21lb25l4oCZcyBnb3QgYSBjbGV2ZXIgc29sdXRpb24uDQoNCiDigJQgSnVzdGluDQoN
Ck9uIEZlYiAyOCwgMjAxNiwgYXQgMTozMSBQTSwgQnJvY2sgQWxsZW4gPGJyb2NrYWxsZW5AZ21h
aWwuY29tPG1haWx0bzpicm9ja2FsbGVuQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpHaXZlbiB0aGF0
IHRoZSBjbGllbnQgY2FuIGl0ZXJhdGUgb3ZlciB0aGUgcXVlcnkvaGVhZGVycyBpbiBhbnkgb3Jk
ZXIgdG8gZ2VuZXJhdGUgdGhlIGNvbmNhdGVuYXRlZCB2YWx1ZSB0byBoYXNoLCBJIHRoaW5rIHRo
ZXJl4oCZcyBhbiBpc3N1ZSB3aXRoIHF1ZXJ5IHN0cmluZyBvciBoZWFkZXIgdmFsdWVzIHdpdGgg
cmVwZWF0ZWQga2V5cy4gSeKAmWxsIHN0aWNrIHdpdGggcXVlcnkgcGFyYW1zIGZvciBzaW1wbGlj
aXR5IGluIG15IHNhbXBsZS4NCg0KSWYgYSBjbGllbnQgc2lnbnMgdGhpcyBjb25jYXRlbmF0ZWQg
cXVlcnk6IOKAnGE9MSZhPTLigJ0gdGhlbiB0aGUg4oCccOKAnSB2YWx1ZSBpbiB0aGUgc2lnbmVk
IEpTT04gb2JqZWN0IGNvdWxkIGJlIHRoaXM6DQoNCiJwIjogW1siYSIsICJhIl0sICJibGFoIl0N
Cg0KT24gdGhlIHJlc291cmNlIHNlcnZlciwgaG93IGRvIHlvdSBrbm93IHdoaWNoIGtleS92YWx1
ZSBwYWlyIHRvIHB1dCBpbiB3aGljaCBvcmRlciBmb3IgdmVyaWZpY2F0aW9uPyBBbHNvLCBnaXZl
biB0aGF0IGRpZmZlcmVudCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGV4cHJlc3MgdGhlc2UgaW5j
b21pbmcgcGFyYW1ldGVycyBpbiBkaWZmZXJlbnQgd2F5cywgaXQgc2VlbXMgcHJvYmxlbWF0aWMg
dG8gYmUgY29uc2lzdGVudC4NCg0KVGhhbmtzLg0KDQotQnJvY2sNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1
dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg==

--_000_255B9BB34FB7D647A506DC292726F6E13BBCD3D02FWSMSG3153Vsrv_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz
IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h
bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN
CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh
cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u
dC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz
cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eTpDb25zb2xhczsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOiM5OTMz
NjY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u
dC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6IzAwMzMwMDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw
dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o
ZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPjxkaXYg
Y2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+QmVpbmcgYWJsZSB0byBzZWxlY3Rp
dmVseSBpbmNsdWRlIG9yIGV4Y2x1ZGUgaW5kaXZpZHVhbCBxdWVyeSBzdHJpbmcgbmFtZT12YWx1
ZSBwYXJhbWV0ZXJzIGluIGEgc2lnbmF0dXJlIGZlZWxzIGZhciB0b28gZGFuZ2Vyb3VzLiBBbHdh
eXMgc2lnbiB0aGVtIGFsbCDigJQgd2l0aCB0aGUgb25seSBleGNlcHRpb24gYmVpbmcgdGhlIHNp
Z25hdHVyZSBpdHNlbGYgaWYgdHJhbnNtaXR0ZWQgYXMgYSBxdWVyeSBzdHJpbmcgcGFyYW1ldGVy
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPlVuZm9ydHVuYXRlbHkgd2Ug
ZG8gbmVlZCB0byBzZWxlY3RpdmVseSBpbmNsdWRlIG9yIGV4Y2x1ZGUgSFRUUCBoZWFkZXJzIGFz
IHRoZXkgYXJlIGEgbWl4IG9mIHRyYW5zcG9ydCwgYXBwLWxheWVyLCBlbmQtdG8tZW5kLCBhbmQg
aG9wLWJ5LWhvcCBpdGVtcy4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+SWdub3JpbmcgZHVw
bGljYXRlIHF1ZXJ5IHBhcmFtZXRlciBuYW1lcyBpcyBhIHBvb3IgZGVzaWduIGZvciBhIGZhaXJs
eSBnZW5lcmljIEhUVFAgc2lnbmluZyBtZXRob2QuIE15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8g
ZG8gYSBzdGFibGUgc29ydCBvbiBwYXJhbWV0ZXIgbmFtZXMuIFRoYXQgaXMsIHNvcnQgdGhlIG5h
bWVzLCBidXQgcHJlc2VydmUgdGhlIG9yZGVyIG9mIHZhbHVlcyB3aGVuIGEgbmFtZSBhcHBlYXJz
IG11bHRpcGxlIHRpbWVzLiDigKZob3BpbmcgdGhhdCB3b3JrcyB3aXRoIGFsbW9zdCBhbGwgZnJh
bWV3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9
J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUz5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUz4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyb2NrIEFsbGVuPGJyPjxiPlNlbnQ6PC9i
PiBNb25kYXksIDI5IEZlYnJ1YXJ5IDIwMTYgMTI6MTcgUE08YnI+PGI+VG86PC9iPiAnSnVzdGlu
IFJpY2hlcicgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+PGI+Q2M6PC9iPiAnJmx0O29hdXRo
QGlldGYub3JnJmd0OycgJmx0O09BdXRoQGlldGYub3JnJmd0Ozxicj48Yj5TdWJqZWN0OjwvYj4g
UmU6IFtPQVVUSC1XR10gSFRUUCByZXF1ZXN0IHNpZ25pbmcgYW5kIHJlcGVhdGVkIHF1ZXJ5L2hl
YWRlciBrZXlzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F
Ti1VUyBzdHlsZT0nZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzAwMzMwMCc+WWVhLCBJ4oCZ
bSBjb29sIHdpdGgganVzdCBzYXlpbmcg4oCcZHVwbGljYXRlIGtleXMgd29u4oCZdCB3b3Jr4oCd
IGZvciBteSBpbXBsZW1lbnRhdGlvbiwgdW5sZXNzIEkgZG8gc29tZSBpbXBsZW1lbnRhdGlvbiBz
cGVjaWZpYyB0aGluZyBsaWtlIHNvcnQgdGhlbSBieSB2YWx1ZSBvcmRlciBvciBzb21lIHN1Y2gg
KGJ1dCB0aGF0IHdvdWxkIGhhdmUgdG8gYmUgb24gYm90aCBzaWRlcykuPG86cD48L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZh
bWlseTpDb25zb2xhcztjb2xvcjojMDAzMzAwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1p
bHk6Q29uc29sYXM7Y29sb3I6IzAwMzMwMCc+LUJyb2NrPG86cD48L286cD48L3NwYW4+PC9wPjwv
ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWls
eTpDb25zb2xhcztjb2xvcjojMDAzMzAwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp
dj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxh
bmc9RU4tVVM+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVM+IEp1c3RpbiBSaWNoZXIg
WzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiPm1haWx0bzpqcmljaGVyQG1pdC5lZHU8
L2E+XSA8YnI+PGI+U2VudDo8L2I+IFN1bmRheSwgRmVicnVhcnkgMjgsIDIwMTYgODoxMyBQTTxi
cj48Yj5Ubzo8L2I+IEJyb2NrIEFsbGVuICZsdDs8YSBocmVmPSJtYWlsdG86YnJvY2thbGxlbkBn
bWFpbC5jb20iPmJyb2NrYWxsZW5AZ21haWwuY29tPC9hPiZndDs8YnI+PGI+Q2M6PC9iPiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7ICZs
dDs8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8
YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEhUVFAgcmVxdWVzdCBzaWduaW5nIGFu
ZCByZXBlYXRlZCBxdWVyeS9oZWFkZXIga2V5czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48
L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+WWVhaCwgdGhh
dOKAmXMgdGhlIHRyaWNrIOKAlCB5b3UgZG9u4oCZdCB3YW50IHRvIGVuZCB1cCByZXBsaWNhdGlu
ZyB0aGUgZW50aXJlIEhUVFAgbWVzc2FnZSBpbnNpZGUgdGhlIEpXUyBlbnZlbG9wZSwgYmVjYXVz
ZSB0aGVuIHlvdSBlbmQgdXAgd2l0aCBhIFNPQVAga2luZCBvZiBhcHByb2FjaCB3aGVyZSB5b3Xi
gJlyZSBub3QgcmVhbGx5IHVzaW5nIHRoZSBvdXRzaWRlIEhUVFAgY29uc3RydWN0cyB0byB0aGVp
ciBmdWxsZXN0IGFueW1vcmUuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv
bnQtc2l6ZToxMi4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48
ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPkluIHRoZSBlbmQsIEkgZG9u
4oCZdCB0aGluayB0aGlzIHNwZWMgaXMgZXZlciBnb2luZyB0byBiZSBwZXJmZWN0bHkgdW5pdmVy
c2FsLCBidXQgaWYgaXQgY2FuIGhpdCBhIG1ham9yaXR5IG9mIHVzZSBjYXNlcyB3aXRoIGEgc2lt
cGxlIGFuZCByb2J1c3Qgc29sdXRpb24sIEkgdGhpbmsgd2XigJlyZSBpbiBnb29kIHNoYXBlLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs
YW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBsYW5nPUVOLVVTPk9uIEZlYiAyOCwgMjAxNiwgYXQgMTo1MCBQTSwgQnJvY2sgQWxsZW4g
Jmx0OzxhIGhyZWY9Im1haWx0bzpicm9ja2FsbGVuQGdtYWlsLmNvbSI+YnJvY2thbGxlbkBnbWFp
bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk
aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm
b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojOTkzMzY2Jz5Ob3cgdGhhdCBJ4oCZbSB0aGlua2lu
ZyBhYm91dCB0aGlzLCB0aGUgb25seSB0aGluZyB0aGF0IGNvbWVzIHRvIG1pbmQgaXMgYSBoYXNo
IG9mIHRoZSB2YWx1ZSBpbmNsdWRlZCBzb21laG93ICh3aGljaCBJ4oCZbSBzdXJlIHlvdeKAmXZl
IGFscmVhZHkgdGhvdWdodCBvZikuIFRoYXTigJlzIG9idmlvdXNseSBtb3JlIGNvbXBsZXhpdHkg
YW5kIG92ZXJoZWFkIGZvciBhbGwgc2NlbmFyaW9zIHRvIHN1cHBvcnQgdGhpcyBlZGdlIGNhc2Uu
IDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpD
b25zb2xhcztjb2xvcjojOTkzMzY2Jz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojOTkzMzY2Jz4t
QnJvY2s8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+
PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u
dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Izk5MzM2Nic+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9
RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj
bSAwY20nPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVM+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVM+IEJyb2NrIEFsbGVuIFs8YSBocmVmPSJtYWlsdG86
YnJvY2thbGxlbkBnbWFpbC5jb20iPm1haWx0bzpicm9ja2FsbGVuQGdtYWlsLmNvbTwvYT5dIDxi
cj48Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAyOCwgMjAxNiA0OjQwIFBNPGJyPjxiPlRv
OjwvYj4gJ0p1c3RpbiBSaWNoZXInICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1
Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozxicj48Yj5DYzo8L2I+ICcmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7JyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxiPlN1Ympl
Y3Q6PC9iPiBSRTogW09BVVRILVdHXSBIVFRQIHJlcXVlc3Qgc2lnbmluZyBhbmQgcmVwZWF0ZWQg
cXVlcnkvaGVhZGVyIGtleXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V
UyBzdHlsZT0nZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCc+T2ssIG1pc3NlZCB0
aGF0IOKAkyB0aGFua3MuPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9
J2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs
YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj
MUY0OTdEJz5Gb3Igbm93IGluIG15IGltcGxlbWVudGF0aW9uIEnigJltIGFsc28gaWdub3Jpbmcg
dGhpcyBwcm9ibGVtIDopPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9
J2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs
YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv
bG9yOiMxRjQ5N0QnPi1Ccm9jazwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO
LVVTIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw
YW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2
IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwY20gMGNtIDBjbSc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFu
Zz1FTi1VUz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUz4gSnVzdGluIFJpY2hlciBb
PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+bWFpbHRvOmpyaWNoZXJAbWl0LmVkdTwv
YT5dIDxicj48Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAyOCwgMjAxNiA0OjM3IFBNPGJy
PjxiPlRvOjwvYj4gQnJvY2sgQWxsZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicm9ja2FsbGVuQGdt
YWlsLmNvbSI+YnJvY2thbGxlbkBnbWFpbC5jb208L2E+Jmd0Ozxicj48Yj5DYzo8L2I+ICZsdDs8
YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDsgJmx0
OzxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxi
cj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSFRUUCByZXF1ZXN0IHNpZ25pbmcgYW5k
IHJlcGVhdGVkIHF1ZXJ5L2hlYWRlciBrZXlzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv
ZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IGxhbmc9RU4tVVM+SW4gwqc3LjUgd2UgY3VycmVudGx5IGhhdmU6PG86cD48L286cD48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cHJlPjxzcGFuIGxh
bmc9RU4tVVM+Jm5ic3A7Jm5ic3A7IFRoZSBiZWhhdmlvciBvZiByZXBlYXRlZCBxdWVyeSBwYXJh
bWV0ZXJzIG9yIHJlcGVhdGVkIEhUVFAgaGVhZGVycyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
PjxwcmU+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsgdW5kZWZpbmVkIGJ5IHRoaXMgc3Bl
Y2lmaWNhdGlvbi4mbmJzcDsgSWYgYSBoZWFkZXIgb3IgcXVlcnkgcGFyYW1ldGVyIGlzPG86cD48
L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyByZXBl
YXRlZCBvbiBlaXRoZXIgdGhlIG91dGdvaW5nIHJlcXVlc3QgZnJvbSB0aGUgY2xpZW50IG9yIHRo
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDsmbmJz
cDsgaW5jb21pbmcgcmVxdWVzdCB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNlLCB0aGF0IHF1ZXJ5
IHBhcmFtZXRlciBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1V
Uz4mbmJzcDsmbmJzcDsgaGVhZGVyIG5hbWUgTVVTVCBOT1QgYmUgY292ZXJlZCBieSB0aGUgaGFz
aCBhbmQgc2lnbmF0dXJlLiBbWyBOb3RlIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48
c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyB0aGUgV0c6IGlzIHRoaXMgc29tZXRoaW5nIHdl
IG5lZWQgdG8gY292ZXI/IF1dPG86cD48L286cD48L3NwYW4+PC9wcmU+PGRpdj48ZGl2PjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t
VVM+V2hpY2ggaXMgdG8gc2F5OiBZZWFoLCB0aGF04oCZcyBhIHByb2JsZW0sIHByb2JhYmx5LiBX
ZSBlaXRoZXIgZGVjbGFyZSB0aGlzIGJlaGF2aW9yIG91dCBvZiBzY29wZSBhbmQgc2F5IHlvdSBj
YW7igJl0IHVzZSB0aGlzIG1ldGhvZCB3aXRoIHRoYXQga2luZCBvZiBBUEkgKG9yIGF0IGxlYXN0
IHRob3NlIHBhcmFtZXRlcnMvaGVhZGVycykgb3Igd2UgZGVmaW5lIGEgbWVjaGFuaXNtIGZvciBo
YW5kbGluZyB0aGF0LiBJ4oCZbSBpbiBmYXZvciBvZiB0aGUgZm9ybWVyLCBhbmQgcmVtb3Zpbmcg
dGhlIHRleHQgZnJvbSB0aGUgZ2VuZXJhdGlvbiBzZWN0aW9ucyB0aGF0IHNheXMgcmVwZWF0ZWQg
cGFyYW1ldGVycyBhcmUgcHJvY2Vzc2VkIHdpdGggbm8gc3BlY2lhbCBoYW5kbGluZywgbWFraW5n
IHRoZW0gZXhwbGljaXRseSBvdXQgb2Ygc2NvcGUgdGhyb3VnaG91dC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n
PUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SSB3b3VsZCBsb3ZlIHRvIHNlZSBt
b3JlIGZlZWRiYWNrIGZyb20gdGhlIGdyb3VwIGFib3V0IHRoaXMsIGVzcGVjaWFsbHkgaWYgc29t
ZW9uZeKAmXMgZ290IGEgY2xldmVyIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp
dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3Nw
YW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu
Zz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48YmxvY2txdW90
ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+T24gRmViIDI4LCAyMDE2LCBhdCAx
OjMxIFBNLCBCcm9jayBBbGxlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyb2NrYWxsZW5AZ21haWwu
Y29tIj5icm9ja2FsbGVuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48ZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpDb25z
b2xhcyc+R2l2ZW4gdGhhdCB0aGUgY2xpZW50IGNhbiBpdGVyYXRlIG92ZXIgdGhlIHF1ZXJ5L2hl
YWRlcnMgaW4gYW55IG9yZGVyIHRvIGdlbmVyYXRlIHRoZSBjb25jYXRlbmF0ZWQgdmFsdWUgdG8g
aGFzaCwgSSB0aGluayB0aGVyZeKAmXMgYW4gaXNzdWUgd2l0aCBxdWVyeSBzdHJpbmcgb3IgaGVh
ZGVyIHZhbHVlcyB3aXRoIHJlcGVhdGVkIGtleXMuIEnigJlsbCBzdGljayB3aXRoIHF1ZXJ5IHBh
cmFtcyBmb3Igc2ltcGxpY2l0eSBpbiBteSBzYW1wbGUuIDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz4mbmJz
cDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k
aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm
b250LWZhbWlseTpDb25zb2xhcyc+SWYgYSBjbGllbnQgc2lnbnMgdGhpcyBjb25jYXRlbmF0ZWQg
cXVlcnk6IOKAnGE9MSZhbXA7YT0y4oCdIHRoZW4gdGhlIOKAnHDigJ0gdmFsdWUgaW4gdGhlIHNp
Z25lZCBKU09OIG9iamVjdCBjb3VsZCBiZSB0aGlzOjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz4mbmJzcDs8
L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+
PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250
LWZhbWlseTpDb25zb2xhcyc+JnF1b3Q7cCZxdW90OzogW1smcXVvdDthJnF1b3Q7LCAmcXVvdDth
JnF1b3Q7XSwgJnF1b3Q7YmxhaCZxdW90O108L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7PC9zcGFu
PjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+
PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1p
bHk6Q29uc29sYXMnPk9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGhvdyBkbyB5b3Uga25vdyB3aGlj
aCBrZXkvdmFsdWUgcGFpciB0byBwdXQgaW4gd2hpY2ggb3JkZXIgZm9yIHZlcmlmaWNhdGlvbj8g
QWxzbywgZ2l2ZW4gdGhhdCBkaWZmZXJlbnQgc2VydmVyIGltcGxlbWVudGF0aW9ucyBleHByZXNz
IHRoZXNlIGluY29taW5nIHBhcmFtZXRlcnMgaW4gZGlmZmVyZW50IHdheXMsIGl0IHNlZW1zIHBy
b2JsZW1hdGljIHRvIGJlIGNvbnNpc3RlbnQuPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48
L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6Q29uc29sYXMnPiZuYnNwOzwvc3Bh
bj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2
PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFt
aWx5OkNvbnNvbGFzJz5UaGFua3MuPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48
L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1pbHk6Q29uc29sYXMnPiZuYnNwOzwvc3Bhbj48c3Bh
biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtZmFtaWx5OkNv
bnNvbGFzJz4tQnJvY2s8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO
LVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmJz5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PHNwYW4gbGFuZz1F
Ti1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2
PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6
ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWYnPiZuYnNwOzwvc3Bh
bj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rp
dj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsc2VyaWYnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48
L2JvZHk+PC9odG1sPg==

--_000_255B9BB34FB7D647A506DC292726F6E13BBCD3D02FWSMSG3153Vsrv_--


From nobody Sun Feb 28 19:18:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5FF1B2B1B for ; Sun, 28 Feb 2016 19:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level: 
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UGJ6zWWJlBN for ; Sun, 28 Feb 2016 19:18:37 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0B61B2B1A for ; Sun, 28 Feb 2016 19:18:37 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1T3IVbc007938 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Feb 2016 03:18:31 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1T3IUnI014953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 03:18:31 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1T3ITHb009893; Mon, 29 Feb 2016 03:18:30 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Feb 2016 19:18:29 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-D67211D7-FF3F-49AF-A965-F9B7D492FE30
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBCD3D02F@WSMSG3153V.srv.dir.telstra.com>
Date: Sun, 28 Feb 2016 19:18:27 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> <005401d17272$070325a0$150970e0$@gmail.com> <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu> <006f01d1728e$f52af250$df80d6f0$@gmail.com> <255B9BB34FB7D647A506DC292726F6E13BBCD3D02F@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James" 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 03:18:40 -0000

--Apple-Mail-D67211D7-FF3F-49AF-A965-F9B7D492FE30
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

The issue for any service is that things like gateways and proxies may chang=
e or add parameters.

There is a long tradition with http to mess with things headers and payload i=
n the real world. Not ideal, but a certain reality.=20

Thus for certain services it is likely only possible to sign a subset of par=
ams that the client and service provider want to verify did not change.=20

Phil

> On Feb 28, 2016, at 18:39, Manger, James =
 wrote:
>=20
> Being able to selectively include or exclude individual query string name=3D=
value parameters in a signature feels far too dangerous. Always sign them al=
l =E2=80=94 with the only exception being the signature itself if transmitte=
d as a query string parameter.
> Unfortunately we do need to selectively include or exclude HTTP headers as=
 they are a mix of transport, app-layer, end-to-end, and hop-by-hop items.
> =20
> Ignoring duplicate query parameter names is a poor design for a fairly gen=
eric HTTP signing method. My suggestion would be to do a stable sort on para=
meter names. That is, sort the names, but preserve the order of values when a=
 name appears multiple times. =E2=80=A6hoping that works with almost all fra=
meworks.
> =20
> --
> James Manger
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen
> Sent: Monday, 29 February 2016 12:17 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header key=
s
> =20
> Yea, I=E2=80=99m cool with just saying =E2=80=9Cduplicate keys won=E2=80=99=
t work=E2=80=9D for my implementation, unless I do some implementation speci=
fic thing like sort them by value order or some such (but that would have to=
 be on both sides).
> =20
> -Brock
> =20
> From: Justin Richer [mailto:jricher@mit.edu]=20
> Sent: Sunday, February 28, 2016 8:13 PM
> To: Brock Allen 
> Cc:  
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header key=
s
> =20
> Yeah, that=E2=80=99s the trick =E2=80=94 you don=E2=80=99t want to end up r=
eplicating the entire HTTP message inside the JWS envelope, because then you=
 end up with a SOAP kind of approach where you=E2=80=99re not really using t=
he outside HTTP constructs to their fullest anymore.=20
> =20
> In the end, I don=E2=80=99t think this spec is ever going to be perfectly u=
niversal, but if it can hit a majority of use cases with a simple and robust=
 solution, I think we=E2=80=99re in good shape.
> =20
>  =E2=80=94 Justin
> =20
> On Feb 28, 2016, at 1:50 PM, Brock Allen  wrote:
> =20
> Now that I=E2=80=99m thinking about this, the only thing that comes to min=
d is a hash of the value included somehow (which I=E2=80=99m sure you=E2=80=99=
ve already thought of). That=E2=80=99s obviously more complexity and overhea=
d for all scenarios to support this edge case.
> =20
> -Brock
> =20
> From: Brock Allen [mailto:brockallen@gmail.com]=20
> Sent: Sunday, February 28, 2016 4:40 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header key=
s
> =20
> Ok, missed that =E2=80=93 thanks.
> =20
> For now in my implementation I=E2=80=99m also ignoring this problem :)
> =20
> -Brock
> =20
> From: Justin Richer [mailto:jricher@mit.edu]=20
> Sent: Sunday, February 28, 2016 4:37 PM
> To: Brock Allen 
> Cc:  
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header key=
s
> =20
> In =C2=A77.5 we currently have:
> =20
>    The behavior of repeated query parameters or repeated HTTP headers is
>    undefined by this specification.  If a header or query parameter is
>    repeated on either the outgoing request from the client or the
>    incoming request to the protected resource, that query parameter or
>    header name MUST NOT be covered by the hash and signature. [[ Note to
>    the WG: is this something we need to cover? ]]
> =20
> Which is to say: Yeah, that=E2=80=99s a problem, probably. We either decla=
re this behavior out of scope and say you can=E2=80=99t use this method with=
 that kind of API (or at least those parameters/headers) or we define a mech=
anism for handling that. I=E2=80=99m in favor of the former, and removing th=
e text from the generation sections that says repeated parameters are proces=
sed with no special handling, making them explicitly out of scope throughout=
.
> =20
> I would love to see more feedback from the group about this, especially if=
 someone=E2=80=99s got a clever solution.
> =20
>  =E2=80=94 Justin
> =20
> On Feb 28, 2016, at 1:31 PM, Brock Allen  wrote:
> =20
> Given that the client can iterate over the query/headers in any order to g=
enerate the concatenated value to hash, I think there=E2=80=99s an issue wit=
h query string or header values with repeated keys. I=E2=80=99ll stick with q=
uery params for simplicity in my sample.
> =20
> If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D t=
hen the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be this:
> =20
> "p": [["a", "a"], "blah"]
> =20
> On the resource server, how do you know which key/value pair to put in whi=
ch order for verification? Also, given that different server implementations=
 express these incoming parameters in different ways, it seems problematic t=
o be consistent.
> =20
> Thanks.
> =20
> -Brock
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-D67211D7-FF3F-49AF-A965-F9B7D492FE30
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


The issue for any service is that thin=
gs like gateways and proxies may change or add parameters.

There is a long t=
radition with http to mess with things headers and payload in the real world=
. Not ideal, but a certain reality. 

Thus for certain services it is l=
ikely only possible to sign a subset of params that the client and service p=
rovider want to verify did not change. 

Phil

On Feb 28, 2016, at 18:39, Manger, James <James.H.Manger@team.telstra.c=
om> wrote:

Being able=
 to selectively include or exclude individual query string name=3Dvalue para=
meters in a signature feels far too dangerous. Always sign them all =E2=80=94=
 with the only exception being the signature itself if transmitted as a quer=
y string parameter.
Unfortunately we do need to selec=
tively include or exclude HTTP headers as they are a mix of transport, app-l=
ayer, end-to-end, and hop-by-hop items. 
 =
;
Ignoring duplicate query parameter names is a poor des=
ign for a fairly generic HTTP signing method. My suggestion would be to do a=
 stable sort on parameter names. That is, sort the names, but preserve the o=
rder of values when a name appears multiple times. =E2=80=A6hoping that work=
s with almost all frameworks.
 
--
James Manger
=
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen
Sent: Monday, 29 February 2016 12:17 PM
To:=
 'Justin Richer' <jricher@mit.edu&=
gt;
Cc: '<oauth@ietf.org&=
gt;' <OAuth@ietf.org>
Subj=
ect: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys<=
o:p>
 
Yea, I=E2=80=99m cool with just saying =E2=80=9Cduplicate keys=
 won=E2=80=99t work=E2=80=9D for my implementation, unless I do some impleme=
ntation specific thing like sort them by value order or some such (but that w=
ould have to be on both sides).
=
 =
;
-Brock
 
From: Justin Richer [mailto:jricher@mit.edu] 
Sent: S=
unday, February 28, 2016 8:13 PM
To: Brock Allen <brockallen@gmail.com>
Cc: <oauth@ietf.org> <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] HT=
TP request signing and repeated query/header keys
 <=
/p>
Yeah, that=E2=80=99s the tric=
k =E2=80=94 you don=E2=80=99t want to end up replicating the entire HTTP mes=
sage inside the JWS envelope, because then you end up with a SOAP kind of ap=
proach where you=E2=80=99re not really using the outside HTTP constructs to t=
heir fullest anymore. 
 
In the end, I don=E2=80=99t think this spec is ever going to be perf=
ectly universal, but if it can hit a majority of use cases with a simple and=
 robust solution, I think we=E2=80=99re in good shape.
=

 
 =E2=80=94=
 Justin
 
On =
Feb 28, 2016, at 1:50 PM, Brock Allen <brockallen@gmail.com> wrote:
 
<=
div>
Now that I=E2=80=99m thinking about this, the only thing th=
at comes to mind is a hash of the value included somehow (which I=E2=80=99m s=
ure you=E2=80=99ve already thought of). That=E2=80=99s obviously more comple=
xity and overhead for all scenarios to support this edge case. 
 
-Brock
 
From: Brock Allen [mailto:b=
rockallen@gmail.com] 
Sent: Sunday, February 28, 2016 4:40 PM<=
br>To: 'Justin Richer' <jricher=
@mit.edu>
Cc: '<oauth@=
ietf.org>' <OAuth@ietf.org&g=
t;
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query=
/header keys
 
Ok, missed that =E2=80=93 thanks.
 
For now in my implementation I=E2=80=99m=
 also ignoring this problem :)=

 
-Brock=

 
From: Justin Richer [<=
a href=3D"mailto:jricher@mit.edu">mailto:jricher@mit.edu] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen <brockallen@gmail.com>
Cc: <=
;oauth@ietf.org> <OAuth@ietf.org>
Subject: Re: [OAUTH-WG]=
 HTTP request signing and repeated query/header keys
 =

In =C2=
=A77.5 we currently have:
 
=

   The behavior of repeated query parame=
ters or repeated HTTP headers is
   undefined by this specification.  If a header or que=
ry parameter is
  =
; repeated on either the outgoing request from the client or the<=
/span>
   incoming request to the p=
rotected resource, that query parameter or
   header name MUST NOT be covered by the hash and=
 signature. [[ Note to
&nbs=
p;  the WG: is this something we need to cover? ]]
 
W=
hich is to say: Yeah, that=E2=80=99s a problem, probably. We either declare t=
his behavior out of scope and say you can=E2=80=99t use this method with tha=
t kind of API (or at least those parameters/headers) or we define a mechanis=
m for handling that. I=E2=80=99m in favor of the former, and removing the te=
xt from the generation sections that says repeated parameters are processed w=
ith no special handling, making them explicitly out of scope throughout.
 
I would love to see more feedback from the group a=
bout this, especially if someone=E2=80=99s got a clever solution.=

 
 =E2=80=94 Justin
<=
div>
 
<=
div>
On Feb 28, 2016, at 1:3=
1 PM, Brock Allen <brockallen@gma=
il.com> wrote:
 
Given that the client can iterate over the query/headers in any order t=
o generate the concatenated value to hash, I think there=E2=80=99s an issue w=
ith query string or header values with repeated keys. I=E2=80=99ll stick wit=
h query params for simplicity in my sample. 
 
If a client signs this concatenated q=
uery: =E2=80=9Ca=3D1&a=3D2=E2=80=9D then the =E2=80=9Cp=E2=80=9D value i=
n the signed JSON object could be this:
 
"p": [["a", "a"], "blah"]
 
On the resource serv=
er, how do you know which key/value pair to put in which order for verificat=
ion? Also, given that different server implementations express these incomin=
g parameters in different ways, it seems problematic to be consistent.
 
Thanks.
 
-Brock
 
___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 
__________________________________=
_____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/=
oauth
=

--Apple-Mail-D67211D7-FF3F-49AF-A965-F9B7D492FE30--


From nobody Sun Feb 28 23:42:34 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ABE1B2D5D for ; Sun, 28 Feb 2016 23:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 zoPDT5hP8F-V for ; Sun, 28 Feb 2016 23:42:30 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 AE1EA1B2D5C for ; Sun, 28 Feb 2016 23:42:29 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id d32so53661027qgd.0 for ; Sun, 28 Feb 2016 23:42:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=B6modMcPbhztbJBTEZlcOOvmkuCFSNwErR5qc6ERSHw=; b=cJGQOP0AN0rr3wcGr3tkrO/cqHlB+ryiLfMyeS9Qb68/gJp1hHRlhmLscIe9j0U37N g16BWC3KN68OWN7I2RCZxcALaLdRuqvZzRGbKn3qXwentBqcM0E5w/HVd7q5gC49baVS lPj2vfXqxSPW/pG6yedQNGwV6O6/3etp+B68WN2Oi1VTsb/NXCUxtWjnp/cEeHjNf8uN 5Ddt1j7dsThi1JrU/KxFFEeT2hNUwtOZ0zAo1Jjl3x502j7Tfj9TeWcPBcSLlTrVf8cD 6Z3nb2jTsJcT4r6BT47sSiq6vwYneGJ2V066j/s2b4dW4I/SJQBAf94KR8DR5G4f44uk qQpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=B6modMcPbhztbJBTEZlcOOvmkuCFSNwErR5qc6ERSHw=; b=CQ7TqGS4iqwLbBXdqEEc9dCLZF8FyWzaK+geayQ6boT9dc+29BsQtm9xEF6Zc28Ll0 TrbZYPVRXAsEmbisjPnaYHveK2U1+Tcg/fynYeC8ioW9yz7DonpUrQMmpcgMUqUexmd5 jMA9rZOD6x41XSTsouREQckr6GoaLSl5zhtYn+Ij/KNC4OniJ43uwuRpKx7bWsW2weQN +B4Az1FmdcX0UppwsgxzlJLgcc98v04nu1z/YYEY3hdaLQN+DZzBLRHojL/eMBRD314j RC1U6xW5DP3wxOVIGDeTsyo76auC1dTM3MsnE0F0MfMr5l911uV99cBIEk3mnL3S9ufN lhog==
X-Gm-Message-State: AD7BkJIcHJAdFEIjnEubwzm/WZgR66M5PsJtVMZnSpzx5HmY3kPs3E8W1uixh6rU5My+35lyeQfzXbo6yNgIcQ==
MIME-Version: 1.0
X-Received: by 10.140.217.209 with SMTP id n200mr18374436qhb.101.1456731748925;  Sun, 28 Feb 2016 23:42:28 -0800 (PST)
Received: by 10.55.179.1 with HTTP; Sun, 28 Feb 2016 23:42:28 -0800 (PST)
In-Reply-To: <4DF9257B-EAFE-440C-B1DD-FB7507F1BB18@mit.edu>
References: <008201d170a4$f5216910$df643b30$@gmail.com> <69709F83-8D24-44DE-9A3B-D3BF8F70C201@mit.edu>  <4DF9257B-EAFE-440C-B1DD-FB7507F1BB18@mit.edu>
Date: Mon, 29 Feb 2016 08:42:28 +0100
Message-ID: 
From: Samuel Erdtman 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=001a113997c46d97ec052ce3ca4b
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP signing spec and nonce
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 07:42:32 -0000

--001a113997c46d97ec052ce3ca4b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

To me it seems reasonable that a client may send multiple signed messages
in one second.

So I=C2=B4m +1 for a nonce. A more fine grained timestamp is nice but I thi=
nk we
might end upp at the same place, someone saying that they think it is
reasonable to send multiple signed messages the same millisecond.

//Samuel

On Sun, Feb 28, 2016 at 10:34 PM, Justin Richer  wrote:

> I understand how they work, I=E2=80=99ve built exactly that cache before.=
 But I
> askWouldn=E2=80=99t a unique timestamp have the same effect? Currently it=
=E2=80=99s integer
> seconds but slicing that down further (floating point seconds?) if people
> desired would allow for multiple signed messages in the same second from
> the same client using the otherwise same parameters.
>
> =E2=80=9COther protocols do it=E2=80=9D is not a compelling reason on its=
 own, especially
> when the example of =E2=80=9Cother protocols=E2=80=9D includes WS-* ;)
>
> Seriously though, an optional nonce is easy to add to the draft if there=
=E2=80=99s
> enough WG support, I=E2=80=99m just hesitant to add more complexity than =
needed to
> this.
>
>  =E2=80=94 Justin
>
> On Feb 26, 2016, at 11:06 PM, Dominick Baier 
> wrote:
>
> The nonce would allow to build a replay cache, the timestamp to trim that
> cache and reject messages that are too old.
>
> Similar protocols have a nonce for the above reasons (ws-sec msg security=
,
> hawk)...
>
> =E2=80=94
> cheers
> Dominick Baier
>
> On 27 February 2016 at 03:48:00, Justin Richer (jricher@mit.edu) wrote:
>
> I=E2=80=99d be glad to add in a nonce if there=E2=80=99s a compelling rea=
son for it, such
> as closing a security attack vector.
>
> What=E2=80=99s the proposed purpose of the nonce? Is it just to add rando=
mness to
> the signing base? Or is it to prevent replay at the RS? If the former, th=
e
> timestamp should add enough of that and it can be verified to be within a
> reasonable window by the RS by comparing it with the time the request was
> made. If the latter, the RS is going to have to track previously used
> nonces for some amount of time.
>
> There was a small discussion of just signing an outgoing =E2=80=9CDate:=
=E2=80=9D header
> instead of the separate timestamp, but the timestamp seemed to be more
> robust. I forget the full reasoning though.
>
>  =E2=80=94 Justin
>
> On Feb 26, 2016, at 9:49 AM, Brock Allen  wrote:
>
> Question about the HTTP signing spec =E2=80=93 why is there no nonce (and=
 just a
> timestamp)?
>
> TIA
>
> -Brock
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113997c46d97ec052ce3ca4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


To me it seems reasonable that a client may send multiple =
signed messages in one second.

So I=C2=B4m +1 for a nonc=
e. A more fine grained timestamp is nice but I think we might end upp at th=
e same place, someone saying that they think it is reasonable to send multi=
ple signed messages the same millisecond.

//Samuel=


On Su=
n, Feb 28, 2016 at 10:34 PM, Justin Richer <jricher@mit.edu> w=
rote:
I understand how they work, I=E2=80=99ve built exactly that cache before. =
But I askWouldn=E2=80=99t a unique timestamp have the same effect? Currentl=
y it=E2=80=99s integer seconds but slicing that down further (floating poin=
t seconds?) if people desired would allow for multiple signed messages in t=
he same second from the same client using the otherwise same parameters.=C2=
=A0

=E2=80=9COther protocols do it=E2=80=9D is not a com=
pelling reason on its own, especially when the example of =E2=80=9Cother pr=
otocols=E2=80=9D includes WS-* ;)

Seriously though=
, an optional nonce is easy to add to the draft if there=E2=80=99s enough W=
G support, I=E2=80=99m just hesitant to add more complexity than needed to =
this.

=C2=A0=E2=80=94 Justin

=

On Feb 26, 2016, at 11:06 PM, Dominick =
Baier <db=
aier@leastprivilege.com> wrote:



The nonce would allow to build a replay cache=
, the timestamp to trim that cache and reject messages that are too old.
Similar protocols have a nonce for the above reasons (ws-sec msg security,=
 hawk)...
 
 
=E2=80=94=C2=A0
cheers
Dominick=
 Baier
 
On 27 February 2016 at 03:48:00, Justin Richer (<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu) wr=
ote:
 











I=E2=80=99d be glad to add in a nonce if there=E2=80=99s a compelling
reason for it, such as closing a security attack vector.




What=E2=80=99s the proposed purpose of the nonce? Is it just to add
randomness to the signing base? Or is it to prevent replay at the
RS? If the former, the timestamp should add enough of that and it
can be verified to be within a reasonable window by the RS by
comparing it with the time the request was made. If the latter, the
RS is going to have to track previously used nonces for some amount
of time.=C2=A0




There was a small discussion of just signing an
outgoing =E2=80=9CDate:=E2=80=9D header instead of the separate timestamp, =
but the
timestamp seemed to be more robust. I forget the full reasoning
though.







=C2=A0=E2=80=94 Justin









On Feb 26, 2016, at 9:49 AM, Brock Allen <brockallen@gmail.com>
wrote:










Question abou=
t the HTTP signing spec =E2=80=93 why is there no nonce
(and just a timestamp)?


=C2=A0=



TIA

=C2=A0=



-Brock=



=C2=A0





_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth











_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_____________________________________________=
__

OAuth mailing list

OAuth@ietf.org

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





--001a113997c46d97ec052ce3ca4b--


From nobody Mon Feb 29 14:35:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CB81B3E29 for ; Mon, 29 Feb 2016 14:35:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 rraEDG8vh92E for ; Mon, 29 Feb 2016 14:35:30 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F551B3E3B for ; Mon, 29 Feb 2016 14:35:30 -0800 (PST)
Received: by mail-ig0-x233.google.com with SMTP id z8so5728281ige.0 for ; Mon, 29 Feb 2016 14:35:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R34A6B+FA7iGDM1AYd2XjGLIfaKUrUzsyO6KQZFnLjU=; b=CO7nFeV7pA04HO6HPEztwE+c17/wNd1Pm81p93mO5vUhN+jCiWv7Fnhl8gWYlpfa8x LeV2QNcCLWaBwCELxuUTNEs0cxO6SmkRf5ua6BAafclI1YJzonww9hhJ5rxuVVw7jrFV wi9mcP28iX+JaYGCx8AJ66nai462rGV9D/9dg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R34A6B+FA7iGDM1AYd2XjGLIfaKUrUzsyO6KQZFnLjU=; b=SNbJmebYhnS1v8493RcOSiUW4jgAb2+i9KoH7yJYOlL69cHIUg1qwNwbn1eOnTAOgp bTJhv8zP822A6QKkVQyXb7lyZeTM/LoHGmqwZjnzPd0nYqdWrs/RYBdSXeF+fxPUGckp EGQ4wj2ceIXuiW0wHAj+p4lThotgnuRE7s7PxZAPK/t7QXkk31C8ebtwA4ZYORdhjGuE 1jkQbgC/6vwupxXgmRwcqM+t/9NTzuNcM/EP7gTlHgbktDUqPvhKJIIyszKQjIvk5qAp v+e1JzTNHm/WAMD4nHFXWLMgmP25u691om3wI2C/dA9iMAvGeGF5TGuQG4qOqVbrqEVK 8Tog==
X-Gm-Message-State: AD7BkJKykT19P3sHYZGRpJd7KpHnYy3JO2g56yN0saK8vO4uArfEBD4VLfRSS2YaeOGWiH3i91TLcQNFBm+pr/vz
X-Received: by 10.50.85.14 with SMTP id d14mr324382igz.49.1456785329407; Mon, 29 Feb 2016 14:35:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Mon, 29 Feb 2016 14:34:59 -0800 (PST)
In-Reply-To: 
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>   
From: Brian Campbell 
Date: Mon, 29 Feb 2016 15:34:59 -0700
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=089e013c710013060a052cf04421
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 22:35:32 -0000

--089e013c710013060a052cf04421
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 for "OAuth 2.0 Authorization Server Discovery=E2=80=9D from those two op=
tions.

But what about "OAuth 2.0 Authorization Server Metadata=E2=80=9D?

The document in its current scope (which I agree with, BTW) isn't really
about discovery so much as about describing the metadata at some
well-known(ish) resource.



On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones 
wrote:

> It=E2=80=99s clear that people want us to move to the name =E2=80=9COAuth=
 2.0
> Authorization Server Discovery=E2=80=9D.  The editors will plan to make t=
hat
> change in the draft addressing Working Group Last Call comments.
>
>
>
>                                                           Thanks all,
>
>                                                           -- Mike
>
>
>
> *From:* Samuel Erdtman [mailto:samuel@erdtman.se]
> *Sent:* Saturday, February 27, 2016 6:47 AM
> *To:* Mike Jones 
> *Cc:* Vladimir Dzhuvinov ; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> +1 for =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
>
>
>
> //Samuel
>
>
>
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
> wrote:
>
> Thanks for your thoughts, Vladimir.  I=E2=80=99m increasingly inclined to=
 accept
> your suggestion to change the title from =E2=80=9COAuth 2.0 Discovery=E2=
=80=9D to =E2=80=9COAuth
> 2.0 Authorization Server Discovery=E2=80=9D.  While the abstract already =
makes it
> clear that the scope of the document is AS discovery, doing so in the tit=
le
> seems like it could help clarify things, given that a lot of the discussi=
on
> seems to be about resource discovery, which is out of scope of the docume=
nt.
>
>
>
> I=E2=80=99m not saying that resource discovery isn=E2=80=99t important =
=E2=80=93 it is =E2=80=93 but
> unlike authorization server discovery, where there=E2=80=99s lots of exis=
ting
> practice, including using the existing data format for describing OAuth
> implementations that aren=E2=80=99t being used with OpenID Connect, there=
=E2=80=99s no
> existing practice to standardize for resource discovery.  The time to
> create a standard for that seems to be after existing practice has
> emerged.  It **might** or might not use new metadata values in the AS
> discovery document, but that=E2=80=99s still to be determined.  The one r=
eason to
> leave the title as-is is that resource discovery might end up involving
> extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
> applies.  6749 is about the AS.  6750 is about the RS.  The discovery
> document is about the AS.  We don=E2=80=99t yet have a specification or e=
xisting
> practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> =C2=B7       =E2=80=9COAuth 2.0 Discovery=E2=80=9D
>
> =C2=B7       =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=9D
>
>
>
>              
>
>
>
>

--089e013c710013060a052cf04421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 for "OAuth 2.0 Authorization Server Discovery=
=E2=80=9D from those two options.

But what about "OAuth 2.0 Aut=
horization Server Metadata=E2=80=9D?

The document in its curre=
nt scope (which I agree with, BTW) isn't really about discovery so much=
 as about describing the metadata at some well-known(ish) resource. 


On Sat, Feb =
27, 2016 at 10:48 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:











It=E2=80=99s clear that people want u=
s to move to the name
=E2=80=9COAuth 2.0 Authorization Ser=
ver Discovery=E2=80=9D.=C2=A0 The editors will plan t=
o make that change in the draft addressing Working Group Last Call
 comments.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Thanks all,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 -- Mike


=C2=A0



From: Samuel Erdtman [mailto:samuel@erdtman.se]


Sent: Saturday, February 27, 2016 6:47 AM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>; oauth@ietf.org


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


=C2=A0




+1 for =E2=80=9COAut=
h 2.0 Authorization Server Discovery=E2=80=9D




=C2=A0






//Samuel








=C2=A0




On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <Michael.Jones@=
microsoft.com> wrote:








Thanks for your thoughts, Vladimir.=
=C2=A0 I=E2=80=99m increasingly inclined to accept your suggestion to chang=
e
 the title from =E2=80=9COAuth 2.0 Discovery=E2=80=9D to =E2=80=9COAuth 2.0=
 Authorization Server Discovery=E2=80=9D.=C2=A0 While the abstract already =
makes it clear that the scope of the document is AS discovery, doing so in =
the title seems like it could help clarify things, given that a lot of
 the discussion seems to be about resource discovery, which is out of scope=
 of the document.


=C2=A0


I=E2=80=99m not saying that resource =
discovery isn=E2=80=99t important =E2=80=93 it is =E2=80=93 but unlike auth=
orization server discovery,
 where there=E2=80=99s lots of existing practice, including using the exist=
ing data format for describing OAuth implementations that aren=E2=80=99t be=
ing used with OpenID Connect, there=E2=80=99s no existing practice to stand=
ardize for resource discovery.=C2=A0 The time to create a standard
 for that seems to be after existing practice has emerged.=C2=A0 It *mig=
ht* or might not use new metadata values in the AS discovery document, =
but that=E2=80=99s still to be determined.=C2=A0 The one reason to leave th=
e title as-is is that resource discovery might end
 up involving extensions to this metadata format in some cases.


=C2=A0


I think an analogy to the core OAuth =
documents RFC 6749 and RFC 6750 applies.=C2=A0 6749 is about the AS.=C2=A0
 6750 is about the RS.=C2=A0 The discovery document is about the AS.=C2=A0 =
We don=E2=80=99t yet have a specification or existing practice for RS disco=
very, which would be the 6750 analogy.


=C2=A0


In summary, which title do people pre=
fer?


=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
=E2=80=9COAuth 2.0 Discovery=E2=80=9D


=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
=E2=80=9COAuth 2.0 Authorization Server Discovery=E2=
=80=9D


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 







--089e013c710013060a052cf04421--


From nobody Mon Feb 29 14:41:50 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF7D1B3E59 for ; Mon, 29 Feb 2016 14:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 SFMlO54AlHDu for ; Mon, 29 Feb 2016 14:41:48 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 027F51B3E58 for ; Mon, 29 Feb 2016 14:41:48 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id 9so199698988iom.1 for ; Mon, 29 Feb 2016 14:41:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f3zX29vt7xo6afditRDCXGic/qlzgF3WwUvU5tSSDqQ=; b=FkW/YEGKgEvybe8uOEsNs/J6u4JDWOG5361bfUD0STfEKjf6Ek7dGtgxivdGtLpH8a 0pf5LwRdBZIvyQWjWkO9EImGw5RHMoCG2vazaHrJ8RPfy/sOq5MlFPQOyhiPmSm1kNqh KYuZkHp/dalqIlZqwhAzyoFynkmEdD1hglVF0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f3zX29vt7xo6afditRDCXGic/qlzgF3WwUvU5tSSDqQ=; b=chvxDnajjwlSQ6U/IJE2SlGVULRzJi5Yo363Cy64uS5VGfcY87YN0b3eGPqysMRSv8 +8ewOorhrg7VkTbzw69a9BltQqFZqa2a/Q1HbLsAe3g/lLjzLDicH6STTmfsUE+L9+ZE nF/tmKeNLqNskkAfotykrLJiGITe9UG16Y9t2VrOW07uCsSMXEmcNewTZSfkAEFmX913 FxIOjXzPQt2XBDpakusFlL/9dPwF43Z0qhdwfrUf7tCFG8Qeic/ACpDIYIqNb0kLxb/J SODBIJ33DZS4vdi8LR2VzBJDcN3wuSR1XYtwlZqVf7A83qRlUWVUD154eIfMIB0ZEUSA 3A7g==
X-Gm-Message-State: AG10YOTleJq2+Eb/VCPtviUYA8RLe/3WIz34KjxwlDLVO/k1JxCcEmvE6vIIFwUDAEkV1ETr35CIcTQNSvQxWQwq
X-Received: by 10.107.15.196 with SMTP id 65mr24244154iop.48.1456785707283; Mon, 29 Feb 2016 14:41:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Mon, 29 Feb 2016 14:41:17 -0800 (PST)
In-Reply-To: <56C7EB56.3040906@connect2id.com>
References:  <56C7EB56.3040906@connect2id.com>
From: Brian Campbell 
Date: Mon, 29 Feb 2016 15:41:17 -0700
Message-ID: 
To: Vladimir Dzhuvinov 
Content-Type: multipart/alternative; boundary=001a113fec6c98d46c052cf05a65
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 22:41:49 -0000

--001a113fec6c98d46c052cf05a65
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov  wrote:

> +1
>
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in the
> right direction. It does, however, still have too many vestiges of its
> OpenID Connect origins. One issue in particular still really bothers me:
> the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the dis=
covery portion. Is
> this an OAuth discovery document, or an OpenID Connect one? There is
> absolutely no compelling reason to tie the URL to the OIDC discovery
> mechanism.
> >
> > I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the
> default discovery location, and state that the document MAY also be
> reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=9D if the=
 server also
> provides OpenID Connect on the same domain. Other applications SHOULD use
> the same parameter names to describe OAuth endpoints and functions inside
> their service-specific discovery document.
> >
> >  =E2=80=94 Justin
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113fec6c98d46c052cf05a65
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 

On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov <vladimir=
@connect2id.com> wrote:
+1<=
br>



On 19/02/16 23:59, Justin Richer wrote:

> The newly-trimmed OAuth Discovery document is helpful and moving in th=
e right direction. It does, however, still have too many vestiges of its Op=
enID Connect origins. One issue in particular still really bothers me: the =
use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in the discovery=
 portion. Is this an OAuth discovery document, or an OpenID Connect one? Th=
ere is absolutely no compelling reason to tie the URL to the OIDC discovery=
 mechanism.

>

> I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the default discovery location, and state that the document MA=
Y also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other ap=
plications SHOULD use the same parameter names to describe OAuth endpoints =
and functions inside their service-specific discovery document.

>

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

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a113fec6c98d46c052cf05a65--


From nobody Mon Feb 29 15:36:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF51A03A0 for ; Mon, 29 Feb 2016 15:36:41 -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, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G94_VrfDEAxW for ; Mon, 29 Feb 2016 15:36:39 -0800 (PST)
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) (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 BC4DA1A064C for ; Mon, 29 Feb 2016 15:36:38 -0800 (PST)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 21B5D2802804; Mon, 29 Feb 2016 15:36:34 -0800 (PST)
Received: from [172.29.187.101] (unknown [198.202.202.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Mon, 29 Feb 2016 15:36:33 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC1CC2BB-4D07-49C7-BD99-70BA34B4271D"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Roland Hedberg 
In-Reply-To: 
Date: Mon, 29 Feb 2016 16:36:25 -0700
Message-Id: <80A1BD00-F762-49D7-A520-21ECBC9405C9@catalogix.se>
References:  <56C7EB56.3040906@connect2id.com> 
To: oauth 
X-Mailer: Apple Mail (2.3112)
X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact abuse@rollernet.us to report violations. Abuse policy: http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 5cc8.56d4d601.98d1d.0
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Feb 2016 23:36:41 -0000

--Apple-Mail=_AC1CC2BB-4D07-49C7-BD99-70BA34B4271D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1=20

> 29 feb. 2016 kl. 15:41 skrev Brian Campbell =
:
>=20
> +1=20
>=20
> On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov =
> wrote:
> +1
>=20
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.
> >
> > I propose that we use =E2=80=9C/.well-known/oauth-authorization-server=
=E2=80=9D as the default discovery location, and state that the document =
MAY also be reachable from =E2=80=9C/.well-known/openid-configuration=E2=80=
=9D if the server also provides OpenID Connect on the same domain. Other =
applications SHOULD use the same parameter names to describe OAuth =
endpoints and functions inside their service-specific discovery =
document.
> >
> >  =E2=80=94 Justin
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org 
> > https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_AC1CC2BB-4D07-49C7-BD99-70BA34B4271D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 

29 feb. 2016 kl. 15:41 skrev =
Brian Campbell <bcampbell@pingidentity.com>:

+1 

On Fri, Feb 19, 2016 at 9:28 PM, =
Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
+1




On 19/02/16 23:59, Justin Richer wrote:

> The newly-trimmed OAuth Discovery document is helpful and moving in =
the right direction. It does, however, still have too many vestiges of =
its OpenID Connect origins. One issue in particular still really bothers =
me: the use of =E2=80=9C/.well-known/openid-configuration=E2=80=9D in =
the discovery portion. Is this an OAuth discovery document, or an OpenID =
Connect one? There is absolutely no compelling reason to tie the URL to =
the OIDC discovery mechanism.

>

> I propose that we use =E2=80=9C/.well-known/oauth-authorization-serve=
r=E2=80=9D as the default discovery location, and state that the =
document MAY also be reachable from =
=E2=80=9C/.well-known/openid-configuration=E2=80=9D if the server also =
provides OpenID Connect on the same domain. Other applications SHOULD =
use the same parameter names to describe OAuth endpoints and functions =
inside their service-specific discovery document.

>

>  =E2=80=94 Justin

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




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

=

--Apple-Mail=_AC1CC2BB-4D07-49C7-BD99-70BA34B4271D--


On Thu, Feb 18, 2016 at 12:34 AM, Mike Jones=
 <Michael.Jones@microsoft.com> wrote:











Thanks to William Denniss for creating the initial w=
orking group version of the OAuth 2.0 Device Flow specification.=C2=A0 The =
abstract of the specification is:


=C2=A0


The device flow is suitab=
le for OAuth 2.0 clients executing on devices which do not have an easy dat=
a-entry method (e.g., game consoles, TVs, picture frames, and media hubs), =
but where the end-user has separate
 access to a user-agent on another computer or device (e.g., desktop comput=
er, a laptop, a smart phone, or a tablet).


=C2=A0


Note: This version of the=
 document is a continuation of an earlier, long expired draft.=C2=A0 The co=
ntent of the expired draft has been copied almost unmodified.=C2=A0 The goa=
l of the work on this document is to capture deployment
 experience.


=C2=A0


If you=E2=80=99re using an OAuth device flow, please=
 let us know whether this specification matches your usage, and if not, how=
 yours differs.


=C2=A0


The specification is available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
http://tools.ietf.org/html/draft-=
ietf-oauth-device-flow-00


=C2=A0


An HTML-formatted version is also available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
http://self-issued.info/do=
cs/draft-ietf-oauth-device-flow-00.html


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<=
u>


=C2=A0


P.S.=C2=A0 This notice was also posted at 
http://self-issued.info/?p=3D1546 and as 
@selfissued.







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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